
Agency or Freelancer for an AI Automation Build
A freelancer is often the better choice for a first automation. The decision turns on what happens in month four, not on the day rate you compare first.
The day rate is the wrong first comparison
Most of these decisions start with two numbers side by side, one considerably smaller than the other, and end with a discussion about whether the larger one is justified.
The day rate is the least decisive number in the comparison. Both parties can usually build the workflow. What separates them is what the thing does in month four, when a supplier changes a form, a channel changes an API, or the volume doubles and an assumption that held at fifty orders a day stops holding at a hundred.
Where a freelancer wins outright
One process. Few systems, all documented. Someone inside your company who will own the result and can change it.
Under those three conditions you are buying construction, not a relationship. The specification can be written down completely before anyone starts, the coordination an agency carries is doing no work, and the price difference is large and real. A good freelancer will often be faster as well, because there is no internal handover in a team of one.
This is a more common shape than vendors like to admit. If your automation is a single well-understood workflow, the honest advice is to get quotes from individuals.
Where the premium is actually earned
| What you need | Freelancer | Agency |
|---|---|---|
| One workflow, documented systems | Strong fit | Overqualified |
| Four systems, four skill sets | Depends on the individual | Structural fit |
| Fixed date tied to a season | Single point of failure | Absorbs absence |
| Someone accountable in month four | Personal commitment | Contractual obligation |
| Willingness to say "do not build this" | Varies | Varies |
The last row is deliberately unresolved, because company size predicts nothing about it. An agency whose diagnostic always concludes that its own product is needed is worse than a freelancer who tells you the truth, and the reverse is equally common.
Continuity is the row that people underweight and then regret. A build is 2-4 weeks; the system lives for years. The question is not who writes it, it is who answers the phone when it stops working.
The cost comparison that is actually useful
Build cost favours the freelancer, usually by a lot. Twelve months of ownership is much closer.
Every automation carries running costs regardless of who built it. Model and infrastructure spend per decision. The time of whoever handles escalated exceptions, which is a real cost by design rather than a defect. And maintenance when the world around the workflow moves, which it does.
Ask both parties for a monthly running figure in writing, add twelve of them to the build price, and compare those totals. That single change makes most of these decisions obvious in either direction, and the four questions that break most ROI numbers apply to both quotes equally.
The arrangement worth considering
Split the work. Have the measurement and design done by whoever you trust to tell you the project is not worth doing. Have the construction done by whoever is cheapest for that shape of work.
The halves have different failure modes. Bad construction is cheap and obvious within days. A bad design is expensive and invisible for months. Splitting them also gives you a specification that several builders can quote against, which is the only way to make the price comparison mean anything.
The reverse arrangement is the one to avoid: hiring a builder first and then asking them what should be built puts the scoping decision with the party whose income scales with the scope. That is the same structural problem described in what a process audit must actually produce.
What neither of them should get away with
Two things, and they apply identically to individuals and firms.
Neither should quote before measuring. A price produced from a conversation is a guess about a process nobody has counted, and the measurement week that precedes an honest quote is cheap enough that skipping it is a choice rather than a constraint.
And neither should leave the decision about what stays human implicit. Anything binding, anything unusual, and anything the system is unsure about belongs with a person, and that boundary should be in the proposal rather than discovered later.
For how we structure our own engagements against these criteria, the comparison page sets out what we do and do not take on.
01When is a freelancer clearly the better choice?+
When the workflow is one process, the systems it touches are few and well documented, and somebody inside your company will own the result and is technical enough to change it. Under those conditions you are buying construction rather than a relationship, the specification can be written down completely before work starts, and the price difference is large and real. A good freelancer will beat an agency on cost and often on speed for exactly this shape of work, because none of the coordination an agency carries is doing anything useful here. The failure mode to watch is scope discovery: if the process turns out to touch four systems nobody mentioned, a solo engagement can stall in a way a team absorbs. That is a reason to spend a week measuring before contracting, not a reason to hire a bigger vendor by default.
02What exactly is the agency premium paying for?+
Three things, and it is worth checking that you actually need each of them before paying for all three. Breadth first: a workflow that spans a CRM, an accounting system, a messaging channel and a document store needs several kinds of knowledge, and one person good at all four is rarer and more expensive than a team that has them separately. Continuity second: an agency can lose a person mid-build without losing the build, which matters more the more the timeline is tied to a season or a deadline. Obligation third, and this is the one people underweight: someone contractually still there in month four when a supplier changes a form or a channel changes an API. A freelancer can offer all three and some do, but they are offering them as a personal commitment rather than as a structure, and personal commitments end when circumstances change.
03How do the two compare on cost once running costs are included?+
The build cost usually favours the freelancer clearly, and the total cost over the first year is much closer than the day rates suggest. Automation carries running costs regardless of who built it: model and infrastructure per decision, the time of the person handling escalated exceptions, and maintenance when the surrounding systems move. Those costs exist in both cases; the difference is who absorbs the maintenance and at what notice. A freelancer typically prices maintenance as new work at a new rate and subject to availability, which is fine when the system is stable and expensive when it is not. Compare the two on twelve months of ownership rather than on the build, and ask both parties for a monthly running figure in writing before signing anything.
04Can you mix the two?+
Yes, and it is a sensible pattern that gets used less than it should. Have the measurement and the design done by whoever you trust to tell you the project is not worth doing, then have the construction done by whoever is cheapest for that shape of work. The two halves have different failure modes: a bad design is expensive and invisible for months, while bad construction is cheap and obvious within days. Splitting them also gives you something to compare, because a design written down properly can be quoted by several builders. The one arrangement to avoid is the reverse, where a builder is hired first and then asked to decide what should be built, since that puts the scoping decision in the hands of the party paid by the size of the scope.


