The part after launch, that decides whether it lasted.
Monitoring, monthly patching, incident response and a steady pace of small improvements, handled by the engineers who wrote the code. Software nobody maintains does not stay working, it fails later and more expensively.
- Monthly
- rolling, 30 days' notice
- Named engineers
- the people who built it
- 30 days
- notice, both directions
Who this is for
You probably need this if…
01
The people who built it have gone
The agency moved on or the developer left, and nobody currently at the company has ever opened the repository.
02
Updates have been deferred for a year
Every month it gets harder to start. At some point a security advisory makes the decision for you, usually at an inconvenient moment.
03
Nobody knows if it is working right now
There is no monitoring, so the honest answer is whoever most recently tried to log in and did not complain about it.
What we build
The work, in detail.
Support hours
A defined number of hours each month with a response commitment tiered by severity, handled by engineers who already know the codebase.
Monitoring & response
Alerts routed to a person, runbooks for the failures we already know about, and a written note afterwards about what actually happened.
Dependency updates
Patches applied monthly rather than accumulated into one frightening upgrade nobody wants to be the person to start.
Security patching
Advisories tracked against your real dependency tree, with anything urgent applied out of cycle rather than waiting for the monthly slot.
Iterative delivery
A small, steady stream of improvements. The alternative is a rewrite in three years, which costs more and feels considerably worse.
Quarterly review
What got slower, what the cloud bill is doing, and what we propose to do about both, costed and prioritised.
Living documentation
Architecture notes and runbooks kept current, so leaving stays a normal option rather than becoming a negotiation.
Incident write-ups
What broke, why, and what changed as a result. Short, honest and sent to you, because incidents nobody documents tend to recur.
Practice areas
The disciplines behind it.
You buy this as one engagement at one price. Underneath, it draws on 4 of our practice areas, and the same people cover all of them.
Managed Services
What happens after launch, when the interesting part is over.
- Support retainers
- Monitoring & incident response
- Iterative delivery
- Dependency updates
Cloud & Delivery
The infrastructure underneath, and the pipeline that keeps it moving.
- Deployment & hosting
- Infrastructure as code
- CI/CD pipelines
- Containers & orchestration
Security & Access
Who can see what, proven rather than assumed.
- Authentication
- Roles & permissions
- Tenant isolation
- Audit logging
Quality & Testing
Knowing it works before a customer tells you that it does not.
- Automated test suites
- End-to-end testing
- Load & stress testing
- Accessibility testing
How it runs
Four weeks, in order.
Week 1
Onboard
For software we did not build, a paid audit first: we read the code and tell you honestly whether it is maintainable or whether a retainer would fund a slow rewrite.
Month 1
Instrument
Monitoring, alerting and runbooks in place, plus the first dependency pass. Most retainers start by discovering what was never being watched.
Monthly
Maintain
Patching, advisories, agreed improvement work and a written report. A shared channel for anything that cannot wait for the cycle.
Quarterly
Review
Performance, cost and risk reviewed together, with next quarter's priorities agreed rather than assumed.
What you get, concretely
- A named engineer who knows your system, not a ticket queue
- Monitoring and alerting with a runbook per alert
- Monthly dependency and security patching
- A written monthly report in plain sentences
- Incident write-ups within two business days
- Documentation kept current throughout
- Handover on exit, written into the agreement from the start
Typical engagement
Rolling monthly · 30 days' notice
Driven by hours and response commitment. The lighter end is monitoring, patching and a few hours of change work; the heavier end is same-business-day response and continuous delivery of improvements.
Technology
What we build it with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Monitoring
- Sentry, uptime checks, OpenTelemetry
- Updates
- Dependabot, scheduled review, staged rollout
- Communication
- Shared channel, monthly written report
- Access
- Scoped credentials in your secret manager
Proof
We have built this before.
Not a reference we cannot name. Systems we designed, shipped and still operate, with the decisions written down.
Questions
What people ask before signing.
- Do we have to take a retainer after launch?
- No. Thirty days of fixes are included with every build, and plenty of clients take handover and run it themselves. The documentation and walkthrough are delivered either way.
- What is the response time?
- Tiered by severity and written into the agreement. Something down in production is not the same as a layout issue on a settings page, and the contract says so explicitly.
- Can you maintain software you did not build?
- Often, after a paid audit. We read the code first and tell you honestly whether it is maintainable. Sometimes the answer is that a retainer would be funding a slow rewrite, and you should hear that up front.
- Do unused hours roll over?
- One month, so a quiet period is not wasted and a busy one is not penalised. Beyond that they lapse, because banking six months of hours is how a retainer turns into an unplanned project.
- What if we want to leave?
- Thirty days' notice, a handover session, current documentation and credentials transferred. Written in from the start rather than negotiated at the end.
- Who actually does the work?
- The engineers who built it, or for inherited systems the ones who did the audit. Context is most of what makes a fix fast, and rotating the work throws that away.
Related reading
Written on this, by us.
Cloud & Security · 7 min read
Your Cloud Bill Went Up Forty Per Cent and Nobody Knows Why
Cloud spend rarely grows because of one decision. It grows because of a dozen small ones nobody wrote down. Here is how to find them, in order of how much they are costing you.
Cloud & Security · 7 min read
What SOC 2 Actually Asks For, and What No Engineering Firm Can Sell You
A customer sends a security questionnaire and suddenly compliance is urgent. Here is what the controls actually are, and where the line sits between preparation and certification.
How We Work · 6 min read
The Test Suite That Earns Its Keep
Coverage percentage is easy to raise and easy to game. Here is where tests actually pay for themselves, and why nobody on your team wants to deploy on a Friday.
Tell us what you need kept running.
What it does, who built it, and what would hurt most if it stopped. For anything we did not build, the first step is a paid audit rather than a promise.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits