The part after launch, that decides whether it lasted.
Monitoring, dependency updates, incident response and a steady pace of small improvements. Software nobody maintains does not stay working, it simply fails later and more expensively.
- Named engineers
- the people who built it
- Monthly
- dependency and security updates
- Exit anytime
- handover is in the contract
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 on your behalf, 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.
What this covers
The work, in detail.
7 capabilities
01
Support retainers
A defined number of hours each month with a response commitment, handled by the engineers who wrote the code in the first place.
02
Monitoring & incident response
Alerts routed to a person, runbooks for the failures we already know about, and a written note afterwards about what actually happened.
03
Iterative delivery
A small, steady stream of improvements. The alternative is a rewrite in three years, which costs more and feels considerably worse.
04
Dependency updates
Patches applied monthly rather than accumulated into one frightening upgrade that nobody on the team wants to be the person to start.
05
Security patching
Advisories tracked against your actual dependency tree, with anything urgent applied out of cycle rather than waiting for the monthly slot.
06
Performance review
A quarterly look at what got slower and what the cloud bill is doing, with the fixes prioritised and costed rather than just noted.
07
Handover & documentation
Kept current throughout, so that leaving remains a normal option rather than becoming a negotiation.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
The builders do the maintenance
The engineers who wrote it answer for it. Context is most of what makes a fix fast, and handing the work to a different team throws that away.
02
Small and often beats big and rare
Monthly patching is routine and dull. Annual patching is a project with a risk register and an argument about who pays for it.
03
Write up every incident
What broke, why, and what changed as a result. Short, honest, and sent to you. Incidents that never get written down tend to happen again.
04
Leaving should be easy
Documentation stays current and handover is contractual. A retainer should be kept because it is useful, not because exiting it is painful.
Technology
What we work 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
Where this shows up in delivery
- We stay on call for what we deliver, and hold maintenance to the standard we would want as the client.
- Sill is patched centrally, which means a security fix reaches every engagement built on it rather than one project at a time.
- Handover documentation is a deliverable on every engagement, whether or not a retainer follows it.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Questions
What people ask about managed services.
- Do we have to take a retainer after launch?
- No. Plenty of clients take handover and run it in-house. The documentation and the walkthrough are delivered either way, because they are part of what you bought.
- What is the response time?
- Defined in the retainer and tiered by severity. Something down in production is not the same as a layout issue on a settings page, and the agreement says so explicitly.
- Can you maintain software you did not build?
- Often yes, after a paid audit. We read the code first and tell you honestly whether it is maintainable or whether a retainer would be funding a slow rewrite.
- What if we want to leave?
- Notice period, handover session, current documentation, credentials transferred. All of it written into the agreement from the start rather than negotiated at the end.
Related reading
Written on this, by us.
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 · 7 min read
Seven Signs a Software Agency Is Going to Disappear on You
The most expensive software project is the one that gets 70% finished and then stops. These are the warning signs, most of which show up before you sign anything.
Business & Strategy · 9 min read
How to Choose a Software Development Partner
Running a selection properly: how many firms to approach, how to make quotes comparable, what to check in a portfolio, and the contract terms that matter.
Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
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