Software maintenance services for software that is already live
Software maintenance is the work that starts after launch. Fixing defects. Patching dependencies. Keeping the product running as the platforms underneath it change. InApps runs it as a standing engineering team, with named engineers and a response clock on every severity. You get the same faces every month, not a ticket queue.
Trusted by engineering teams across 15+ countries - from startups to Fortune 500.
Six things we hear on the first call
Different products, same six problems. All six come from the same place. Maintenance was nobody's job.
The team that built it has moved on. Nobody left can say why the code does what it does.
Bugs get picked up by whoever is least busy. Nothing has an owner and nothing has a clock.
Dependencies are years behind. Every upgrade is now a project, because none of them happened.
Roadmap work stops whenever production breaks. Your best engineers are on the pager instead.
A vendor built it and left. Support is an email address and a two-week wait.
You are billed per incident, so a bad month costs more and no quarter can be forecast.
Software support and maintenance, and where the line sits
Shipped it, and now nobody owns it?
A standing team with a clock on it
Maintenance is everything that keeps working software working. Defect fixes. Security patches. Dependency and framework upgrades. Small changes as the business moves.
Support is the other half of it. Support answers the question. Maintenance changes the code. Most vendors sell one and invoice for both. We staff them as one team, so the engineer who takes the ticket is the engineer who writes the fix.
Some buyers call the whole thing software maintenance support, some call it application support. The label matters less than what the contract says about who fixes what, and how fast.
In scope every month
Whether or not anything broke.
- Defect fixes on anything already in production
- Security patching and CVE response
- Dependency, framework and runtime upgrades
- Small changes, from an agreed monthly block of hours
- Monitoring, alerting and on-call cover
- A written cause on every P1
Not in scope, and we say so at scoping
Each of these is a different engagement.
- A new product. That is custom software development
- A rewrite. Run a code audit first, then decide
- Engineers inside your own sprints. That is staff augmentation
- Building a test suite from zero. That is QA and test automation
- An infrastructure migration. That is a project with a plan, not a retainer
Each of those five has its own page, and the fit section says which one to read.
The four types of software maintenance
The standard splits it four ways, and the split matters when you buy. A retainer that only covers the first one will not hold past a quarter.
Corrective
Fixing what is broken. Defects found by your users, by monitoring, or by us. This is the part everyone budgets for, and it is rarely the biggest part.
Adaptive
Keeping up with the world outside your codebase. OS and browser releases, API deprecations, a payment provider changing its terms, a library going end of life.
Perfective
Small improvements to things that already work. A slow query. A screen that confuses people. A report nobody can export. Never a project, always noticed.
Preventive
Work that stops the next incident. Dependency upgrades before the CVE lands, dead code removed, tests written around the parts that keep breaking.
Four workstreams, one monthly fee
All four run every month. Three of them run whether or not anything broke, which is the whole difference between a retainer and a break-fix contract.
Incident response and defect fixing
On-call cover to the hours you need. Every incident triaged against the severity table below, reproduced before a line is written, fixed, tested and released. A written cause on anything that reaches P1.
Security and dependency upkeep
CVE monitoring across every dependency you ship. Patches batched into a scheduled release rather than merged the moment an alert fires. Framework and runtime upgrades planned before end of life, not after it.
Monitoring and reliability
Alerting on the things that should actually wake a human. Error rates, slow queries, failed jobs, queue depth. If your observability is thin, month one is spent putting the basics in rather than guessing.
Small change delivery
A fixed block of engineering hours each month for changes too small to be a project. Unused hours do not roll over, and we tell you when they are going unused rather than quietly billing for them.
Three ways to buy it
All three run from Ho Chi Minh City. Offshore software maintenance is where the economics work, because steady-state work does not need to sit in your building to be done well.
Retained pod
A fixed monthly fee, a named team and a response clock. Two to four engineers is typical. This is the default and it is what most single products need.
Dedicated team
Your own team, full time, reporting into your engineering lead. For estates with several products, or where you need a 24/7 rota. Read the dedicated team page for how that is staffed.
On-demand blocks
A block of hours drawn down as you need it. For products that are stable and rarely change. There is no response clock on this one, so it is wrong for anything revenue-critical.
What a severity means, and what happens next
Four tiers, agreed at scoping and written into the contract. The clock starts when the ticket lands, not when we get to it.
| Severity | What it means | First response | What we commit to |
|---|---|---|---|
| P1 Critical | Production is down, or data is at risk | Within 1 hour, around the clock | Continuous work until a workaround is live, then a written cause |
| P2 High | A core function is broken for many users | Within 4 business hours | Fix or workaround inside the same business day |
| P3 Medium | Something is wrong and there is a way round it | Within 1 business day | Scheduled into the next release, with a date |
| P4 Low | Cosmetic, or a small change request | Within 2 business days | Taken from the monthly change block, in the order you rank it |
You set the severity when you raise the ticket. If we disagree we say so on the ticket and it stays at your level until the two of us agree otherwise.
Keep it in-house, go back to the vendor, or retain us
| Criterion | InApps | In-house | Original vendor |
|---|---|---|---|
| Who does the work | A named team, the same engineers each month | Whoever is free that day | Whoever is on the account this quarter |
| Response clock | Per severity, in the contract | Best effort | Business hours, if your tier covers it |
| Effect on the roadmap | None. Maintenance is a separate team | First thing to slip when production breaks | None, but you cannot direct it either |
| Security patching | Scheduled monthly, not on alert | When somebody remembers | Only what they shipped |
| Cost shape | Fixed monthly fee against agreed scope | Senior salaries, taken off the roadmap | Per incident, or a percentage of licence |
| Where the knowledge sits | Documented as we go, and it is yours | In one person's head | With the vendor, by design |
| Getting out | 30 days' notice, handover included | Not applicable | Renegotiate, or rebuild |
How we take over software we did not write
Four weeks from repository access to holding the pager. Nothing about it is a discovery phase you pay for and never see again.
Read and inventory
We read the code before we touch it, and we write down what we cannot yet explain.
Shadow a real release
We watch your team ship once, end to end, and write the runbook from what happens rather than from what is documented.
Take the pager
We hold first line with your team on standby behind us. Not the other way round.
Run it, and report on it
One report and one call a month. It shows what we missed as well as what we hit.
Four roles, and you get their names
A maintenance team is not one generalist with a pager. These four are staffed from day one and you meet them at handover, before the rota goes live.
Maintenance lead
- Your single point of contact
- Severity calls and escalation, both directions
- The monthly report and the standing call
Senior software engineer
- Defect fixes and small changes
- Review before every merge, by someone who is not the author
- The parts of the codebase nobody documented
Platform engineer
- Pipeline, environments and releases
- Monitoring, alerting and the on-call tooling
- Dependency and runtime upgrades
QA engineer
- Reproduction before any fix gets written
- Regression cover around whatever we touched
- Release verification, on your definition of done
We work in your stack, not ours
Maintenance is the wrong moment to introduce new tools. We take over what you already run. We only ask for a change when a gap is causing the incidents.
Monitoring and alerting
Sentry, Datadog, Grafana, Prometheus, PagerDuty. Whatever you have, we take it over as it is. If there is nothing, month one goes on putting the basics in rather than on guessing.
Pipeline and patching
Your CI stays yours, whether that is GitHub Actions, GitLab CI or Jenkins. Snyk and Dependabot drive the CVE and dependency work, batched into a scheduled release rather than merged on alert.
Runtime and data
Docker, Kubernetes and Terraform where they are already in use. PostgreSQL, MySQL and the managed equivalents on AWS, Azure or GCP. We do not migrate anything to suit ourselves.
What sets the price of a maintenance retainer
There is no rate card, because a 40,000-line Rails app with one integration and a twelve-service estate with a payment provider in it are not the same retainer. Five things set the number. You get it after one call.
| Driver | What we ask | Why it moves the number |
|---|---|---|
| Surface area | How many services, repositories and third-party integrations | More surface means more that can break, and more to keep patched |
| Response targets | Business hours, extended hours, or a 1-hour clock on P1 | A round-the-clock clock needs a rota, and a rota needs more than two people |
| State of the code | Test coverage, documentation, how old the dependencies are | Code with no tests costs more to change safely, every single month |
| Monthly change budget | How many engineering hours you want for small changes | This is the part you control. Set it low and raise it once you see the demand |
| Observability | What monitoring and alerting exists today | If there is none, month one is instrumentation rather than maintenance |
Not sure which state your code is in? A code audit answers that in two weeks, and the issue register feeds straight into the retainer scope so you are not paying us to find the same things twice.
Ask the people who stayed
Every quote below is from a verified review. None of them were written by us.
“Clear expectations, rules that actually hold, delivered on time. And the people are genuinely easy to work with, not just professionally, but as humans.”
Worth the call, or worth a no
A retainer is the wrong shape for plenty of good problems. Here is where it works, and where we will point you somewhere else.
This works well if
- Your software is live, revenue depends on it, and nobody owns keeping it running.
- The team that built it has moved on, or the vendor has.
- Your engineers are firefighting instead of building the roadmap.
- You want a software maintenance company with a response clock, not an email address.
- You are billed per incident and cannot forecast a quarter.
This is not a fit if
- You need something new built. That is custom software development, and it is priced as a project.
- Nobody knows what is in the codebase yet. Start with a code audit, then retain us against the register.
- You want engineers inside your own sprints, on your own board. That is staff augmentation or a dedicated team.
- You need a test suite built from nothing. That is QA and test automation, and it is a project before it is maintenance.
- The product is being sunset inside six months. Pay per incident. It will be cheaper and we will say so.
Answered without the hedging
Not sure a retainer is the right shape?
Send the stack and roughly how many incidents you get a month. We will tell you what it would take to run it, including when the answer is that you do not need us.
Book a maintenance callWhat are software maintenance services?
How much does software maintenance cost?
What are the four types of software maintenance?
What is the difference between software support and software maintenance?
Can you maintain software your team did not build?
What response times do you commit to?
Is offshore software maintenance a security risk?
What happens if we want to leave?
Tell us what keeps breaking
The stack, roughly how many incidents a month, and what hours you need covered. We come back with a scope, a severity table and a monthly fee. If a retainer is the wrong shape for it, we will tell you that instead.