How to price an AI automation project as a freelancer

1. Hourly: the safe floor, not a strategy

Billing your hours is the easiest model to defend and the worst one to grow on. Automation work has a shape that punishes it: the better you get, the faster you build the same workflow, and the less you earn from it. Hourly also transfers every surprise to your own side of the table — a tool with no API, a client whose “quick data cleanup” is three weeks of duplicate records.

Where hourly earns its place: a genuine discovery block you sell before quoting the build. Two to four paid hours reading the client's process, with the fee credited against the project if they go ahead. It filters out prospects who were never going to buy, and it pays you for the thinking you would otherwise do for free.

2. Fixed price per workflow: the default for solo work

This is the model we recommend as a starting point. You price one process, end to end, as one number. The client knows what they are buying; you keep the upside when you build it in half the estimated time.

A fixed price only holds if the scope holds, so the number must ride on answers, not assumptions: which tools are involved, who can grant admin access, what happens when a run fails, and what one revision means. Those are exactly the questions in our free discovery questionnaire. Send it before you quote. A price written over a gap in the answers becomes unpaid rework, and rework is the reason fixed prices get their bad reputation — not the model itself.

When the client pushes the number down, move scope, not rate: fewer integrations, one workflow instead of two, a manual approval step instead of a fully autonomous run. The price follows the surface area of the work, always.

3. Value-based: powerful, and easy to get wrong alone

Pricing against what the automation saves — hours removed, orders processed, errors caught — can produce the best margin in freelancing. It also demands two things solo operators usually lack: a client who will share real numbers, and a documented before-and-after to settle on. Without those, “value based” quietly becomes “whatever I can get away with”, and the client remembers.

The honest middle path: quote the build fixed-price, and in the same proposal put the client's own stated numbers next to it (“you told us this takes your team about six hours a week”). The value case does the persuading; the fixed price does the billing. You never have to audit a claim to get paid.

4. Retainer for monitoring and repair

An automation that runs unattended will eventually break: a tool changes its API or its pricing, a form field gets renamed, a key expires. Who notices, and who fixes it, is a pricing question you should ask before handover — in our experience it is the difference between a retainer and a clean exit. Offer it as a choice in the proposal: a small monthly retainer for monitoring and repair, or a clean handover where any repair after a third-party change is quoted separately. Both are legitimate; ambiguity is not.

The order that protects your price

1. 01Send the discovery questionnaire. No price moves until the tools, access, volumes and sign-off questions have answers.
2. 02Write the scope: what gets built, what one revision means, what is explicitly out. The scope is the price's foundation.
3. 03Price the build fixed, per workflow. Put the retainer-or-exit choice next to it as a separate line.
4. 04If the client says no, shrink the scope before you shrink the number.