Who builds your automation? The decision that outlives the tool

Your automation didn't break because of the tool. It broke because of who owned it.

Here's a story I've watched play out more times than I'd like. A company builds a slick automation. Orders flow into the accounting system, invoices go out, everyone's thrilled. Eighteen months later it quietly falls over on a Tuesday, and the only person who understood how it worked left the company back in spring. Nobody can fix it. Nobody can even explain it. They're staring at a flowchart nobody drew.

The interesting part is what everyone gets wrong about that moment. They think it was a tooling failure, or a person failure. It was neither. It was a decision nobody made on purpose: the decision about who builds and who runs this thing over its actual lifetime.

That decision is the most expensive one in automation, and almost nobody makes it deliberately. Someone had a free afternoon. A freelancer was cheap. An intern knew a bit of Zapier. And that accidental choice quietly determines whether your automation becomes an asset or a liability with a delay timer on it. This post isn't about tools. It's about the operating model underneath them, and why it matters more than any license fee you'll ever pay.

The tool is the wrong first question

When people come to me about automation, the first twenty minutes are almost always about tools. Make or n8n. Zapier or self-hosted. Power Automate, because we've already got Microsoft anyway. Fair questions, all of them. Just secondary ones.

A single workflow is rarely the hard part. A workflow is two afternoons of work. The hard part starts the day after: now something has to keep it alive. APIs change. Vendors rename fields. A rate limit that didn't exist yesterday is throttling half your runs today. A business rule shifts and last year's logic no longer fits. Automation isn't a project with an end date. It's an operation. And operations need an owner.

So the real question isn't which tool. It's which operating model. Who is responsible for this thing still running reliably in two years, who understands it when the person who built it is gone, and how fast can someone respond when it fails at a genuinely inconvenient hour.

There are basically four answers. You build it yourself. You hire a freelancer. You bring in an agency or a specialist provider. Or you hire and grow the capability in-house. Each one is legitimately the right answer in some situation. Each one carries a price that rarely shows up on the invoice. Let's walk through them.

Model 1: Build it yourself

The default, especially for smaller businesses and solo operators. Someone on the team taught themselves Make from YouTube and starts wiring things up. No external budget, full control, instant start. For a certain level of maturity this isn't just fine, it's correct.

Self-building is the smart move when a process is non-critical, when an outage ruins nobody's day, and when the logic stays simple. A solo consultant piping contact form submissions into her CRM and pinging herself on Slack does not need an agency. She needs an afternoon and a tutorial. If it breaks for a day, she notices and copies three entries by hand. No drama.

And the value isn't only the money saved. It's the understanding. People who build their own automations develop an instinct for what's possible and what's expensive, and that instinct pays off later even when they do hire help. The worst clients I've ever had were the ones who had no idea what they were actually buying. Having built a little yourself is the best vaccine against that.

Where it breaks is operational readiness. A process that moves money, sends invoices, or triggers legal deadlines does not belong to someone doing it on the side of their real job. Not because they're not smart enough, but because they don't have the time to do it properly: error handling, monitoring, documentation, tests. Those are exactly the parts a self-builder skips first, because they're invisible and the workflow runs fine without them. Until it doesn't. And the bus factor of a self-built system is almost always one. Exactly one human knows why it works the way it does. When they leave, the knowledge leaves with them.

Model 2: The freelancer

The next step for a lot of companies. A freelancer builds what nobody internal can or wants to. You'll find people on the platforms who know Make and n8n cold, often at day rates well below an agency's. For clearly scoped tasks, it's a good model.

Freelancers shine when the job is finite and describable. "Build me an automation that pushes new Shopify orders into our accounting system with this field mapping." Clear brief, clear deliverable, clear price. A good freelancer ships that faster and cleaner than an internal amateur ever could, and they've probably built the same thing three times before.

The failure mode is continuity. The typical freelancer problem is the handoff. Job done, invoice paid, freelancer moves on to the next client. Six months later the workflow breaks and they're fully booked, have forgotten the context, or aren't even on the platform anymore. The bus factor is still one, it just sits outside your building now and stops sending invoices when it disappears.

Then there's documentation. Plenty of freelancers build fast and functional, but not for the next person. Why a particular branch exists, which edge cases were deliberately handled and which were silently ignored, none of it is written down anywhere. You've got a running system and no map of it. As long as it runs, nobody feels the problem. It's latent damage that only surfaces on the first outage. If you work with freelancers, make handoff and documentation part of the deliverable, in writing, with sign-off. And build a continuous relationship instead of one-off projects wherever you can. A freelancer who knows your stack and stays reachable is worth a lot. One who builds once and vanishes leaves you with the same single-person dependency as self-building, plus an invoice.

Model 3: The agency or specialist provider

Past a certain size and criticality, companies land with us or with people like us. An agency or specialist automation provider brings something a lone freelancer structurally can't: redundancy. It's not one person who knows your setup, it's a team, processes, documentation standards, and ideally cover when someone's out sick.

What you're actually buying from an agency isn't clicks in Make. It's operational safety. The fact that someone sets up monitoring before anything goes live. That failures get caught before your customer reports them. That there's a documented state that doesn't live inside one person's head. A good provider isn't selling you the workflow, they're selling you the confidence that it'll still run tomorrow and that someone understands it.

But there's a real objection to the agency model, and it's this: building isn't running. A lot of providers are excellent at building and lose interest afterward. They ship a clean project and disappear into the next one, and you're left with a system that's well documented but orphaned. When something breaks, the original builder is long gone, and you're paying hourly for someone to re-learn a system your own agency built.

So when you're picking an agency, the decisive question isn't "can you build this." Almost everyone can build. The decisive question is "what happens the day after go-live." Is there a maintenance agreement, a defined response time, a named contact. If the answer gets vague, you're buying a project, not an operating model. And a project doesn't solve your actual problem.

I worked with a logistics company, around 300 people, that had spent two years cycling through freelancers. The result was a patchwork of thirty automations nobody understood as a whole, with contradictory naming and zero overview of which workflow touched which data. We spent the first week just mapping it. Not building, understanding. That's the price of missing continuity, and it gets paid later, with interest.

Model 4: Build it in-house

The fourth model is hiring or training internal people until automation is a genuine in-house capability. For larger organizations this is often the end state: an internal team, or at least a named role that owns automation. Full control, full knowledge, immediately reachable.

When does a dedicated hire pay off? The honest answer is arithmetic. A full-time person focused mainly on automation costs you, fully loaded, easily 70,000 to 90,000 euros a year. That only makes sense once there's enough work to keep them usefully busy and the processes are critical enough that fast internal response genuinely pays. As a rough rule of thumb: below roughly fifteen to twenty productive, business-critical automations, a dedicated internal hire is usually oversized. Above that threshold, and especially when automation feeds your core business, in-house stops being a cost and becomes risk management. Critical capability belongs in the building.

The trap here is the same bus factor wearing a suit. I regularly meet organizations proud of their "automation person," the one gifted colleague who built everything and understands everything. That's not an internal capability. That's a freelancer with a permanent contract and the same risk, except now there's also a notice period and a rehire when they go. Real internal capability means at least two people who can cover each other, plus written standards both of them follow. Anything less is a one-person dependency in nicer clothing.

The costs that never make the invoice

Every one of these models has a visible price and an invisible one. The visible one is in the quote: day rate, salary, retainer. The invisible one is where most decisions go wrong, and it comes down to four things.

First, response time when something breaks. If a business-critical automation dies at 10pm on a Friday, how long until someone responds. For self-building and one-off freelancers, the answer is often: Monday. For an agency under contract or an internal team: minutes to hours. That gap costs nothing while nothing happens, and a great deal the moment something does.

Second, the bus factor. How many humans understand the system. At one, every automation is a bet that this one person stays, stays healthy, and has time. That bet pays off for a long while. And then, once, it doesn't.

Third, handoff-ability. Is there documentation that lets a newcomer take over without reverse-engineering the whole thing. Missing documentation is a loan you take out without noticing, and it comes due at the first staff change.

Fourth, strategic dependency. If all your automation knowledge sits outside the building, you don't own the engine of your own operation. That's fine while the relationship is good. It stops being fine when the provider raises prices, shifts focus, or shuts down.

The table doesn't point at a best model. It shows that each one wins and loses on a different axis. The skill isn't picking the best model, it's picking the right one for the specific process in front of you.

The hybrid that actually works

Most mature setups I know aren't pure models. They're blends, and the smartest blend separates two things people love to lump together: building and running.

What works best in practice is a clean split by criticality. Non-critical, simple automations get built and run by the team itself. Whoever wants a Slack notification should build it, no one else needs to be involved. Complex or business-critical automations get built externally, with proper documentation, and then deliberately taken in-house or kept under contract. Building is the expensive, rare activity. Running is the cheap, permanent one.

A pattern I recommend a lot: have it built externally, but make the handoff a condition. A good provider doesn't just build, they enable. By the end of a project, someone from your side is at the table, understands the architecture, has the documentation, and can make small changes themselves. The agency stays for the big stuff and the emergencies, but you're no longer dependent on them for every trivial tweak. That lowers your ongoing cost and your bus factor at the same time.

How do you spot a provider who means it? By their attitude to handoff. Anyone who keeps you deliberately dependent, who only hands over documentation for an extra fee, who treats knowledge as leverage, is optimizing their own revenue, not your operation. Anyone who actively enables you, even at the risk that you'll need them less, is thinking long term. That's the one you want.

A practical way to decide

Two questions get you most of the way: how critical is the process, and how many automations do you run in total.

Solo operators and very small teams with a handful of non-critical automations: build it yourself, pull in a freelancer for the occasional thing that's over your head. An internal team would be absurd and an agency usually oversized. Invest in your own understanding instead.

Growing companies with a double-digit count of automations, some of them business-critical: this is the classic point for a continuous provider or a steady freelancer plus baseline internal skill. Secure the critical stuff externally, do the simple stuff yourself, force the handoff.

Larger organizations with lots of critical automations in the core business: build internal capability, at least two people, with an agency as reinforcement for peaks and specialist cases. Here in-house isn't a luxury, it's risk management.

One question I get a lot: should you ever fully outsource a business-critical automation? Honest answer: building, yes; running, only with a contractually guaranteed response time, and never without an internal handoff. If you put a process your business depends on entirely in someone else's hands without understanding how it works, you don't have an automation problem anymore, you have a control problem. The automation can live outside. The control over it has to stay inside.

What I've taken away from all this

After years in this business, my conviction is simple: the tool is rarely the reason automation fails. The operating model almost always is. I've watched clean systems in Make die because the one person who understood them walked out the door. And I've watched inelegant n8n workflows run stably for years because two people looked after them together and both knew what they were doing.

Two things I carry out of every project. First, separate building from running in your head before you separate who pays for what. Building is an event, running is a state, and most bad decisions come from paying for the event and forgetting the state. Second, fight the bus factor of one in every model, whether that one person sits inside or outside your walls. A system only one human understands isn't automation. It's a time bomb with a pleasant runtime.

If you're not sure which model fits your operation, or whether your existing automations are hanging off a single human, take a look at our free automation check. We'll go through how your automations are actually run, where your bus factor sits, and which model genuinely holds up for your size and your level of risk.