How to price an AI project

Pricing is the single most expensive mistake new AI consultants make, and most of them make it for longer than they should.

The pattern looks like this: you charge hourly. Your rate is reasonable. Your work is good. Your clients are happy. And you are making far less than the value you are creating, and you can tell because the clients keep telling you.

"This saved us twelve hours a week."

"We would have paid ten times this for this outcome."

"Can you do it again for our other team?"

Every one of those sentences is a sign you are priced wrong. The reason you are priced wrong is almost never that you do not know your numbers. It is that you have priced your labor, when you should have priced the outcome.

Let me lay out the three pricing models I have used, in the order I used them, and what each one gets right and wrong.

Model one: hourly

I bill an hour of my time at a rate. The client gets a timer. I do work. They pay for the time. This is the default for new consultants because it is the model they know from agencies and law firms, and it feels fair. It is fair in the sense that you are being paid for your time. It is unfair in the sense that it ties your earnings to the slowest possible version of yourself.

Here is the perverse incentive. The better you get at the work, the faster you finish it, the less you get paid. A problem that takes a junior consultant eight hours takes me thirty minutes, not because I am cutting corners but because I have seen it before. At an hourly rate, I get paid sixteen times less for the same outcome. The client gets the same result. I get penalized for being good.

This is not a rate problem. It is a model problem. You cannot fix it by raising your rate, because now you are an expensive junior instead of a fairly-priced senior, and the conversation shifts from "is this worth the money" to "why are you so expensive."

Worse: hourly billing turns the call into a conversation about time instead of a conversation about the problem. Clients watch the clock. You watch the clock. You both start optimizing for the wrong variable. The best consulting calls I have ever had are the ones where nobody mentions the time. Hourly billing makes that impossible.

Hourly is what you use when you are just starting out and have no other way to price, or when the scope is genuinely uncertain and a flat fee would be unfair to one side. That is it. Graduate off it as soon as you can.

Model two: flat project fee

You scope the project, you give a number, the client says yes, you do the work, you get paid. This is what most agencies do, and it is a real step up from hourly because it decouples your earnings from your efficiency. Finish in half the time? You earn twice the effective rate. Good for you.

The problem with flat-fee is scoping. You have to know exactly what the project is before you quote, and clients almost never know exactly what they want until they see it. The real scope of an AI project is usually 30% larger than the stated scope because of the last-10% problem. So either you pad the number and some clients balk, or you quote fairly and some projects go over, or you quote fairly with a change-order process and spend half the project arguing about what is and is not in scope.

Flat fee is the right tool for sharply defined work. "Build me this integration, with these endpoints, against this spec, delivered in this format." It is the wrong tool for exploratory work, for systems that will evolve during the engagement, or for any project where "what does done look like" is itself one of the unknowns.

Model three: outcome-based

You get paid for a result the client can measure. "Cut time spent on X by Y percent." "Hit Z reliability on the agent in production." "Deliver a system that runs for ninety days without human intervention." You define the outcome, you attach a number to it, and you get paid when the outcome is real.

Outcome-based is the pricing model that matches the actual shape of value in AI work. The value of an AI system is not the hours that went into building it. It is the hours it saves, or the revenue it generates, or the risk it removes, compounded over the life of the system. If a system saves twelve hours a week forever, that is six hundred hours a year, and six hundred hours of senior operator time is worth maybe sixty to eighty thousand dollars a year, and that number compounds. Charging a flat project fee of fifteen thousand dollars for the build is not "fair pricing." It is a discount.

The trick with outcome pricing is the measurement. The outcome has to be something both sides can see and agree on, in advance, with a clear way to verify. "More productivity" is not an outcome. "The weekly report that currently takes four hours now takes under thirty minutes, measured across four weeks" is an outcome. "Better customer experience" is not an outcome. "Inbound email response time under five minutes, measured across a thousand emails" is an outcome. If you cannot write the outcome as a sentence that could be audited by a stranger, it is not an outcome. It is a vibe.

In practice, I use a hybrid. For short engagements, like a consulting call, I flat-fee it. Thirty minutes is one price, sixty minutes is another. Those are the tiers. No timer, no clock-watching, no scope games. The scope is "whatever we can fit in the time," and that is fair to both sides because the value of a single call is roughly predictable.

For medium engagements, a build that takes two to six weeks, I use a flat fee plus an outcome bonus. The flat fee covers the work. The bonus kicks in if the system hits a measurable outcome in the first ninety days of production. The bonus is usually 20 to 40 percent of the base fee. This aligns incentives: I have a reason to care about whether the thing actually works in production, not just whether it was delivered.

For large engagements, the "deploy a system that will run the business function for the next year" kind, I use outcome-based with a floor. The floor is the minimum I will be paid regardless of outcome, and it exists to make sure I can pay the team and the infrastructure. Above the floor, the payment scales with the measured result. This is the model Kingstone uses for most of its larger builds, and it is the one that has convinced more than one skeptical CFO to say yes to a project they would have haggled down by 40% on a flat fee.

There is one more thing I want to say about pricing, and it is the uncomfortable part. Most new consultants are underpriced because they are afraid of the number. They are afraid the client will say no. They are afraid the client will think they are greedy. They are afraid the client will find someone cheaper.

The fear is real, and the fear is almost always wrong. Higher prices filter for clients who take the work seriously. Higher prices give you room to do the work properly instead of cutting corners. Higher prices make the client respect the engagement, because they have skin in the game. Every single time I have raised a price, the client roster got better, not worse. Every single time. I do not know a consultant this has not been true for.

The sentence I use when I feel the fear is this: "The price is X. It is worth it because of Y. If the outcome is worth Y to you, it is a good deal. If it is not worth Y to you, I am the wrong fit, and I would rather tell you that now than after you have paid me." That is the whole script. It is honest. It is direct. And it works because it is honest.

So: look at your last five engagements. What were the outcomes? What was the value you delivered? What did you charge? If the value was larger than the charge by a factor of ten, which it almost always is for good work, the problem is not your rate. The problem is your model. Change the model. Price the outcome. The client will be happier, and so will you.