Profit or progress: How QA pricing models define vendor incentives

The thing about pricing models is that they always seem to make sense, until someone comes around and does something a little bit different. 

Take Blockbuster, from back in the day. 20% of their revenue came from late fees. After driving to the store, choosing whatever movie was still left on the shelf, and then paying for the rental, the company charged you again if that pesky thing called “life” made you late. Then Netflix came along with a subscription service — unlimited rentals for one flat fee. When they moved to streaming, the pricing model remained the same. 

Then there was Oracle CRM in the 1990s: A huge up-front installation cost, followed by annual maintenance fees, consulting fees, custom configuration fees, and true-ups for CPU overages. Until Salesforce bundled it all together as a SaaS package: one small recurring fee per user per month. 

Amazon Web Services changed the way we pay for infrastructure: Where we used to pay for computing capacity, now we pay for computing usage. 

In every case, the old pricing model prioritized the vendor’s costs over the buyer’s needs. Which is what’s been happening with QA since the very first QA vendor appeared. If you’re watching this webinar and reading this post, you know that we’ve developed a modern pricing model — one that incentivizes our business to provide valuable outcomes for our customers — but before we get there let’s take a look at the existing models. 

The old ways of charging for QA

Broadly speaking there are three styles, but they’re all just variations on a theme: Taking the hourly cost of the person doing the work and adding a profit margin. That could be…

1. Fixed price contracts where the customer pays a set price for some deliverable, say 100 automated tests.
2. Time & materials (aka hourly billing) where the customer pays for the number of hours worked, and any expenses needed to do the work (like a Browserstack license).
3. Staff augmentation, where the customer effectively pays a retainer for a full-time resource regardless of how many hours were actually worked. 

Since each of these models is ultimately derived from the same approach (the hours worked) they all have the same fundamental problem: the incentive of the person doing the work isn’t aligned with the goals of the paying customer. What development teams need from a QA vendor is test coverage — comprehensive, reliable, tests that are ready to run at any time, and accurate results. The labor hours are simply a means to an end. 

Understanding the incentives at work with each model

Show me the incentive and I’ll show you the outcome.
—Charlie Munger

Fixed-price contracts: A rigid model that punishes change

With a fixed-price contract, where the work product and costs are pre-negotiated, anything outside the scope of the contract becomes a financial liability for the vendor. In order to make money on the engagement (the goal of any business) they will have to refuse additional work or require a change order. They simply cannot afford to be a partner when needs change, unless the fixed-price contract they’re under is modified. This inevitably leads to an antagonistic relationship with a vendor that follows the letter but not the spirit of the agreement. 

Time & materials: Rewarding effort, not results

T&M contracts where the vendor marks up the hours worked, regardless of how many hours are required, are obviously more flexible than fixed-price but they don’t incentivize speed of delivery. The vendor makes more money the longer the activity takes and there’s no pressure to do anything quickly. 

While T&M offers adaptability, it shifts all the risk onto the customer. Customers also have to actively manage the vendor’s work to ensure alignment with standards and avoid scope creep, which increases the risk of projects dragging on indefinitely without clear deliverables. Worse, vendors have little financial incentive to improve efficiency or automate processes. Since every hour saved would be an hour not billed, T&M jobs get a reputation for always taking longer and costing more than initially quoted. 

Staff augmentation: Predictable costs, unpredictable value

Staff aug, where a vendor provides a QA engineer who’s dedicated to your team has many benefits: They are always available, they get to know your product and understand your goals, and you can insist on a certain level of expertise that you wouldn’t be able to in other cases. 

But, the vendor gets paid for a full month of time regardless of how much the resource works.  If the customer’s priorities shift or work slows down, they still pay the same fixed monthly cost, even if their consultants aren’t fully utilized. Or worse, when things are busy it’s not easy to scale. You leave money on the table if you don’t use their full availability, and you risk delays if you don’t staff enough surge capacity.

Return to first principles and find new incentives

Fixed deliverables assume a static scope, making necessary adjustments costly and slow. Hourly models reward effort over impact, incentivizing vendors to take longer rather than work smarter. When every change triggers extra costs, teams avoid improvements that could enhance test reliability and release speed. A better approach ties pricing to a meaningful result — a stable, adaptive test suite that keeps pace with development — so automation accelerates rather than hinders innovation.

By charging for the test under management, rather than the labor that goes into it, the vendor assumes all the risk and is motivated to improve their processes to be as efficient as possible. Instead of tying revenue to time spent, it rewards efficiency, speed, and reliability.

When vendors charge for the outcome (functioning tests) instead inputs (labor hours) every aspect of the testing lifecycle gets faster and more efficient:

• Test creation. When revenue is tied to the number of tests under management, delays become a cost rather than a profit opportunity. The faster a vendor gets automation up and running, the more financially viable their service becomes. That means customers get their tests built, maintained, and running faster, leading to shorter feedback loops and faster releases.
• Test reliability. Under per-test pricing, unreliable tests increase the vendor’s costs without increasing revenue, so the vendor has every reason to build stable, maintainable automation from the start. More reliable tests mean fewer disruptions for the customer and less wasted time for the vendor. 
• Fewer miscommunications. When the price is tied to test management, mistakes hit the vendor’s bottom line, so it’s in their best interest to work closely with the customer, prevent misalignment, and avoid rework. Clearer communication leads to fewer delays and a testing process that proactively identifies new areas to cover rather than constantly revisiting old ones.
• Total coverage. The vendor benefits from actively identifying areas for additional testing, rather than waiting for the customer to ask. Customers get better coverage and peace of mind that their QA scales with their product, while the vendor builds a more valuable long-term relationship.

Unlike hourly billing, which benefits vendors at the customer’s expense, per-test pricing creates a system where both sides win. Vendors only succeed when they deliver reliable, efficient, and comprehensive automation. The result is a model that isn’t just good for the customer—it’s also a smarter, more sustainable way to run a testing business.

‍

‍