Software maintenance and support that owns it after launch
Ongoing maintenance retainers covering monitoring, security updates, bug fixes, and incremental improvement — for software we built and software we did not.
a retainer with people on it, not a queue you shout into
- Monitoring and alerting
- Security patching
- Bug fixing
- Best when
- Software you depend on has nobody responsible for it, or response times are undefined.
- Not a fit when
- You want a one-time fix rather than someone on call.
- First thing you get
- An assessment of the system and agreed response times in writing.
What is software maintenance and support?
Software maintenance and support is the ongoing work that keeps a live system healthy after launch: monitoring, security patches, dependency updates, bug fixes and steady improvement. Without it, small defects pile up and advisories go unpatched. We run it as a retainer on a predictable cadence, including for systems someone else originally built.
Software does not hold still after launch. Dependencies get security advisories, platforms deprecate APIs, traffic patterns change, and the small defects nobody prioritised accumulate into something people route around.
A maintenance retainer means there is someone whose job it is to notice. We monitor, patch, fix, and improve on a predictable cadence — including for systems originally built by someone else, which is a large share of what we take on.
What this includes
- 01
Monitoring and alerting
Uptime, errors, and performance watched so you hear it from us rather than a customer.
- 02
Security patching
Dependency advisories tracked and applied on a defined schedule.
- 03
Bug fixing
Defects triaged and resolved against agreed response times.
- 04
Incremental improvement
Budgeted capacity each cycle for enhancements, not only firefighting.
- 05
Inherited system takeover
Onboarding onto software built by someone else, documenting as we go.
- 06
Backup and recovery
Backups verified by actually restoring them, which is the only test that counts.
Situations we see most often
Your developer is no longer available
The person or agency who built your system has moved on and nobody currently owns it.
You have no in-house engineering
Software is critical to your operation but you do not employ anyone to look after it.
Your team is fully committed to new work
Internal engineers are on the roadmap and maintenance keeps getting deferred.
You need defined response times
Someone contractually accountable when something breaks outside business hours.
What to know before you start
What does a maintenance retainer actually include?
Monitoring and alerting, so problems are noticed before users report them. Security patching and dependency updates on a schedule. Bug fixing against agreed response times. Verified backups, meaning restores are actually tested. And a share of the time for incremental improvements.
Unused capacity in a month goes to improvements rather than being lost, so a quiet month still leaves the system better than it was.
How do you take over a system someone else built?
With an assessment first. We get access to code, infrastructure and documentation, map how the system is deployed, review dependencies and security, and identify anything urgent, such as expired certificates, unpatched advisories or untested backups.
Urgent items are fixed first. Then the system moves into a normal support cadence, and we document what we learned so knowledge stops living in one person's head.
Why does software need maintenance if nothing is broken?
Because the world around it keeps changing. Dependencies receive security advisories, operating systems and browsers deprecate features, app stores change requirements, and certificates expire. Software that is not maintained does not stay the same; it slowly becomes insecure and harder to change.
The cost of catching up after years of neglect is almost always higher than the cost of steady upkeep.
What happens when something breaks at night?
Monitoring raises an alert the moment an error rate, failed job or outage crosses a threshold. Critical issues are handled under the response times agreed in your contract, starting with restoring service, then finding the root cause.
Every incident gets a short written summary: what happened, what was affected, what was done, and what will stop it recurring. Over time those summaries are the clearest record of how the system is becoming more reliable.
How are backups verified?
A backup that has never been restored is an assumption. We schedule restore tests, bringing a backup up in a separate environment and checking the data is complete and usable, and record the result.
That tells you not just that backups exist, but how long recovery would actually take, which is the number that matters on a bad day.
What drives the cost of a maintenance retainer?
Retainers are priced as a monthly allocation of engineering time. These factors decide how much time a system needs.
| Factor | Effect | Why it matters |
|---|---|---|
| Response times | High | Faster guaranteed responses for critical issues mean keeping capacity available, which costs more than scheduled fixes. |
| System size and complexity | High | More services, integrations and platforms mean more to monitor, patch and understand. |
| Condition at takeover | Medium | An inherited system with outdated dependencies needs catch-up work before it settles into routine upkeep. |
| Change volume | Medium | How many improvements you want each month sets the share of time beyond pure upkeep. |
| Compliance requirements | Medium | Audit logs, access reviews and documented changes add process to every fix. |
| Hosting responsibility | Low | Managing the infrastructure as well as the code adds monitoring and updates on the infrastructure side. |
What a typical engagement looks like
- 011–3 weeks
Discover
Process map
- 022–4 weeks
Design
Interactive prototype
- 03two-week cycles
Build
Working software each cycle
- 04ongoing
Ship & support
Automated pipeline
What we build it with
- Monitoring
- Uptime checksError trackingAlerting
- Security
- Dependency advisoriesPatch scheduleVerified backup restores
- Process
- Severity tiersAgreed response timesMonthly capacity
Questions we get asked
01Will you support software you did not build?
Yes — it is a significant part of what we do. We start with an assessment to understand the system and identify anything urgent, then move into a normal support cadence.
02What response times do you offer?
Tiered by severity and agreed in the contract. Critical production issues get the fastest response; cosmetic defects are batched into scheduled work. We set these against what your business genuinely needs rather than a standard table.
03How is a retainer priced?
As a monthly allocation of engineering time sized to the system and the response times you need. Unused capacity goes to improvements rather than being wasted.
04Can we cancel or change the retainer?
Yes. The allocation is reviewed with you and can be resized as the system's needs change. If you bring maintenance in-house, we hand over documentation and access in an orderly way.
05Do you maintain mobile apps as well as web systems?
Yes: OS updates, store requirement changes, dependency upgrades and crash monitoring for Android and iOS apps, alongside their backends.
06Do you provide reports on the system's health?
Yes. A regular summary of uptime, incidents, patches applied, work completed and anything we recommend addressing, so you can see what the retainer delivered without asking.
07Can the retainer include small new features?
Yes. Capacity not needed for fixes and upkeep goes to improvements you choose, so small features, report changes and usability fixes ship steadily without a separate project each time.
Adjacent capabilities
Tell us what you are building.
Share the problem and we will come back with an approach, a rough shape of the work, and what it would take to deliver it.