Why I charge a fixed price for AI work

Code that used to take me three days now takes one with AI. On an hourly rate, that would cost me two days of revenue. Whoever bills by the hour earns more the longer the work takes, and now that AI speeds up so much of the work, that arrangement becomes a penalty on speed.

So I work on a fixed price per result, with a written scope and an end date. The cost of your AI implementation is settled up front, and the risk of overrun sits with whoever can best estimate how long the work takes. That is me.

What does an AI implementation cost at a fixed price?

With me it starts with a Scan of about a week, from €1,995 ex VAT. After that comes a sprint of four weeks at most that takes one workflow into production, at a fixed price that is on paper before I start.

I only quote the sprint price after the Scan. In that week I see how much material there really is, how many exceptions the process has and which systems it has to talk to. Per pilot I say whether to kill it, scale it or rebuild it. A build price without that work is a price based on assumptions, and those come back later as extra work.

Why does hourly billing reward overruns?

Because the supplier’s revenue grows with every hour, and nothing in the contract says when it is enough. That has little to do with bad intent. I have seen extra work pile up in projects where nobody had agreed up front when to decide again. On an hourly rate, that missing decision point costs the supplier nothing. The client pays for it.

The bigger problem is who knows what. The supplier knows best how long something takes: which part is routine, what AI speeds up, where the exceptions are. The client can rarely judge whether forty hours were needed or twenty. An hourly rate puts the risk on the party that knows least. A fixed price puts it on the party that can estimate it, and forces that party to scope sharply up front.

AI widens that gap. An hourly supplier who works twice as fast with better tools halves their revenue for the same work, so they have little reason to get faster. A fixed price turns that around. If it goes faster than planned, that is my margin. If it runs over within the agreed scope, that is my problem. Either way you pay the amount you knew up front.

What should a fixed-price proposal contain?

At minimum an amount, an end date and a description of “done” you can check. This is the list I work to, and one you can ask any agency for:

1. One bounded result. With me that is one workflow per sprint. If someone asks for a complete platform, I start with one application.
2. A definition of done. Which questions the system answers, at what error rate, in which system, and who judges that. Plus the measurement method: which data, exceptions and calculation rules count.
3. A decision point on day five. Simple case: I keep building in weeks three and four. Medium: you choose between a simpler automation now or a larger project. Complex: the short format does not fit, and we talk about a longer engagement.
4. Who pays for overrun. If it is not in there, you do.
5. A signature before the work starts. A good relationship does not replace a written engagement letter.

My memo on 35+ implementations ends with ten questions for any AI agency. Question six is exactly this one: is the price fixed or hourly, and who pays for overrun?

When is a fixed price the wrong choice?

When nobody can yet write down what “done” means. That covers open research, where you do not yet know whether something is possible, a scope the client is still unsure about, and projects where a platform’s limits only show up during the build.

I have been through that last one: halfway through an implementation the platform turned out unable to do everything the design asked, and a fixed price on that design meant little by then. How to find that limit before you start is in your AI platform sets the ceiling.

I have also used a fixed price badly myself. A four-week format I used before, with training, analysis and a live automation, was too ambitious for its price for a long time. It worked for simple cases. With more complex ones it only became clear in week two or three that things were harder, and that is when the tug-of-war over scope starts. The decision point on day five comes from there.

Sometimes a fixed price also does not match how an organisation buys. Some procurement departments would rather buy fixed days per week over a few months than a fixed-scope proposal. That works, if your procurement asks for it. The risk of overrun then sits with you again, and both sides should say so out loud. Maintenance after go-live has no natural end point either. For that I work with a retainer that has a goal and an end date.

How do you choose between an hourly rate and a fixed price?

If you can write the definition of done in one paragraph, ask for a fixed price. If you cannot, do not buy a build yet. First buy down the uncertainty for a small fixed amount, which is what the Scan is for. Afterwards you know enough for a fixed build price, or you know this project needs a different format.

Then compare proposals on the most you will pay, not on the hourly rate. A low rate without a ceiling can end up costing more than a fixed price that looks higher. The three formats and their prices are on my AI consultancy page.