AI agents can now deliver a finished result instead of a tool that helps a person produce one, which is why service as software is reshaping how companies think about selling their work. The pricing model that fits that shift is outcome-based pricing, charging for the result instead of the seat or the hour. The part almost nobody covers honestly is what it actually takes to build the system underneath it.
TL;DR: Outcome-based pricing is easy to describe and hard to build. The real work isn't choosing a price, it's building an audit trail that can prove, after the fact, exactly what happened and why a customer is being billed for it. Get the measurement architecture right first (event store, idempotent ingestion, a defined "done"), then wire it into billing infrastructure like Stripe's Billing Meters. Brocoders has already built usage-based and metered products this way, Fieldera, BrainBox, and Bridge.
What is outcome-based pricing
Outcome-based pricing is a model where a customer pays only after a defined, measurable result happens, a resolved support ticket, a closed set of books, a completed workflow, rather than for a license, a seat, or raw usage. Stripe frames it directly as linking revenue to results instead of to access. Intercom charges $0.99 per resolved support conversation and doesn't charge at all if the ticket isn't fully resolved. Zendesk's AI agents bill $1.50 to $2.00 per automated resolution depending on commitment level.
The model reads simply from the outside. What's underneath it is a harder engineering problem: before you can charge for an outcome, you need a system that can prove, after the fact, that the outcome actually happened.
Why outcome-based pricing matters now
Outcome-based pricing matters because it's the pricing model that actually fits what service as software describes: an AI agent delivering the finished outcome of a service directly, instead of a tool that helps a person produce that outcome. A SaaS priced per seat still bills for access, a person logging in to do the work themselves. When an AI agent does the work end to end, closing the books, resolving the ticket, charging for the seat stops making sense, because there's no longer a person's time being metered. Charging for the outcome is the only pricing model that lines up with what's actually being sold.
That alignment has a second, more practical effect: it changes who bears the risk. Under per-seat or per-token pricing, the customer pays regardless of whether the AI actually delivered, and the vendor's incentive is usage, not results. Under outcome-based pricing, the vendor only gets paid when the result lands, which is why Sequoia Capital's essay on the shift argues the vendor that sells the work, not the tool, gets stronger as the underlying model improves, instead of racing against it. For a company deciding whether to turn a service into an AI product, outcome-based pricing isn't a separate decision from that shift, it's the pricing model the shift requires. The catch, covered in the rest of this piece, is that requiring it and being able to build it are two different things.
The real problem isn't the price, it's the proof
The billing requirement underneath outcome-based pricing is an audit trail, not a meter. A meter counts units. An audit trail proves a specific outcome happened, when, and why the customer is being billed for it, a distinction laid out clearly in Lago's guide to AI billing infrastructure. Every billable event needs a timestamp, a customer record, a workflow type, a billable reason, a verification method, an amount, and a source link back to the underlying evidence.
Skipping that step has a real cost. A SaaStr Fund portfolio company that crossed $1M a year on an outcome-based deal had the customer move to a fixed contract shortly after, once volume made the "what counts as an outcome" question expensive to keep re-litigating, according to SaaStr's own account. The pattern runs the other way too: Henson Group moved from seat-based to outcome-tied managed services and grew deal size roughly 4x almost overnight, once the measurement problem was solved first. The infrastructure work isn't optional overhead before outcome-based pricing works, it's the entire reason it works at all.
That's serious enough that a funded company now exists purely to solve it. Paid, founded by Manny Medina, raised a $21M seed specifically to build results-based billing infrastructure for AI agents, according to TechCrunch's coverage. If a funded infrastructure company is needed to solve the measurement layer, a spreadsheet won't.
The architecture: separate the request from the bill
The core pattern is to keep the request lifecycle and the billing lifecycle as two separate things, connected by a unique operation identifier that tracks a request through every stage: initial processing, the model invocation, validation, and finally the outcome determination. Each stage writes to an event store, request received, model invoked, response generated, validation performed, outcome determined, and that event log becomes the single source of truth for both billing and disputes.
Two details make or break this in practice. First, the ingestion layer has to be idempotent: if a retry sends the same outcome event twice, the customer gets charged once, not twice, which matters constantly during high-volume periods when retries are routine rather than rare. Second, "outcome" needs a contractually unambiguous definition before a single line of billing code gets written, not during the first customer dispute. Is a support ticket "resolved" the moment the AI closes it, or only if the customer doesn't reopen it within 24 hours? That decision belongs to the product and legal conversation, not the engineering team alone.
Build the transparency into the billing layer itself, not a support inbox: a customer-facing breakdown by resolution type, channel, time window, or agent ID removes most disputes before they start, because the customer can see exactly what they're being charged for and why.
Implementing it with existing billing infrastructure
None of this has to be built from raw database tables up. Stripe's Billing Meters, its current usage-based billing primitive, map directly onto the architecture above: you define a named event (what counts as billable), attach it to a recurring price, and choose an aggregation formula (sum, count, or last) for how repeated events roll up into a charge. As of API version 2025-03-31.basil, every metered price requires a backing Meter, the older usage-records API Stripe used to support is gone. In March 2026, Stripe extended this model with dedicated LLM token billing, a direct acknowledgment that flat subscriptions break under the spiky, unpredictable usage patterns real AI agents produce.
The event store described above becomes the system that reports usage events into Stripe's meters, while retaining its own richer audit trail (the billable reason, the verification method, the source link) that Stripe's meter alone doesn't capture. Stripe handles the aggregation and the invoice, the audit trail underneath stays owned by the product. For teams integrating this for the first time, Brocoders' guide to payment gateway integration covers the broader groundwork, provider selection, PCI compliance, webhook handling, that a metered billing setup sits on top of.
What this looks like already built
Brocoders has built products across this spectrum already. Fieldera, the field service platform, uses usage-based pricing with a setup fee and no per-seat charges, chosen specifically to avoid the per-technician penalty that pushes FSM operators away from incumbent tools. BrainBox, a multi-tenant AI agent SaaS platform, meters usage by plan with per-customer workspace isolation, the same aggregation-by-customer pattern a Stripe Meter is built to handle. Bridge, Brocoders' own AI agent platform, ships an analytics dashboard tracking real-time token usage and cost, the exact instrumentation layer an outcome-based or usage-based pricing decision depends on having in place before the pricing conversation even starts.
How to know if you're ready
Three questions worth answering honestly before committing to outcome-based pricing.
Can you define "done" in one sentence that a lawyer and an engineer would both sign off on. If the answer takes a paragraph and still has edge cases, the definition isn't ready and the pricing model shouldn't ship yet.
Do you have an audit trail, or just a meter. A count of events is not proof of an outcome. If a customer disputes a charge, can the system produce the specific evidence, not just the tally, that justifies it.
What happens to your margin if volume grows 10x. The SaaStr and Henson Group examples above point in opposite directions for a reason, outcome pricing only holds up if the unit economics were modeled before the first large customer signed, not after.
Brocoders is an AI-native software development company that builds AI product development for teams architecting a pricing model, and the metering and audit-trail infrastructure behind it, for their own AI product.
Frequently Asked Questions
A pricing model where a customer is charged only after a specific, measurable result happens, rather than for a license, seat, or unit of raw usage.
Defining "done" in a way that's both technically measurable and contractually unambiguous, then building an audit trail that can prove it happened, not just a meter that counts events.
Stripe's Billing Meters handle the aggregation and invoicing side (event name, aggregation formula, recurring price), but the richer audit trail, the billable reason and verification method behind each charge, needs to be built and owned separately.
No. Some of the same companies exploring it, including AI-native ones, still run flat subscriptions successfully. The right model depends on whether the outcome can be defined and proven cleanly enough to survive a customer audit.