What Happens After Custom Software Goes Live?

The first few weeks after go-live are qualitatively different from the rest of a support relationship, because this is when issues that only appear under real usage volume and real, messy data surface for the first time — no amount of testing fully replicates production conditions. A stabilisation period, usually explicitly defined in the contract, is when the vendor is closely watching for exactly these issues and triaging them fast.

Not every issue found during stabilisation is a defect in the strict sense — some are workflow mismatches that only became visible once real staff used the system for real work, which is a normal and expected part of any launch, not a sign the project went wrong.

A warranty period covers fixing defects — the software not doing what was specified — typically for a fixed window after launch, at no additional cost. It does not typically cover new features, workflow changes, or adapting to a business process that's evolved since the original specification was written, even if those requests feel like natural extensions of the original build.

This boundary should be explicit in the contract before launch, because "is this a bug or a change request" is exactly the kind of question that causes friction when it's left ambiguous. A clear, written definition of what counts as a defect — the software failing to do what the agreed specification said it would do — resolves most of these disputes before they start.

Someone needs to own uptime monitoring (knowing the system is down before a customer tells you), backups (and, just as important, periodically testing that a backup can actually be restored), and administrative access to the hosting environment — and this ownership should be assigned explicitly rather than assumed to sit with whoever built the system.

Imagine a mid-sized private school that just launched a new admissions, fee-tracking and attendance system ahead of a new academic term. In that scenario, backups matter enormously — a fee-payment record or an attendance log lost to an unrecovered failure isn't a minor inconvenience, it's a real operational and reputational problem. Confirming, in writing, exactly who is responsible for backups and how often they're tested is worth doing before go-live, not after an incident.

Training doesn't end at launch — new staff will join after go-live and need the same grounding the original team received, which means documentation (not just a one-time training session) needs to exist and stay current as the system evolves. A system with no written documentation becomes entirely dependent on institutional memory, which is fragile the moment a key staff member leaves.

Requests for genuine enhancements — new functionality beyond the original scope — should be captured in a backlog and prioritised deliberately, rather than handled ad hoc as they arrive. This keeps the system evolving in a planned way instead of accumulating small, unreviewed changes that gradually make it harder to maintain.

A few months after launch is the right time for an honest review against the success measures agreed during discovery — is the software actually solving the problem it was built for, and is the support arrangement (response times, the quality of fixes, communication) actually working for the business. This review is easy to skip once the software is simply running, but it's the only reliable way to know whether the investment delivered what it was meant to, rather than assuming it did because no one's complained loudly.

If the review surfaces a genuine gap — response times slower than agreed, or the software falling short of an original success measure — raise it directly and in writing rather than letting it become background frustration. A support relationship that's working well for both sides usually stays that way because issues get named early, not because nothing ever goes wrong.