The work after launch is still engineering.
Software that runs the business keeps needing upgrades, security work, integrations and fixes at the cause — and that work competes with the roadmap every sprint. This is ongoing engineering capacity for the systems you already depend on.
The system works. That is exactly the problem.
A product in production is never finished. Dependencies age, integrations change upstream, data grows past what the queries were written for, and the list of small things users keep asking for gets longer every quarter.
None of it is urgent enough to win against the roadmap, and all of it gets more expensive the longer it waits. That is the work this engagement exists to hold.
The work that never reaches the sprint.
Bugs that keep coming back
The ones that get patched at the symptom because nobody has had time to find where they actually start.
Dependencies falling behind
Libraries, frameworks and runtimes that were current at launch and are now two majors back, with each upgrade harder than the last.
Security work nobody scheduled
Advisories, patches and the credentials that were never rotated. Work with no visible output until the day it has one.
Performance that degraded quietly
Queries that were fine at ten thousand rows and are not at ten million. Usually a data access problem, not a hosting one.
Integrations that break upstream
Third-party APIs deprecate endpoints and change payloads on their schedule, not yours.
Infrastructure that accumulated
Environments, pipelines and cloud resources added one at a time, none of them wrong on their own.
Technical debt with interest
The shortcuts that were correct under the original deadline and now make every change cost more than it should.
Improvements that never make the sprint
The small things your users ask for repeatedly, which always lose to the roadmap and never stop being asked for.
This is engineering, not IT support.
“Software maintenance” gets used for two completely different things, and buying one when you needed the other is an expensive mistake. Here is which one this is.
Engineers, not agents
The people doing the work read the code, run the tests and open the pull requests. There is no first-level layer between you and them summarizing what happened.
The codebase, not the desktop
This is work inside your repository, your infrastructure and your deployment pipeline. End-user IT, workstations, accounts and office systems are somebody else's job.
Engineering judgement, not ticket throughput
The value is in deciding what to fix at the cause instead of at the symptom, and saying which items on a backlog are not worth doing. Counting closed tickets measures the wrong thing.
A partner in the system, not a vendor around it
We learn the system deeply enough to change it safely. That takes real time at the start, and it is the reason a change in month six costs less than the same change in month one.
From an existing system to one that keeps improving.
The first weeks are mostly reading. A system you do not understand is a system you cannot change safely, and the cost of learning it properly is paid back every time something has to move quickly afterwards.
Understand the system
Code, data model, dependencies, deployment, environments and whatever documentation exists. Also the parts everyone already knows are fragile.
Map risk and priority
What is most likely to break, what costs most when it does and what is blocking the business. These are rarely the same list, and the difference is the useful part.
Agree the engineering scope
What the engagement covers, who prioritizes and how work is accepted. Written down before it starts, so nobody is inferring it in month three.
Work inside the codebase
Your repository, your branching model, your review process and your release path. Changes arrive the way your team already ships them.
Review continuously
What was done, what it cost, what it revealed and what should come next. The priorities move because the system teaches you things.
Three ways to contract the capacity.
Not plans, and not blocks of hours. These are shapes an engagement can take, scoped against your system and your priorities — and they change when the situation does.
Ongoing engineering capacity
Recurring capacity reserved for a system, working from a backlog you prioritize. Best when the software matters enough that the work is never going to end and you would rather have it handled than queued.
Fits when the system is active and the demand is continuous.
Defined maintenance scope
A specific set of technical work agreed for a period or an objective — a framework upgrade, a security pass, a performance problem, a set of integrations. It ends when the work does.
Fits when you know what needs doing and want it done without hiring for it.
Product evolution
Maintenance and new development in the same engagement, because on a live product the line between fixing and improving is drawn by the backlog, not by a contract.
Fits when the system is still growing and the roadmap is real.
There is no tier list and no monthly package. What the engagement covers, who prioritizes and how it can be ended are agreed in writing before it starts.
Modernize without betting the business on a rewrite.
Most systems worth modernizing are systems people depend on today. Replacing one wholesale means running two versions of the truth for a year and hoping the cutover lands — which is why so many rewrites are abandoned halfway with both systems now needing maintenance.
Start where the risk is
The oldest part of a system is not always the most dangerous one. We look for what is most likely to break, most expensive to change and most central to the business — usually not the same component.
Change it in pieces that ship
A module, a data model, a dependency, a deployment step. Each piece goes to production on its own and can be stopped without leaving the system half-migrated.
Keep the current system working throughout
The business does not pause for the rewrite, because there is no rewrite to pause for. Old and new paths coexist for as long as they need to.
Say when a rewrite is genuinely the answer
Sometimes it is — and then it is a product engineering engagement with its own scope, not something that should hide inside a maintenance retainer.
Systems we can operate responsibly.
We take on systems in the stack our engineers actually work in — Node.js, NestJS, Python, TypeScript, React, Next.js, Flutter, PostgreSQL and AWS — plus the infrastructure and integrations around them.
If your system is outside that, say so early. The assessment will tell us whether we can maintain it responsibly, and we would rather answer that before an engagement than after.
- We read the system before we agree to be responsible for it
- We say no to systems we could not change safely
- We tell you which backlog items we think are not worth doing
- We modernize in pieces, and say plainly when a rewrite is the honest answer
- We commit to engineering work, not to uptime, response times or an incident rotation
Before you send the first message.
Do you maintain software you did not build?
Often, yes — but not automatically. We assess the codebase, the deployment model, the test coverage, the documentation and the operational risk first. If we cannot take responsibility for a system safely, we say so before an engagement starts rather than discovering it in the first incident. That assessment is useful to you either way, including if you take it elsewhere.
Can you take over an existing codebase?
Yes. It starts with reading what is there and giving you an honest account of it: what is solid, what is fragile, what is undocumented and what would need to change before the system can be worked on at a normal pace. Taking over a codebase without that step is how a maintenance engagement turns into an emergency.
Do you work with legacy systems?
Yes, when we can operate them safely. Age is not the problem — a well-structured system in an older framework is easier to maintain than a recent one with no boundaries. What we look at is whether the system can be built, tested and deployed reliably, and whether the technology is one our engineers can work in responsibly.
Is this 24/7 production support?
No. This is engineering capacity, not a staffed operations desk: there is no on-call rotation and no incident line, and saying so now is cheaper for both of us than discovering it during an outage. What this engagement does is make incidents rarer — fixing causes instead of symptoms, upgrading what is overdue, and improving what fails under load.
Can the retainer include new features?
Yes, and it usually should. On a live product the line between fixing and improving is drawn by the backlog, not by a contract clause. What matters is that you decide the balance between the two and can change it when priorities move.
Can we start with a technical assessment?
Yes, and it is often the right first step. A short engagement to read the system and report on its state, its risks and what maintaining it would actually involve — ending in something you can act on, including with another partner.
Who prioritizes the backlog?
You do. We bring the technical read: what is urgent because it is a risk rather than because it is loud, what is cheaper to do together, and what we think is not worth doing at all. The order is yours to set.
Can maintenance become a dedicated team later?
Yes, and it is a natural progression. When the work stops being maintenance and becomes a continuous roadmap across several roles, a dedicated team is the better structure for it, and moving from one to the other is a commercial conversation rather than a restart.
Rebuilding rather than maintaining?
If the honest answer is that the system needs to be built again, that is a different engagement with its own scope.
Product EngineeringGrown past maintenance?
When the work becomes a continuous roadmap across several roles, a team is the better structure for it.
Dedicated TeamsAn agency maintaining client software?
Change requests and technical continuity after delivery, under your brand and your client relationship.
For AgenciesWhat is the system, and what is it costing you?
Tell us what it does, roughly how old it is and what keeps going wrong. We will tell you what we would look at first — and if we do not think we can maintain it responsibly, we will say that instead.