Software Maintenance and Support After Launch: How to Judge a Partner's Continuity

The riskiest part of a custom software project is not the build. It is the years after go-live, when the launch team has moved on, the dependencies start to age and the first serious incident arrives on a Friday evening. When a buyer hesitates to hand a large project to a mid-sized firm, this is usually the real question underneath: will someone who understands this system still be looking after it three years from now?

Vendor size answers that question less well than it seems. What answers it is how maintenance and support are structured, and that structure can be checked before you sign.

What maintenance and support actually has to cover

"Support" in a proposal often means a bug-fix line and an hourly rate. A system that runs a real business needs six things, and each one has a different owner and rhythm.

1. Corrective work. Incidents and bugs, handled against agreed severity levels with defined response and resolution targets.
2. Adaptive work. Keeping the system working as the world around it changes: operating system and browser updates, app store policy changes, third-party API versions, new regulatory requirements such as KVKK or GDPR updates.
3. Preventive work. Security patches, dependency upgrades, performance tuning and paying down technical debt before it turns into an outage.
4. Operations and monitoring. Uptime and error monitoring, alerting, backups and, just as important, restore tests that prove the backups work.
5. Evolution. New features and changes requested by the business, planned as a roadmap rather than a stream of ad hoc tickets.
6. Knowledge continuity. Documentation, runbooks, architecture decisions and a team where more than one person understands every critical part.

The first five are what most contracts describe. The sixth is what decides whether the other five survive a resignation, a reorganisation or a change of partner.

Where continuity actually breaks

One person holds the system

The most common failure is not technical. A single developer knows how the payment flow, the integration with the ERP or the deployment pipeline really works. When that person leaves, on either side, the system does not stop, but every change becomes slow, risky and expensive.

Support is negotiated after launch

When the support model is left for later, it is usually designed under pressure, after the first incident. Severity levels, response targets and working hours get defined by whoever shouts first, and the build budget has already been spent.

Dependencies age quietly

A system that "just works" is still built on frameworks, libraries and cloud services that release updates and end support. Skipping updates for a year looks like saving money. It turns into a forced, large upgrade the day a security issue or an app store deadline makes it unavoidable.

Nobody watches the system

Without monitoring and alerting, users become the monitoring. Outages are discovered through complaints, and root causes are reconstructed from memory instead of logs.

The build team disappears

Many vendors staff a project with their strongest people for the build and hand it to a separate, rotating support pool after launch. The people answering your tickets have never seen the architecture they are patching.

The roadmap has no owner

Change requests arrive from several departments, nobody prioritises them, and the system grows in directions no one planned. Over time it becomes harder to maintain, not because of age but because of unmanaged change.

The easy answer, and why it does not hold

The easy answer is to pick the largest vendor on the shortlist. Size does bring real things: deeper benches, formal processes, financial resilience. But a large firm can also staff your account with a rotating team that changes every quarter, and the continuity you were paying for exists on the org chart rather than on your system.

The honest version is that a mid-sized firm carries a real risk too: if the knowledge of your system lives in two people, that is a concentration risk, and you should ask how it is managed. In both cases the useful question is the same. Not "how big are you?" but "who exactly will look after this system, what happens when one of them is away, and how would I know?"

In the 400+ projects we have delivered since 2017, the systems that aged well had one thing in common: support was designed during the build, by the people building it, and written into the contract before launch.

What to check before you sign

Team structure. Ask for the named core team that will stay on the system after launch, and a named backup for each critical area: backend, mobile, infrastructure, integrations. "A support team" is not an answer.

Process maturity. Code review on every change, automated tests on critical flows, a CI/CD pipeline that anyone on the team can run, and runbooks for common incidents. These are what let a second engineer step in without archaeology.

Support model and SLA. Severity definitions with examples, response and resolution targets per severity, support hours and the escalation path out of hours. Response time and resolution time are different promises; check which one is being made.

Monitoring and reporting. What is monitored, who receives alerts, and what you see each month: incidents, response times, dependency status, open risks.

Update policy. How often dependencies and frameworks are reviewed and upgraded, and whether that work is included in the support scope or quoted separately.

Handover and exit. Source code, documentation and access that let your own team or another partner take over. We cover this in detail in Vendor Lock-In in Custom Software: What You Should Own, and How to Keep It.

Roadmap ownership. Who on your side and who on the partner's side decides what changes next, and how often that conversation happens.

A phased plan for support that lasts

The timeline below assumes support is planned as part of the build. Adjust the lengths to the size of the system; the order matters more than the exact weeks.

Weeks -4 to 0: design support before go-live. Agree severity levels and SLA targets. Set up monitoring, alerting and backups, and run the first restore test. Write runbooks for the incidents you can already predict. Make sure a second engineer has reviewed and deployed every critical component.

Weeks 1-4: hypercare. The build team stays close to the system. Incidents are triaged daily, quick fixes are released frequently, and every recurring issue gets a root cause and a runbook entry.

Weeks 5-12: move to steady state. Shift from daily triage to the agreed SLA. Run the first dependency review and security patch cycle. Hold the first monthly report and agree the first roadmap priorities with the business.

Every quarter: health review. Review incident trends, dependency age, security status, documentation gaps and team coverage. Decide what technical debt to pay down next, and confirm that every critical area still has a backup engineer.

Three things not to do

1. Do not treat support as the line to cut. A lower build price with a vague support clause tends to cost more over the life of the system than a priced, structured support plan, because the work still happens, only later and under pressure.
2. Do not let one person become the system. On your side and on the partner's, every critical area needs at least two people who can change it safely.
3. Do not postpone updates because everything works. Small, regular upgrades are cheap. One forced upgrade after two quiet years rarely is.

Frequently asked questions

What is included in software maintenance and support?

Software maintenance and support covers fixing bugs and incidents, adapting the system to changes in platforms, APIs and regulation, preventive work such as security patches and dependency upgrades, monitoring and backups, and planned feature changes. A good support agreement also covers knowledge continuity: documentation, runbooks and more than one engineer who knows each critical part of the system.

What should a software support SLA include?

A software support SLA should define severity levels with concrete examples, response and resolution targets for each level, support hours and the out-of-hours escalation path. It should also state what is monitored, how incidents are reported and whether dependency updates are included or quoted separately.

Is it risky to give a large project to a mid-sized software company?

The risk depends less on company size than on how the project is staffed and supported. Ask for a named core team that stays after launch, a backup engineer for each critical area, documented processes and a written support model. A mid-sized firm with these in place can offer more continuity than a large one that rotates staff across accounts.

How much does software maintenance cost?

Maintenance cost depends on the size and age of the system, the number of integrations, the SLA level you need, how often dependencies are updated and how much new feature work is expected. The most reliable way to control it is to define the support scope during the build, so that preventive work is planned instead of paid for as emergencies.

Can we take software maintenance in-house later?

Yes, if the system was built for it. That requires full ownership of the source code and infrastructure, current documentation and runbooks, and a planned handover period in which your engineers work alongside the partner's team. Many companies use a hybrid model in which their own team owns the roadmap and the partner handles operations and specialised work.

Planning support for a system you are about to build?

If you are evaluating partners for a large project, we can walk through how support, team continuity and handover would work for your system before any contract is signed. Talk to our team.