Acceptance, the first weeks after release, the difference between a bug, a revision and a new request, and how a live system is looked after.
In short
Before anything goes live, we agree how it will be accepted and check it against real cases. After release, Software Care or an ongoing service covers monitoring, checks and small fixes. Support runs 9am to 6pm on business days, and we reply by the next business day.
People don’t always ask about life after go-live in the first conversation. Once a deal gets serious, they always do. What happens when users find a problem? Who fixes it? Is that included? What if we want changes?
These are the right questions, and the answers should be agreed before launch, not discovered after.
Go-live should not be the first time your team sees the software working properly. Before work starts, we agree how each change will be accepted: the result expected and how it will be checked.
The work is then reviewed against real business cases. Where the setup allows it, that happens on a test copy of the system, with test accounts or protected sample data. At release, we plan how the system will be watched and recovered if something goes wrong, and record who approved the release and any risks that remain.
This matters after launch too. When the definition of “working” was agreed and checked beforehand, there is far less to argue about when something comes up later.
Real users do things no test plan predicted. They use unusual data, click in an unexpected order and rely on a report in a way nobody mentioned. A few issues in the first weeks are normal, and a period of stabilisation is part of any honest plan.
What should not be normal is confusion about who handles them and on what terms. That belongs in the agreement.
After launch, three very different things tend to arrive under the same name, “a fix”:
| What it is | How it is usually handled | |
|---|---|---|
| Bug | The software does not do what was agreed and accepted | Fixed against the agreed result |
| Revision | A change to something that works as agreed, because the need has changed | Agreed as a change, with its effect on timing and cost |
| New request | Something that was never part of the scope | Scoped separately, or added to an ongoing priority queue |
Sorting a request into the right column is often the whole conversation. It is also why an agreed acceptance check is so valuable: it is the reference that separates a bug from a revision.
Once software is live, it needs ongoing care: updates, monitoring, small fixes and someone who knows the system. That is what Software Care is for: monitoring, health and backup checks, small fixes and a monthly report, from RM1,500/month.
Larger changes and new features move through System Improvement or a separately agreed piece of work.
Whoever builds your software, agree these in writing before go-live:
A reliable release process makes all of this easier. For Chugai, website updates go live through an automated pipeline, the same way every time. The less manual the release, the less there is to go wrong after it.
Founder and Managing Director, Antdragon
Rosaan started Antdragon in 2020 to be the team that stays accountable once software goes live, and works with business owners on the systems they rely on every day.
Filed under Support and fixes
Most businesses only fully understand what they need once people start using the software. Why that happens, and how the way you pay for development makes it easier or harder to handle.
Rosaan Ramasamy · · 5 min read
A worksheet for the records, owners, access, errors, reconciliation and real-world tests behind a business system integration.
Rosaan Ramasamy · · 2 min read
A copyable brief that helps a software team understand users, workflows, priorities, constraints, dependencies and how you will accept the work.
Rosaan Ramasamy · · 2 min read
