Software Maintenance After Launch: Bugs vs Change Requests, and What a Retainer Should Cover

Two weeks after go-live, the owner of a new business system sends a WhatsApp message: "The report is wrong, and I also need it to show last year's figures." The developer replies that the second half is a new feature and will be quoted. The owner replies that the whole report was always meant to work. Both are partly right, and neither can prove it, because nobody wrote down what "the report" should do or how a problem would be classified.

This guide is for a business owner who has had a custom system or app built, or is about to, and wants to know what to expect once it is live. It explains the difference between a bug and a change request, how to report each so it can be acted on, what a maintenance retainer should cover and exclude, and how to review it each month. It is general guidance, not legal advice, and it does not describe any one supplier's terms.

Bugs, change requests and the two things that look like them

Almost every after-launch complaint falls into one of four groups. Sorting it correctly matters because each group is handled, and often billed, differently.

• A bug (defect). The system does not do what was agreed. The behaviour is written in the signed-off scope, quote or acceptance checklist, and the live system departs from it.
• A change request. You want something that was not agreed: a new field, report or approval step. The system works as specified.
• A usage question. The system works as agreed, but someone does not know how to use it or entered something wrongly. The fix is training or a clearer screen.
• An outside change. Something around the system moved: a payment provider altered its connection, a browser update changed behaviour, a hosting renewal lapsed.

The last row shows why the line is sometimes blurry. Where the agreement is silent or ambiguous, the honest label is "unclear, to be decided", and the decision should be recorded, not argued in a chat thread.

A one-minute test: was it agreed?

You do not need technical knowledge to classify a problem, only the agreed baseline and a few questions.

1. Find the baseline. The signed-off scope, the quote's description of the work and the checklist you ticked at user acceptance testing. The accepted version is the starting line for everything after.
2. Does it say how this should behave? If yes and the live system differs, report a bug and quote the line you rely on.
3. Is it silent? Then it is a change request, however obvious it feels. "Obvious" is where arguments begin.
4. Is it unclear? Ask the developer to propose the intended behaviour and confirm it in writing before work starts.

Why you agree the definition before the build

The label often decides who pays, and money turns a neutral question into an argument. The cheapest fix is to settle the rules while nobody has a stake in the answer.

• Define a bug in writing. For example, "behaviour that differs from the signed-off specification or acceptance checklist", with three or four examples from your own business.
• Define a change. Anything new, or any alteration to approved behaviour, is quoted before work begins.
• Say who decides grey cases, and how fast. A named person on each side, and a rule such as "unclear items are decided and recorded within the week".
• State the baseline. The system as accepted on a recorded date, with the acceptance checklist attached.
• State the free fix period. Often called a warranty or defect-fix period. Vendor pages describe periods from about a month to a few months, but there is no standard, so what matters is that it is written, when it starts (go-live or sign-off) and what happens when it ends.

These points belong in the quote or contract, which is why comparing quotes should include what each says about life after launch. How changes are priced links to fixed price versus hourly rate, and the schedule around go-live to how long a custom system takes.

How to report a bug so it can be fixed

A developer cannot fix "it's broken". A good report lets someone reproduce the problem in minutes without calling you:

• What you did. The exact steps: "Opened Quotes, picked Q-0231, clicked Convert to invoice."
• What you expected, ideally with the agreed line it contradicts.
• What happened. Copy any message word for word.
• Evidence. A screenshot showing the whole browser window, or a short screen recording.
• When and how often. First noticed, every time or sometimes, one user or everyone.
• Device and browser. Phone or computer, and which browser.
• Who is affected, and how urgent. Use a scale agreed in advance.

Use the scale honestly. If everything is "stopped", nothing is. A good report reads: "12 November, 10:40, laptop, Chrome. I clicked Convert to invoice on quote Q-0231 and expected an invoice with the same lines. A red message said 'Something went wrong' and nothing was created. Screenshot attached. It happened three times, and a colleague sees it too. We cannot bill this customer today, so it is high."

How to describe a change request

Describe the problem, not just the screen you imagine. "Add a column for last year" leaves the developer guessing. "Every Monday our sales manager compares each month with the same month last year, using a spreadsheet" lets them find the simplest way to meet the need. Include the outcome you need, who uses it and how often, what workaround it replaces, how you will know it works (a sentence you can check) and any deadline.

Expect a written answer before work starts: whether it is feasible, what it affects, how long it takes and what it costs, or how many included hours it uses. If the answer is "yes" in a chat message, ask for it in the log too. Verbal approvals are the main source of bills nobody remembers agreeing to.

Keep one running list

Problems, ideas and questions pile up in WhatsApp, email and phone calls. Pick one list, such as a shared spreadsheet, and put everything there. It also gives you the facts for your monthly review and for any later disagreement.

One person on your side owns the list and reads every new line. An item closes only when you have tested the fix yourself, the same principle as the final check before acceptance.

Why software needs maintenance when nothing seems to change

A system you do not touch does not stay still. Browsers and phones update, the software components it is built from release security fixes, connected services change their rules, and your data grows. Engineers commonly group the work into four kinds: corrective (fixing faults), adaptive (keeping up with the environment), perfective (improving what exists) and preventive (security updates, backup checks, monitoring). A retainer should say which of these it includes. Neglect is not free, because small faults left to accumulate make each later change slower and riskier.

What a maintenance retainer should cover

A retainer is an agreement, usually monthly, under which a supplier keeps your system healthy and responds when you need help. A good one is specific. Look for each of these in writing:

• Bug fixing. Whether faults are fixed within the retainer, from what date, and how the "was it agreed?" test is applied.
• Small changes. A stated number of hours, how bigger requests are quoted, and whether unused hours expire or carry forward.
• Security and platform updates. Who applies updates to the framework, libraries and server software, how often, and how they are tested before going live.
• Backups and restore tests. What is backed up, how often, where copies are kept and evidence that a restore has been tried. A backup nobody has restored is a hope, not a safeguard. The website backup guide explains the principle.
• Monitoring. What is watched (availability, errors, disk space, certificate expiry), who is alerted and what happens next.
• Renewals. Hosting, domain, SSL certificate and any paid third-party service: who tracks the dates, who pays, and whose name each is in. Lapsed renewals are a common cause of avoidable outages.
• A named contact. A person, a backup, and a route for urgent matters.
• Response expectations. Hours of cover, time to acknowledge and time to start work for each urgency level, and what "resolved" means. Acknowledging is not fixing.
• Hours and extra work. What is included monthly, how extra work is quoted and approved before it starts, and how hours used are reported.
• Handover and exit. Documentation, access and the code, as covered in who owns custom software source code, so ending the retainer does not strand you.

Equally important is what it excludes, and the exclusions should be visible before you sign. Typical ones are new features and larger changes (quoted separately), faults caused by third-party outages or by someone else's changes to the system, training for new staff and data clean-up, a redesign or major platform move, your own devices and network, and third-party licence fees unless passed through at a stated amount.

A retainer for a website is a related but different product. Website maintenance cost in Malaysia and why a website needs ongoing maintenance cover that, and a staging copy helps there too. A custom system has its own database, logins, business rules and integrations, so its list is different.

Questions to ask before you sign

• How do you define a bug and a change request? Please give three examples from my business.
• What is the free fix period, when does it start and what happens after it ends?
• How many hours are included, what happens to unused hours, and how is extra work approved?
• What is your response for each urgency level, in working hours, and who covers when my contact is away?
• How and how often are updates applied, and what was the last backup restore you tested?
• Who tracks and pays for renewals, and in whose name are they?
• Who can see my live data, and how is access limited?
• What do I receive on exit, including the code and documentation, and what is not covered?

Signs a retainer is too thin or too vague

• No definitions. "Support" and "maintenance" are used loosely, with no line between bug and change.
• No response expectations, or only a promise to reply "as soon as possible".
• Unlimited everything. Unlimited changes at a fixed monthly price, with no way to see what is done, usually ends in arguments about what is reasonable.
• Nothing on updates, or backups with no restore test.
• No named person, only a general inbox or chat group.
• Accounts in the supplier's name, such as your domain, hosting or app store account.
• No exclusions and no exit terms. Limits and lock-in hidden in other documents.

A simple monthly review routine

Set a recurring 30-minute slot, with the supplier's contact if there is a monthly summary. Use the same agenda each time.

1. Read the list. What is new, what is open, what has waited longest? Re-sort "unclear" items and record who decided.
2. Check the hours. Compare hours used with hours included, and look at the largest items.
3. Look for repeats. The same complaint three times suggests a change, training or a root-cause fix.
4. Check the dates. Renewals due in the next 90 days, expiring certificates, a fix period about to end.
5. Ask for evidence. Have updates been applied, and has a restore been tested lately?
6. Decide next month's work. Choose what the hours go to and note what you declined.

Once or twice a year, ask whether the system still fits how you work. If not, that is a bigger-project conversation.

Common mistakes

• Treating every wish as a bug. It erodes trust and slows the real faults.
• Reporting in voice notes only. Nobody can search them, and details get lost.
• Letting the fix period lapse unnoticed. Diarise the end date and test everything shortly before it.
• Agreeing to changes in chat and forgetting the bill. Get the quote in writing first.
• Closing items you have not tested.

Where Gotka Technologies fits

Gotka's App & System Development service builds mobile apps, web apps and business systems, from an indicative RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once your needs are scoped. This guide does not describe any Gotka support terms, fix period or retainer, so ask any supplier, Gotka included, to put those in writing before you sign. If you are still choosing a builder, see freelancer, in-house developer or software company and what to prepare before your first conversation. Gotka also offers optional monthly Care plans for websites, described on the website care page; they are not a software-system retainer. You can reach the team through the contact page.

Key terms used in this guide

• Bug (defect): behaviour that differs from what was agreed.
• Change request: a request to add or alter behaviour that was not agreed.
• Baseline: the accepted version of the system and its signed-off scope.
• Warranty (defect-fix) period: a stated period in which the builder fixes bugs without a separate charge, as the contract defines.
• Retainer: a recurring agreement, usually monthly, to maintain and support a system.
• Restore test: recovering a backup to prove it works.
• Workaround: a temporary way to do the task while a fault is repaired.
• Exclusion: work the agreement states is not covered.