Agency vs freelancer vs in-house for automation: who should build it

First, what does a silent failure cost? An automation that posts a summary to a chat channel and one that creates customer orders sit at opposite ends. The first can be built by almost anyone and fixed whenever. The second is load-bearing: a scenario that stops quietly and is discovered a week later by a customer is the real risk in automation, and the cost of that discovery sets how much review, monitoring and ownership you need around it.

Second, how steadily will it change? Automations touch other people's systems, and upstream tools change their fields, credentials expire and new exceptions appear. Budget some recurring time for upkeep rather than treating the build as finished on delivery. If your list of automations is long and growing, change is continuous and someone has to be there for it. If you need one integration built and left alone, it is a project.

A strong freelancer is often the best value for a well-specified piece of work, and for a single scenario or a single integration the overhead of an agency is not worth paying. You talk to the person who does the work, and nothing is lost in translation.

• Key-person risk. One person holds the understanding. If they are on holiday, unwell or booked elsewhere when the automation fails, you wait.
• No second pair of eyes. Work with no review is where tokens end up pasted into HTTP headers and where retries write twice. Ask who checks it.
• Platform bias. Someone expert in one tool will reach for it, including for jobs it does not suit. Ask what they would not build on it.
• Continuity. Ask what you can do if they leave. A runbook and an export of the work you own make this survivable.

Agencies make sense when the work crosses specialisms: a platform configuration, an API integration, a database underneath and an interface for people outside your licences. That combination is rarely held by one person, and an agency can also staff a surge. A rescue or a migration does not need a permanent hire.

• Handover overhead. You pay for management and communication as well as the build. For a small job it is not worth it.
• Who actually builds it. Ask to meet the people doing the work, not only the people selling it.
• An incentive to build. A firm that earns by building will lean towards building, even when the answer is a native automation inside a tool you already pay for. Test any agency, including us, by asking when they have told a client not to build something.
• Dependence. If the only person who can change it is at the agency, you have swapped one single point of failure for another.

We would add one fair test of our own work. The clients who gain most from outside help typically have a specific problem, a person who can make decisions, and a plan for who owns the result afterwards. Without the last of those, no builder can make an automation durable.

If you have a long list of automations, a process that changes monthly and domain knowledge that is the real asset, an employee who sits next to the work will outperform any outside party. They know why the exception exists. They are there at two in the morning, or at least on Monday.

• Price the person, not the hour. Salary, the platform seats, the time spent managing and the cost of the time before a hire is productive all count. A rough test: if you cannot keep one person usefully busy with this most weeks, you are hiring for a peak.
• Breadth. A single hire who is excellent on a workflow platform may not be the person to design a database with proper constraints. Know which kind of problem you have.
• Isolation. One engineer with nobody to review their work reproduces the freelancer problem inside your payroll.
• Hiring time. Recruiting takes time, and the problem does not wait.

These do not depend on which option you pick, and they sort good builders from poor ones quickly.

1. 01Whose account is it in? Platform accounts, the repository, the domain and the credentials should be yours from the first commit. If a build cannot be handed to another competent engineer without an introduction, it was built badly.
2. 02What happens when it fails at two in the morning? The answer should name where the alert goes, who sees it and what the run log shows. Silence on this is the answer.
3. 03Can I see a runbook from something you built? Ask for one that covers where it runs, how to restart it, where the credentials are and what the known sharp edges are.
4. 04What happens if the same event arrives twice? Retries writing twice is the failure that erodes trust fastest. A good builder talks about idempotency without being prompted.
5. 05What would you not automate here? A builder who cannot name something is selling a product, not giving advice.
6. 06How will we know it is working? Expect a shadow-mode period, where the new path runs beside the old one and logs what it would have done, before cutover.

A common pattern is to bring in outside help for the build, then hand it to a named internal owner with a runbook, and keep someone external on call for the occasional change. It treats the build as a project and the running of it as a job, which is accurate. It also keeps the in-house hire modest: one person who owns outcomes, not a person who must be an expert on everything.

On cost, we can only speak for ourselves. Most of our projects land between $5,000 and $10,000 (US dollars) and larger systems cost more than $10,000, which is a typical range and not a quote: we quote after a discovery conversation, because any figure given without your exception count would be a guess presented as data. We do not know what any other freelancer or agency charges and will not guess. Ask each candidate how they would estimate your job and which variable would move the number. A builder who cannot say what moves the price has not understood the problem.