Custom software starts earning its keep after users have it. We aim to put working software in people's hands every fortnight during the build. The first quarter after go-live is the same idea, with a real roster and real volume.
The first fortnight
Someone has to own the queue. Who the floor calls when a screen is wrong, a login fails, or a report is empty. Mature partners have a real answer for what happens when something breaks at 11pm. Get that path in writing before launch day, including response times you have actually agreed.
Expect a burst of small issues. Data that looked clean in testing is messier once the live records are in. A role designed for one person is often shared across a roster. The useful response is a short list, triaged, with the ones that block the day fixed first.
Training has to happen on the roster. We have seen software work fail because the training never happened, or because the people using the tool did not trust it. A PDF in the inbox does not replace that time.
Logs, metrics, and error tracking should already be on. We treat observability as part of the first version.
The rest of the first month
Look at usage against the outcome you agreed. Every release we do is meant to be tied to an outcome and reviewed against it. If a screen nobody opens was a big part of the brief, treat that as information. Change the screen, or drop it.
Small feature work belongs here. The work that does not justify a project and still matters to the people on the tools. Tweaks, labels, a filter the floor asked for in week two.
Performance will move as data grows. What worked at the volumes in test will not always hold. Watch the slow lists and the jobs that run overnight.
The quarterly check-in
Our maintenance retainers include a quarterly review of usage, technical debt, and the roadmap. Even if you are not on a retainer, run that meeting. Bring the people who use the system.
Ask what broke, what they stopped using, and what they now do in a spreadsheet again. Shadow tools coming back after go-live usually means the software missed a step in the operation.
Agree the maintenance beat. Monthly dependency and OS upgrades with regression testing is the cadence we use for most products. Quarterly is usually too slow. Weekly is usually more than you need.
Who owns the code and the cloud accounts should already be you. If it is not, fix that in this quarter. Offboarding is harder once the system is in the week.
What operations should hold
Hold a named product owner in the business, even if their time is limited.
Keep a written incident path and a habit of short post-mortems. We include incident response and prevention in support work so the same failure is less likely to repeat.
Keep a view of cost that includes hosting, observability, and the people time to run the thing. First-year hosting and analytics is easy to forget in the build quote. Plan for it.
If you want a senior view of a system that has just gone live, or one that has been drifting, book a discovery call.
