In-house vs agency vs freelancer

The comparison

In-house: the honest test

The question is not whether an internal person would be useful. It is whether you have twelve months of genuine automation work lined up.

Most businesses under 200 people do not. They have three or four meaningful automations, then a long tail of small changes. That is perhaps four months of work in the first year and considerably less afterwards, which means either an expensive person underused, or someone hired for automation who is quietly reassigned to general IT and leaves within eighteen months.

Where in-house genuinely works: businesses with continuously changing processes, regulated environments where external access is difficult, or where automation is close enough to the product that the knowledge should stay inside. Full arithmetic on hire or automate.

Freelancer: cheapest, with a specific risk

A good automation freelancer is excellent value and we recommend the route regularly. The hourly rate is genuinely lower, there is no agency overhead, and for a defined build you can brief precisely, the outcome is often identical to ours at lower cost.

Two risks to manage rather than avoid.

Continuity. When they take a full-time role or get busy, you have automations nobody understands. This is entirely manageable: make documentation a contractual deliverable, insist credentials live in your vault, and get a recorded walkthrough. If a freelancer resists any of that, walk away.

Discovery. Most freelancers price against a spec you provide. If your spec is the happy path, and first specs almost always are, the build handles the happy path, and the exceptions come back as change requests. See the exception problem.

Firm: what you are actually paying more for

Not better engineers. A good freelancer is frequently as capable as anyone we would put on the work.

You are paying for four things: discovery done systematically rather than from your spec; process, error handling, parallel running, documentation as standard rather than as optional extras; continuity, meaning someone still exists in two years and is contractually obliged to answer; and estimating risk transfer, because a fixed setup price means overruns are the firm's problem.

Whether that is worth the premium depends entirely on the project. For a well-defined single-system build, probably not. For a five-system integration where nobody has documented the process, almost certainly.

When not to hire us

Stated plainly, because it should be.

• Your automation is a two-step Zap. Build it yourself this afternoon.
• You have a precise spec and a tight budget. A freelancer will do it well for less.
• You need continuous availability rather than delivered outcomes. That is a hire, not a firm.
• Your process changes every month. Automating something unsettled encodes a process you are about to abandon, and then you pay again to change it. See what should not be automated.
• An off-the-shelf product does it. See build vs buy.

How to evaluate whoever you pick

Four questions that separate firms and freelancers who have done this from those who have not.

1. "How did you arrive at this estimate, and who did you watch?" A quote from a one-hour call with a manager has priced a process that does not exist.
2. "What happens when this automation fails?" If the answer is not immediately about retries, alerting and dead-letter handling, error handling is not in the build.
3. "What documentation do we get?" It should be a named deliverable, not a promise.
4. "Whose accounts will this run in?" Yours. Any other answer creates a dependency you do not want.

What we would actually recommend