A few years ago I watched a capable engineer get penalized for being good at his job. He’d been brought into a fixed-staff arrangement at an engineering firm, billed by the hour. He found a way to automate a reporting process that had been eating two days a week. The work that used to take sixteen hours now took twenty minutes. Everyone agreed it was excellent.
Then the renewal conversation happened, and the math turned ugly. His efficiency had reduced his own billable hours. The vendor’s account manager, who had a number to hit, quietly steered the next phase toward “more thorough” approaches. Nobody said the quiet part out loud, but the incentive was plain: under hourly billing, the fastest path to revenue is to take longer.
That’s the rot at the center of time-based billing for technical work. It pays for motion, not arrival. The client wants a thing to exist and work. The vendor gets paid for hours regardless of whether the thing exists or works. Those two interests don’t just fail to align — they actively pull apart, and the gap widens exactly when the engineering gets good.
We stopped billing for time because we got tired of being on the wrong side of that incentive. Here’s what we do instead, and why it keeps everyone honest.
The hourly model optimizes for the wrong thing
Hourly and day-rate billing have one honest virtue: they’re easy to invoice. Beyond that, they quietly reward everything you don’t want.
Think about what an hour actually measures. It measures presence, not progress. A senior engineer who’s seen your exact problem before might solve it in an afternoon. A less experienced one — or a more financially motivated one — might spend two weeks “exploring approaches.” Under hourly billing, the second one bills more. You are paying a premium for inexperience and a discount for nothing.
It gets worse when you consider what good engineering looks like. The best technical work is often the work that makes future work smaller: a clean data model that prevents a class of bugs, an integration that removes manual steps, a pipeline that nobody has to babysit. All of that compounds in your favor and shrinks the billable surface area. So the engineer who builds you something durable is, under hourly terms, sabotaging their own revenue. The one who builds something brittle that needs constant tending is building an annuity.
I’m not claiming most vendors are cynical. Most aren’t. But you don’t need cynicism for incentives to bend behavior. You just need a number on a timesheet and a quarter to hit. Over enough cycles, the model wins.
What “outcome” actually means — and what it doesn’t
When people hear “outcome-based,” some of them imagine vague promises: “we’ll improve your operations,” “we’ll unlock value with AI.” That’s not what I mean, and that kind of language should make you reach for your wallet protectively, not open it.
An outcome we’ll stand behind is a specific, observable thing that either exists and works or doesn’t. It has an acceptance test you could run yourself. For example:
- A quoting tool that ingests a customer RFQ and returns a structured draft estimate, validated against your last 50 historical quotes.
- A data pipeline that lands your shop-floor sensor readings in a queryable warehouse, with defined freshness and completeness checks.
- A document-extraction service that pulls the right fields from your supplier certs at an agreed accuracy threshold on a held-out test set.
Notice what all of these have in common. There’s a noun (the thing) and a verifiable condition (how you know it’s done). No adjectives doing load-bearing work. No “we’ll try.” You can point at it and say yes, that works or no, it doesn’t — and so can we. That shared, boring clarity is the whole game.
The opposite — “AI transformation,” “intelligent automation initiative” — is unfalsifiable by design. If you can’t write down how you’d know it was finished, you can’t price it as an outcome, and frankly you probably shouldn’t buy it as one either.
The work happens before the work: scoping and acceptance criteria
Here’s the part most people underestimate. Outcome-based delivery moves the hard thinking to the front. Before anyone writes code, we have to agree on three things, in writing:
1. What the thing is
The boundary of the deliverable. What’s in, what’s explicitly out. This is where a surprising amount of project failure gets prevented, because most “the project went sideways” stories are really “we never agreed on what we were building” stories wearing a costume.
2. How we’ll know it’s done
The acceptance criteria. Concretely: what test, on what data, at what threshold, judged by whom. If accuracy matters, we name the number and the held-out set we’ll measure it against. If it’s a pipeline, we name the freshness and completeness checks. The criteria are written so that acceptance is a verification, not a negotiation. You shouldn’t have to argue about whether you got what you paid for — you should be able to check.
3. What you’re responsible for
This one cuts both ways and protects you as much as us. If we need access to a system, sample data, or a subject-matter expert for two hours a week, that’s named up front. Outcomes have dependencies, and naming them keeps a slipped deliverable from quietly becoming your fault — or ours — without anyone deciding it on purpose.
We do this scoping on a call before any commitment — that’s literally what the first 30 minutes is for. It’s not a sales ritual. It’s the most important engineering conversation in the whole engagement, because everything downstream inherits from how clearly we define the target. A fuzzy scope produces a fuzzy result no matter how good the execution is.
Why this is better for the client, not just cleaner for us
It’s worth being direct about who benefits, because “outcome-based” can sound like vendor-speak for “we’d like more money with less accountability.” Done right, it’s the reverse.
You stop paying for our learning curve. If we underestimate the difficulty, that’s our problem to absorb, not a surprise on your next invoice. The risk of “this turned out to be harder than expected” sits with the party who’s actually equipped to estimate it — us. That’s where it belongs.
You can predict your spend. You agree to a defined piece of work for a defined scope. No watching a meter run. No quarter-end conversation where the burn rate mysteriously accelerated. Budgeting a project shouldn’t feel like leaving a taxi idling.
Speed becomes your friend instead of your enemy. If our engineers find a faster way to hit the acceptance criteria, you get the result sooner and we’re both fine with it. Nobody is incentivized to pad. The faster path and the cheaper-for-you path and the better-for-us path are finally the same path. That alignment is the entire point.
Quality has a floor that isn’t optional. Because we’re paid on acceptance, not on hours logged, half-finished doesn’t count. “Mostly working” isn’t a milestone we can bill against. Either it passes the criteria we agreed on or we keep working — at our cost, not yours.
I won’t pretend this is selfless. It’s a better model for a firm that’s confident in its engineering, because confidence is exactly what lets you put the risk on your own side of the table. A shop that pads hours is telling you something about its confidence. So is one that doesn’t.
How clients stay in control the whole way through
A fair objection: “If I’m not buying hours, am I handing over a black box and hoping?” No — and the structure is specifically designed to prevent that.
- Scope is decomposed, not monolithic. Big ambitions get broken into discrete outcomes, each with its own acceptance criteria. You’re never betting the whole thing on one giant deliverable that either lands in six months or doesn’t.
- You accept each piece on its own merits. Acceptance is a real gate. You run the test, or watch us run it, against the criteria we agreed to. If it doesn’t meet them, it isn’t done, and the definition of “done” was yours to shape from the start.
- Direction stays yours between pieces. After one outcome lands and before the next begins, priorities can shift. You learned something. The market moved. That’s normal. Discrete, accepted units of work make it cheap to change course — you’re never trapped finishing something that stopped mattering.
- Visibility doesn’t depend on a timesheet. You see working software hitting agreed checks. That tells you more about real progress than any line-item report of hours ever could. Hours measure effort. Acceptance measures arrival.
The capacity we can take on, and how the scope fits your timeline, is something we set together on a call rather than publish on a page — because it genuinely depends on what you’re building and what shape your data is in. If you want to see how a specific problem decomposes into acceptable outcomes, that’s a good thing to walk through live. It’s also, not coincidentally, how we figure out whether something belongs in a Forge build or a Labs experiment in the first place.
The point is alignment, not cleverness
None of this is a pricing trick. It’s an attempt to make our interests and yours point the same direction for the length of an engagement, so you don’t have to audit our motives at every step.
Under hourly billing, you and your vendor are quietly negotiating against each other on every task — them for more time, you for less. Under outcome-based delivery, you’re both pointed at the same target: the thing exists, it passes the test, it ships. When the incentive is clean, you spend far less energy managing the vendor and far more on the actual problem. That’s the real return, and it’s hard to overstate how much friction it removes.
If you’ve been burned by a project that billed enthusiastically and delivered vaguely, the fix probably isn’t a better timesheet. It’s refusing to start until everyone agrees, in writing, on what “done” looks like. You can do that with us or without us. But if it’s useful to think it through with someone who scopes this way for a living, a 30-minute call is the place to start — no obligation to build anything, and you’ll leave with a clearer sense of what your problem actually requires.
