It is not a formality. It is the last line of defense before your customers find the problems.
Why QA gets cut
QA is invisible when it works. A thorough test cycle that catches forty bugs before launch produces no visible deliverable, the deliverable is the absence of problems. This makes it hard to defend in a budget conversation. The broken checkout that QA would have caught costs $15,000 in lost revenue on the day of a campaign launch. The QA cycle that would have prevented it cost $2,000. These two numbers are never compared in the same meeting because the first number doesn’t exist yet when the decision is made.
The second reason QA gets cut is misunderstanding what it covers. “The developers tested it” is not QA. Developer testing confirms that code does what it was written to do. QA testing confirms that the product does what the user expects it to do, which is not the same thing. A developer tests the happy path. A QA engineer tests what happens when a user does something unexpected, enters the wrong format, clicks the back button at the wrong moment, or uses a device or browser that was not part of the development environment.
What QA actually catches
The bugs found in QA that are not found in development testing are the expensive ones. A form that submits without validation on a specific mobile browser. A checkout that fails when the billing and shipping addresses are different. A product image that breaks on Safari but not Chrome. A discount code that applies incorrectly when combined with another promotion. An API integration that times out under real user load but not in a developer’s local environment.
None of these are catastrophic to fix in QA. All of them are expensive to fix in production, because fixing them in production means users have already experienced them, and fixing a live system requires careful deployment to avoid creating new problems while solving the existing ones.
The cost calculation nobody does upfront
A QA cycle for a mid-size web project (eCommerce store or custom web application) typically costs $1,500 to $5,000 depending on scope and the size of the test surface.
A broken checkout on launch day, on a store doing $50,000 in monthly revenue, costs roughly $1,650 in lost revenue per hour of downtime (assuming 8 hours in a working day and even distribution of traffic). A four-hour outage on a campaign launch day costs more than most QA budgets for the entire project.
A form that submits but does not deliver the data costs every lead that comes through it until someone notices. If that takes two weeks, and the site was generating 50 leads per week, that is 100 lost leads, at whatever your lead value is.
These numbers are specific to the business. They are almost never calculated before the QA budget is cut.
What to do instead
The simplest fix is to treat QA as a non-negotiable line item from the start of the project, not a buffer that gets absorbed when timelines slip. A project brief that specifies “QA testing is included in scope” makes it harder to remove under budget pressure because removing it requires an explicit scope change conversation, not a quiet line item deletion.
The second fix is defining what QA covers before the project starts. At a minimum for any eCommerce or lead-generation site: cross-browser testing (Chrome, Safari, Firefox on both desktop and mobile), checkout flow end-to-end (from product page through order confirmation), all form submissions with confirmation that data arrives where it should, and load testing at expected peak traffic.
For web development projects that involve third-party integrations, payment gateways, CRMs, ERPs, inventory systems, integration testing is the highest-value QA activity. Integration bugs are the hardest to diagnose in production and the most reliably caught in a structured test environment.
Our QA and testing work is scoped at the beginning of every project, not added at the end. That distinction matters more than it sounds.
