Some Softronic clients don’t pay me by the hour. They pay a commission on each sale that goes through the system I built for them. If the system doesn’t sell, I don’t get paid. It’s the most useful example I have of what “outcome-based pricing” means once you get past the sales deck.
Outcome-based pricing means paying a vendor for an observable result instead of for hours: a deliverable that passes written acceptance criteria, a metric that moves, a share of the revenue the work produces, or a service level that’s met. A body shop bills headcount times hours times rate, so when the work runs long or fails, the client carries the cost. With outcome pricing, the vendor carries at least part of it.
How a body shop makes money
A body shop sells engineering hours. You agree on a rate, the vendor sends people, and every month you get an invoice for the hours they logged.
Look at what that rewards. A project that drags on earns more. A senior engineer who solves the problem in two days makes the vendor less money than a junior who takes two weeks, unless the junior is billed at a senior rate, a complaint every procurement team has heard. If the project fails, the invoices were still paid. If it succeeds beyond anyone’s hopes, the vendor earns what it would have earned if it had barely worked.
Nobody needs bad intent for this to happen; the incentive points that way on its own. The monthly report counts the hours that went in, while the board wants to know what shipped.
Why are hours harder to price now?
Hours were always a proxy for output, and the proxy keeps getting worse.
With AI coding tools, the same task can take wildly different amounts of time depending on the person, the codebase and the kind of work. People are also bad at judging the effect. In a 2025 study by METR, experienced open-source developers took 19% longer to finish tasks when they were allowed to use AI tools, and afterwards still believed the tools had sped them up by 20%. Whatever you make of that result, it shows that nobody, the engineer included, can say with much confidence what an hour of work is worth right now. When the input is that hard to measure, it makes more sense to pay for something you can observe: the feature works, the migration is finished, the system made sales.
Analysts see the same shift. IDC forecasts that “by 2029, driven by agentic AI, 30% of all contractual engagements with service providers will be outcome-based.” Read it the other way around too: most contracts will still be priced some other way. Hourly billing will stick around, just not as the default.
Four ways to price on outcomes
“Outcome-based” gets stretched to cover very different contracts. These are the ones I run into most:
| Model | How the vendor gets paid | Works when | Fails when |
|---|---|---|---|
| Fixed price per deliverable | A set price for a specified result; the vendor absorbs overruns | “Done” can be written as acceptance criteria before work starts | Nobody knows yet what the thing should be |
| Payment tied to a metric | A base fee plus a bonus if a number moves, such as checkout conversion | The metric depends mostly on the vendor’s work and moves within weeks | Marketing, seasonality and your sales team push the same number around |
| Share of revenue or savings | Less up front, plus a cut of what the work produces | Both sides look at the same numbers | Sales happen outside the system and attribution turns into an argument |
| Service levels | A flat monthly fee for agreed standards (uptime, response times), with credits on misses | The measurements already exist, as in support, security operations and managed infrastructure | The standard measures something that isn’t what you care about |
My commission clients are in the third row.
What a commission per sale needs
The commission arrangement works because three conditions hold, and I’d check them again before signing another one.
The sale has to happen inside the system. If orders come in through the software and get recorded there, the commission is a report anyone can run. If some sales close over the phone and get typed in later, or never, attribution turns into an argument.
Both sides have to trust the data. The client can see every transaction and so can I. Nobody emails the other a spreadsheet and asks to be believed.
The client needs real demand. A commission on sales that never happen is zero. I’m betting on their market as much as on my code, so I only take the bet when I understand how they sell.
I feel the incentive shift directly. When my income depends on the checkout working, a bug that blocks payments on a Saturday night is my problem in the most literal sense, and nobody has to remind me of a support clause.
The client’s side of the trade: in a good year they may pay more than the hours would have cost. That’s what moving the risk to me costs them. A vendor who takes on delivery risk and charges the same as time and materials has either misjudged the risk or written a contract where the risk never moved.
Where paying by the hour still fits
I still sell hours, and in some cases they’re the right unit.
For maintenance and ongoing development, when a system is in production and each month brings a mix of fixes, small features and dependency updates, a monthly block of hours is simpler and fairer than inventing a deliverable every month. My monthly maintenance plans work that way.
For full-time placement, the client directs the engineer’s work day to day. They’re renting capacity, not buying a result, and a monthly fee reflects that.
For real exploration, where neither side can describe the deliverable when the contract is signed, pricing on outcomes just means someone will invent a deliverable and fight about it later. Short, time-boxed phases with a demo at the end of each one fit better.
What to check in an outcome-based contract
- Is “done” written down? Acceptance criteria, how they’ll be tested, who signs off. Without that, you have an hourly contract with a nicer name.
- How does a change get priced? You will change your mind, and the contract should say what that costs before anyone starts on it.
- Is attribution specific? “Sales go up” isn’t a metric. “Orders placed through the new system, as recorded in its database, per calendar month” is.
- Is the variable part the right size? A bonus that’s a rounding error won’t change anyone’s behavior. If everything rides on the bonus, the vendor will staff the work as cheaply as possible to limit their loss. A base fee plus a meaningful variable part usually works better.
- Is the first phase on hours? Some vendors propose hourly billing “until things settle” and outcome pricing afterwards. The early phase is where most of the risk sits, which is exactly why they want it billed by the hour.
A test for the contract you already have
Take your biggest vendor contract and answer two questions. What does the vendor earn if the project runs 50% over? What do they earn if it delivers twice the value you expected? If the answers are “more” and “the same,” you’re in a body-shop arrangement whatever the contract calls it. That may still be fine for your situation, as long as you know which one you signed.