Application Bug Fixes in New Zealand

Describing it well is worth more than anything else

This is the one part of the process entirely within your control, and it moves the price more than any negotiation.

For each fault, write:

1. What you did. The steps, in order, precisely enough that someone else could follow them.
2. What you expected.
3. What happened instead, with the exact wording of any error message and a screenshot.

Then add:

• When it started, and whether anything changed around then.
• Does it happen every time, or occasionally?
• Who is affected — everyone, one office, one customer, one browser?
• Is there a workaround people are using?

A well-described bug can frequently be diagnosed before anyone opens the code. "The system is broken" reliably costs more, because the first several hours are spent establishing what you already knew.

Rank by cost, not by irritation

Every backlog is ranked by who complained most recently. That is rarely the right order.

For each item ask: what does this cost per month, in money or in time? A cosmetic fault on a screen used forty times a day by six people may be costing more than an alarming-looking error nobody hits.

Then split the list:

• Costing money now — wrong calculations, failed payments, anything customers see.
• Costing time — workarounds people do daily without mentioning them any more.
• Annoying — genuinely irritating, costing nothing.

Give the developer the list in that order with the reasoning. It makes a fixed budget go considerably further, and it stops the cheapest bugs being fixed first simply because they are easiest.

Diagnosis is work, and someone pays for it

Nobody can price a fix for a fault they have not investigated. Two honest ways to handle it:

• A capped investigation. A fixed fee to find the cause and quote the fix properly.
• Hourly with a ceiling you agree in advance, and a phone call before it is reached.

What should make you cautious is a firm fixed price for a fault nobody has looked at. Either it is padded against the worst case, or it will be revised once work starts. Being told honestly that the cause is not yet known is better than either.

Insist on a test with every fix

This is rarely offered and should be a standing condition of any bug work you buy.

A regression test means this specific fault cannot quietly return in six months when somebody changes nearby code. It adds a small amount to each fix, and it compounds: after twenty bugs you have twenty tests wrapped around exactly the parts of the system that have proven fragile.

It also changes the conversation with the developer, because a fix that cannot be tested is usually a sign the code needs restructuring — which is worth knowing before you buy nineteen more fixes.

Watch for the same bug arriving repeatedly

If the same kind of fault keeps recurring in different places — the same calculation wrong in three screens, the same crash with different data — you do not have a list of bugs. You have one design problem producing symptoms.

Fixing them individually is expensive and never finishes. Ask each developer, after they have looked: are these separate faults, or one cause? A developer who tells you the honest answer has just talked themselves out of twenty small invoices, which is worth noticing.

Be careful with production data

Reproducing a bug often needs realistic data, and the quick answer is to give the developer a copy of the live database. That copy contains your customers' personal information, and the Privacy Act applies to it wherever it ends up.

Better options, in order:

• Reproduce it with made-up data that has the same shape.
• Use an anonymised extract with names and contact details replaced.
• Give access to a controlled environment rather than a copy that leaves your systems.

If a full copy really is necessary, agree in writing where it will be held, who can see it, and when it will be deleted. Ask the question during quoting — the answer tells you a lot about the firm.

Consider a retainer instead

If you report more than two or three faults a month, per-bug pricing works against you. Every small irritation needs a quote and an approval, so the small ones never get fixed and slowly accumulate into the backlog you are now reading about.

A retainer with agreed response times gets them handled as they arise and keeps a developer familiar with your system, which makes every fix faster. Below that volume, paying per fix is perfectly reasonable.

Comparing five quotes

Read for:

• Who asked a question about the fault that you had not considered?
• Who was clear about what their price covers if the cause is different?
• Who offered to add a test with each fix?
• Who asked how they would get realistic data safely?
• Who suggested some of these are one underlying problem?

Send the list, ranked by what each costs you, with steps to reproduce and screenshots. Developers who do this work will tell you within a paragraph which items are quick and which are hiding something.