A software warranty on custom development should cover defects against the acceptance criteria you agreed before the build, fixed at no charge, for a fixed period after launch. A decent one runs at least a full business cycle (about 90 days) and lists its exclusions plainly: new features, changes by other developers and third-party outages.
A week after launch, a customer finds that the booking form fails when their name has an apostrophe in it. Who pays to fix it? If your contract has a clear warranty, the answer takes one message. If it does not, it can take a week of polite arguing.
Key Takeaways
- A warranty covers bugs: the software not doing what was agreed. It does not cover new features.
- It should run for a fixed period after launch. We use 90 days on our own builds.
- The acceptance criteria written before the build are what decide whether something is a bug.
- Know the exclusions: changes by other people, third-party outages, and new requirements.
What Should a Software Warranty Cover?
A good software warranty covers defects against the agreed acceptance criteria, found within a set period after the project is completed, fixed at no charge.
In plain terms:
- A feature that was agreed does not work.
- A feature works in normal cases but breaks in a case the criteria covered.
- Something that worked at acceptance stops working without anyone changing it.
On our software factory projects, the warranty is 90 days from project completion, and it covers functional bugs against the agreed acceptance criteria. It does not cover new feature requests or scope additions.
What Does a Software Warranty Usually Exclude?
| Excluded | Why |
|---|---|
| New features or changed requirements | That is new work, priced as a change |
| Changes made by someone else | The builder cannot warranty code they did not write |
| Third-party outages | If a payment provider or email service goes down, it is not a defect in your app |
| Problems from misuse or unsupported setups | For example, a browser version nobody agreed to support |
| Content and data you entered | Typos in your prices are not bugs |
| Hosting and running costs | Those are ongoing, not part of the build |
The exclusion that surprises owners most is the second one. If another developer edits the code during the warranty period, the original builder may reasonably refuse to cover anything touched. If you plan to bring someone else in, agree how that works first.
The Gray Area
Some issues are not clearly bugs or changes. The typical example: "it works as written, but the way it works is annoying." A report that takes 40 seconds to load. A button that is technically on the screen but hard to find.
The acceptance criteria decide these. If the criteria said "the report loads in under 5 seconds," a 40-second report is a bug. If they said nothing about speed, it is a change. This is the best reason to write criteria carefully before the build, including a few that cover speed, mobile use, and error messages. See how to review a software milestone before you pay.
How Long Should a Software Warranty Last?
Long enough for real users to use every part of the app at least a few times. For most small business apps, that takes weeks, not days, because some features run only monthly (invoices, reports, renewals). A warranty shorter than one full business cycle leaves those features untested by real use.
Ninety days covers a full quarter, which is why we use it. After that, fixes and small changes usually move to a maintenance arrangement. Ours are monthly retainers covering bug fixes, security patches, and minor enhancements, with response times from 4 hours for critical issues to 3 business days for minor requests.
How To Use a Warranty Well
- Report issues in writing, with what you did, what you expected, and what happened.
- Report early. A bug found on day 80 and reported on day 95 is a harder conversation.
- Keep a log of every issue and its status. It helps if the same problem keeps coming back.
- Do not let others edit the code during the warranty without agreeing it with the builder.
A Concrete Version
An online ordering app for a bakery launches in March. The warranty runs 90 days.
- Week 2: orders with a note longer than 200 characters fail. The criteria said notes are allowed, with no limit. Bug, fixed free.
- Week 5: the owner wants a "gift wrapping" option. Change, quoted separately.
- Week 7: the card payment provider has a two-hour outage. Excluded. The builder helps by adding a clear "payments are temporarily unavailable" message, quoted as a small change.
- Week 11: the end-of-month sales report shows the wrong total when an order is refunded. The criteria said the report shows net sales. Bug, fixed free. It only showed up at the third month-end, the first one with a refunded order, so a 30-day warranty would have missed it.
Is a "Bug-Free Guarantee" Realistic?
No, and be wary of anyone who offers one. All non-trivial software ships with defects nobody has found yet. What a builder can honestly promise is to fix, at their cost, anything that fails the agreed criteria during the warranty period. That promise is checkable. "Bug-free" is not, and it usually means the fine print defines bugs very narrowly.
The Honest Counterpoint
A warranty is a floor. Every piece of software has bugs that surface later, and a 90-day window will not catch all of them. What matters as much is whether the code can be fixed by someone else after the window closes, which depends on the handover, not the warranty. Read the software project handover checklist. Also, very long warranties can be priced into the build. A builder offering a year for free may be charging for it somewhere.
Frequently Asked Questions
Is a warranty the same as maintenance?
No. A warranty fixes defects in what was built, for a limited time, at no charge. Maintenance covers ongoing updates, small changes, and fixes after that, usually for a monthly fee. See what happens after your app is built.
What if the builder refuses to call something a bug?
Go back to the written criteria. If they are silent, treat it as a change and negotiate, then write clearer criteria next time.
Do freelancers offer a software guarantee?
Some do. Ask before signing and put the period in writing. See fixed-price software contract: what to include.
What if the builder has gone out of business?
The warranty goes with them. That is why owning your code and accounts matters. Read how to hire a developer to maintain an existing app.
How long is a typical software warranty?
For custom builds, 30 to 90 days after completion is common. Thirty days often misses monthly features like invoices and month-end reports, so ask for at least one full business cycle.
The Bottom Line
A warranty should cover defects against the agreed criteria, for long enough to see a full business cycle, with clear exclusions. Write good criteria and it will do its job. If you are still at the idea stage, the honest read turns your idea into a short spec you can hold any builder to.
Roberto Espinoza is CEO of Ruzora, which builds custom software for business owners at a fixed price and places pre-vetted senior LATAM engineers with US teams. Get a free honest read on your idea.
