Fixed Price Is a Feature
If you're a small-business owner about to hire someone to build you an AI system, the single most important decision you'll make isn't which vendor. It's how you agree to pay them. Get that wrong and even a good vendor will produce a bad outcome, because the billing model quietly steers everything that happens after you sign.
I bill fixed price by size. Not because it's simpler to explain — though it is — but because hourly billing fails this kind of work in three specific, predictable ways, and every one of them costs the buyer.
Hourly puts the uncertainty on the wrong person
AI projects are uncertain. Nobody knows on day one exactly how many edge cases the data will throw, how stubborn an integration will be, or how many rounds of tuning it'll take to get an answer you'd trust in front of a customer. That uncertainty is real and it has to live somewhere.
With hourly billing, it lives entirely on you. The vendor names a rate and starts the meter, and every surprise — every gnarly data problem, every dead-end approach, every "huh, that's weird" — shows up on your invoice. You're absorbing 100% of the risk on a project you're the least equipped to estimate, because it's not your field. The person who knows how hard this is charges you for finding out how hard it is.
Fixed price flips that. When I quote a number, I'm the one holding the uncertainty. If the data is messier than it looked, that's my problem to solve inside the price, not a change order I mail you. That's the correct allocation — the risk sits with the party who can actually estimate it and manage it down.
The meter rewards the wrong things
This is the uncomfortable one, and I'll say it plainly because I've been on the vendor side of it: hourly billing pays you more when you go slower.
Nobody sits down and decides to pad an engagement. It's subtler than that. When every hour bills, there's no pressure to reuse the thing you built last month, no pressure to kill a struggling approach early, no reward for being ruthless about scope. Efficiency literally reduces your revenue. So the incentive leans, gently and constantly, toward the scenic route. A good person resists it. But you shouldn't have to rely on your vendor's willpower to get an honest pace.
Fixed price inverts the whole thing. Once the number is locked, every extra week comes out of my margin. Suddenly I'm desperate to reuse code, to scope tightly, to cut the approach that isn't working before it eats another three days. Speed becomes my interest, not just yours. The billing model and the customer's goals finally point the same direction.
"Done" never gets defined
The third failure is the quietest. On an hourly engagement, "done" is dangerously optional. There's always one more refinement, one more nice-to-have, one more thing you could tune — and since it all bills, nobody's in a hurry to draw the line. I've seen projects that were basically finished keep running for two more months because "done" was never something anyone had to define. The meter doesn't stop until someone decides it should, and deciding that costs the vendor money, so it tends not to happen.
Fixed price forces the definition up front. To quote a number, I have to say precisely what you're getting — which workflow, which integrations, deployed and accepted against what criteria. "Done" becomes a thing we agreed to before I started, not a thing we argue about at the end. That definition is worth as much as the price itself.
Payment tied to a deployed system
Here's how the number actually flows. Payment breaks into a 30/40/30 split, and each piece is tied to a real milestone, not to elapsed time. Thirty percent when the build phase kicks off. Forty when the MVP is deployed and you've accepted it. Thirty at handoff, when it's running in production with the documentation to operate it.
Notice what you're paying against: deployment and acceptance, not effort. If nothing ships, the back two-thirds doesn't come due. That's the whole philosophy in one payment schedule — you pay for a working system reaching your hands, not for hours reaching a timesheet.
Why I can quote a number at all
Fixed price only works if the number is honest. Quote too low and you cut corners to survive it; quote too high and it's just hourly with padding baked in and a friendlier label. So the fair question a buyer should ask is: how does a vendor put a real number on an uncertain project without either gouging you or gambling on himself?
The answer is sizing. Before I quote anything, every engagement gets sorted into one of four sizes — think small, medium, large, extra-large — based on the actual shape of the problem: how many workflows, how many integrations, how much new data plumbing, how many people have to change how they work. Those sizes aren't pulled from the air. They're calibrated from real deliveries, so each one carries a price range I've actually seen the work land inside. A single workflow with one integration is a known quantity. A multi-department platform with a custom data model is a different known quantity. The sizing is what turns "who knows how long this'll take" into "this is an XS, here's the number."
That's the machinery behind the confidence. I'm not quoting a fixed price because I'm brave. I'm quoting it because the sizing model already absorbed most of the uncertainty before you and I ever talked about money. Without that discipline, fixed price really would be a coin flip — which is exactly why a lot of vendors won't offer it, and why the ones who do sometimes have to pad it into meaninglessness. Do the sizing honestly and you can hold the number honestly.
But what about scope changes?
The reasonable objection to fixed price is: what happens when I want to change something mid-stream? Doesn't fixed price make the vendor rigid, guarding the scope like a contract lawyer?
It would, if the answer to a scope change were "no." My answer is "let's reprice." If you want to add a workflow that wasn't in what we agreed, that's a conversation with a number attached, done in the open, before any work happens. What fixed price prevents isn't change — it's the invoice surprise, the moment three weeks later when you discover that an offhand "can we also…" turned into eleven billed hours you never approved. Change is fine. Change should be a decision you make with eyes open, not something you find out about when the bill arrives.
The engagements I'm proud of all share this shape: the customer knew the price before I started, knew what "done" meant, and never once opened an invoice with their stomach dropping. That predictability isn't a nice-to-have wrapped around the real work. For a small business betting real money on a system it can't fully evaluate, the predictability is the work.
If you want to see how the sizes and prices break down before you ever talk to me, it's all published on the services page.
You might also like
Why We Charge for Discovery
Free discovery is a pitch wearing a scoping costume. Here's why we charge for it now, and what the customer actually walks out with.
What 90 Days of Fractional AI Ops Actually Looks Like
Most AI projects don't fail during the build. They fail at the handoff — the vendor leaves and the system quietly rots. Here's what a real first 90 days after go-live looks like.
Liftoff: Why We Turned Delivery Into a Methodology (and Put the Prices on the Website)
Most consulting engagements die of ambiguity — scope, price, and 'when is it done' all stay negotiable forever. Liftoff fixes that with three phases, four sizes, and published rates.