We first answered this question on our blog in 2018. Prospective clients still ask it, usually a little sideways, somewhere in the second conversation. It deserves a straight answer.
Who pays for bugs? You pay the team that catches and fixes them. You do not buy each bug one at a time, and you should not sign a contract that treats every defect as a change order. Here is how that works in practice.
What you are actually buying
There is a common assumption that when you hire a software firm, you are buying a finished, bug-free product, the way you would buy a truck. That is not what custom software is.
Just like you hire other professionals, such as attorneys, CPAs, or physicians, for their time and expertise, you are hiring software professionals for theirs. You are paying for a team’s judgment and skill to design and build something fit for your business, and to build it in a way that can be maintained for years. A good team works hard to keep the bug count low. No team gets it to zero, and any team that promises to should worry you.
That puts a responsibility on you as the buyer. Your job is to pick a team you trust, that has the right capabilities, and that has real practices for quality. The team’s job is to ask the right questions, attack uncertainty early, and tell you plainly about risks and options along the way.
Bugs found during the build
Bugs are part of building software. When they surface while the project is underway, they get fixed inside the project. They are not billed separately and they do not eat into your scope as if they were a feature you asked for.
This is one of the reasons we work to a fixed budget with controlled scope. On a fixed price, fixed scope contract, a vendor has a financial incentive to argue about whether each defect was “in scope.” On a pure hourly contract, every fix is another invoice. Under a fixed budget, the incentive runs the right way: the team wants to build it correctly the first time, because rework costs them the same as it costs you.
The one distinction worth being clear on is bug versus change. A bug is the software not doing what we agreed it should do. A change is you deciding, after seeing it work, that it should do something different. Changes are normal and welcome. They are handled through the weekly trade-off conversation, where you decide what gets prioritized inside the remaining budget. They are not bugs, and a good team will tell you which is which without making it a fight.
Bugs found after launch
Once the first release is live and accepted, the system moves into maintenance and support. That is a separate agreement, and it is where post-launch bugs are covered.
We price it as reserved hours billed monthly, with response times set by priority. A production outage and a cosmetic misalignment are not the same call, and the agreement says so in writing before you sign. Each month you see exactly what the hours went to. If the system also needs hosting, that is cloud costs at pass-through plus a fixed monthly management fee, and the same team that built the system runs it. The full picture is on the Managed Hosting & Support page.
The reason it works this way, and not as a warranty, is that not all dependencies are always known. Your custom application runs alongside other systems, other vendors, and a cloud provider that ships changes on its own schedule. Sometimes a change somewhere else breaks something here. That is not a defect in the original build, but it is still your problem, and the people who know the system are the ones you want fixing it.
Why this should not surprise you
Just like any other valuable asset, such as a building or a piece of equipment, custom software requires regular attention over time. Most of the lifetime cost of software comes after launch. That is not a knock on the build. It is what it means to own a system the business depends on.
Part of our job during planning is helping you budget for that from the start. A VDP Sprint for a new build, or a System Evaluation for an existing one, ends with a plan that includes what it will take to keep the system healthy after it ships. The typical budgets by type of project on our pricing page show how the build, the support, and the hosting fit together. There is no such thing as bug-free, maintenance-free software, and a budget that pretends otherwise is the first bug.
What keeps the bug count low
Since you are paying for the team’s ability to catch and fix bugs, it is worth knowing what that looks like. Quality is more than the number of defects. It is whether the code can be understood and changed by the next person, and whether the solution matches the real-world problem. Software that is easy to maintain makes every future fix faster and cheaper.
Our approach is an engineering approach:
- We take a little more time up front to understand the real problem and its context.
- We plan how to solve it before we build.
- We build it.
- We review it to make sure it is correct.
Under the hood that means a data model that matches your business, code that is organized and clean without being over-engineered, automated and manual testing, code review on every change, and oversight from someone who has seen the pattern before. None of that is exotic. It is simply what professional software work looks like, and it is why our project success rate is 96.5% across hundreds of projects since 2005.
Questions to ask any vendor
If you are evaluating firms, these three questions will tell you most of what you need to know about how bugs will be handled:
- How are bugs found during the build handled, and does fixing them change what I pay?
- What happens the week after launch when something breaks? Who do I call, how fast do they respond, and what does it cost?
- What are your testing and review practices, and can I see the monthly support report from a current client?
A team that answers all three in plain language, without a rate card appearing mid-sentence, is a team that has thought about this.
The first step
Know going in that there will be bugs, and know what the arrangement is before the first one shows up. If you are planning a build, book a 30-minute intro call and we will walk you through how the build, the support agreement, and the budget fit together for your specific project.