What Our 90-Day Warranty Covers

The test we apply

One question decides every warranty case: does the software do what the signed specification says it does? If the answer is no, it is a bug and we fix it free. If the answer is yes but you now want it to do something else, that is a change and we quote for it.

That sounds obvious and it is, but stating it in advance removes almost all the friction. Most warranty disputes in this industry are not about the fix — they are about which category the request falls into, argued after the fact by two people with opposite incentives.

What is covered

• Anything that errors, crashes or returns wrong output against the spec
• Behaviour that contradicts the written specification, however small
• Performance materially worse than what we agreed — if we said a report renders in under three seconds, we hold that
• Security defects in code we wrote, without a time limit in practice
• Broken behaviour caused by a routine dependency update we performed
• Data integrity problems traceable to our migration

There is no ticket allowance and no hours cap. If a covered defect takes forty hours to fix, it takes forty hours and costs you nothing.

What is not covered

• New features, and changes to agreed behaviour — these get quoted normally
• Breakage caused by a third-party API changing, though we will always tell you what it will cost to adapt
• Problems caused by changes made by another developer after handover
• Hosting, domain, licence and API usage costs, which were always yours
• Content, data entry and configuration you own
• Training beyond the handover sessions in the proposal

The line we care about most: if we misunderstood you, that is our cost. If you changed your mind, that is a change request. Both are legitimate; only one is free.

Response times inside the warranty

These are the targets we work to rather than a contractual SLA with penalties. If you need a contractual SLA with financial teeth, that is a support retainer and we will price one.

Why 90 days specifically

Because that is roughly how long it takes for real usage to surface the defects that testing does not. The first month exercises the happy paths, the second finds the edge cases, and the third is when someone finally uploads the file with the unusual characters in it.

Very few defects appear for the first time after 90 days of real use. The ones that do are usually seasonal — a year-end process, an annual report — and we handle those case by case rather than hiding behind the date.

What happens on day 91

Nothing dramatic. Most clients move onto a maintenance retainer covering dependency updates, monitoring, security patches and a block of change hours. Some do not, and call us when they need something — that is fine too, and there is no penalty for having left.

What does not happen is the software becoming unsupportable. You own the code, the documentation and the deployment pipeline, and another developer can pick it up. That is the point of writing things down.

Frequently asked questions