Should your own team build your automations, or should you bring someone in?
Build in-house when someone on your team has the skill and spare hours, and the workflows are simple and stable. Bring someone in when the build would come out of billable work, when nobody wants to be the one fixing it at night, or when it has to outlast the person who built it.
If you want automations, you may already have someone who could build them: an ops lead who's good with tools, a developer between projects, or the owner on a Sunday. The skill may well be there. The harder parts are the hours, the night it breaks, and the day that person leaves.
I'm the outside option on this page, so weigh my side with that in mind. Building in-house is the right call in several of the situations below, and the picks say which.
| What you're weighing | Your own team builds it | You bring someone in |
|---|---|---|
| Whose hours it takes | Someone whose week is already full of client work or their own job. When a client deadline lands, the automation waits. | An outsider's, plus the hours you spend explaining how the work runs. |
| What it costs | There's no invoice. The cost is billable hours, or management attention, that you don't get back. | A fee for the build, and for looking after it if that's part of the deal. |
| Who fixes it when it fails at night | Whoever built it, if they see the alert. They built it on the side, so it lands on top of their day. | Whoever the agreement names. A one-off build ends at delivery, so check that someone is named after that. |
| Whether it gets written down | Only if someone asks for it, since the builder already knows how it works. | Handover docs can be written into the agreement, so ask for them by name. |
| When the builder leaves | The logins, the workarounds and the reasons behind each step leave with them, unless they were handed over. | The same risk from outside. Your cover is your data, automations in your own accounts, and handover docs. |
| Knowing your process | Strong. They know the clients, the odd cases and the workarounds nobody wrote down. | Weaker at first. An outsider has to learn the process, which is why mapping the workflow comes before building. |
Where each one fails
When your own team builds it
The first risk for an in-house build is time. Building automations is the job that waits whenever client work gets busy, so a half-built workflow can sit for weeks while the old manual way carries on beside it.
Then comes the night it breaks. An app renames a field, a run fails, and the alert goes to the person who built it in their spare hours. If they're asleep, away or deep in a client deadline, the leads or tasks it was handling wait too. When that person leaves, the logins, the workarounds and the reasons behind each step go with them, unless someone wrote them down while they were still there.
A software or implementation firm is in a different spot. Your people already build and look after systems for clients, so you have the skill. What decides it is whether an internal build gets the same care as client work: a named owner, alerts that reach someone, and docs. If it does, build it yourselves.
When you bring someone in
Bringing someone in fails when the outsider never learns how the work runs. A builder who starts from the tool automates the steps as someone described them in a meeting, and misses the workarounds your team does without thinking. That's why I map the workflow before I build anything.
It also costs attention up front. Someone on your side has to explain the process, answer questions and check the result. And a one-off build has the same leaving problem as an in-house one: when the project ends, nobody may be looking after it. If that matters, make looking after it part of the deal, or keep it in-house.
Which one to pick
- If someone on your team has the skill and spare hours, and the workflows are simple and stable, build in-house. Give that person the job by name, with time set aside for it.
- If you run a software or implementation firm and your people already look after systems for clients, build in-house and run it like a client project, with an owner, alerts and docs.
- If you're unsure, build one small workflow in-house first. How it goes tells you whether your team has the time to keep it running.
- If the only person who could build it is also the one doing billable work, count what those hours earn on client work before you hand them the build.
- If nobody wants to be the one fixing it at night, or the system touches clients every day, bring someone in and make looking after it part of the deal. That's the embedded operator arrangement, and it's how I work.
- If you're bringing someone in, the comparison of freelancers, agencies and embedded operators covers who it should be.
Questions
Can't our developer just build this?
Yes, if they have the time. Check two things first: whether their hours would otherwise go to billable work, and who gets the alert when it fails at night. If both have good answers, build it in-house.
Is it cheaper to build automations ourselves?
It looks cheaper, because there's no invoice. The cost is the hours: billable work or management time you'd have spent elsewhere, plus the hours of looking after it later. Count both before you decide.
What happens when the person who built our automations leaves?
What they knew leaves with them, unless it was written down. Ask for handover docs while they're still there, covering what starts each automation, what it changes and where its alerts go. Move any logins they set up to an account the business owns.
Who should own our automations internally?
One named person, with time set aside for it, who gets the alerts and keeps the docs current. When a system belongs to everyone, nobody notices when it stops.
Can we start in-house and bring someone in later?
Yes. Keep your data in tools the business controls, keep the automations in the business's own accounts, and write down what each one does. Then whoever comes in later starts from what you've built.
Related
- Should a freelancer, an agency or an embedded operator build your automations?A public template, a freelancer, an agency or an embedded operator: where each fails, and what you hold if the person who built it disappears.
- Should I hire an operations coordinator or install a system?What an operations coordinator costs a year, set against installing a system: where each one fails, and which to pick first when your agency is growing.
- n8n vs Zapier vs Make: which should a service business run on?What each one bills for, who can change a workflow, what happens when a step fails, and where n8n, Zapier and Make each fall short for a small service firm.
- Questions to ask anyone building your automationsQuestions to ask an automation builder before you hire them, with what a careful answer sounds like and the answers that should worry you.
- What does coordination cost your business each year?Turn your leads, proposals and active projects into the hours your people spend coordinating each month, and what that time costs you in a year.
- HandoffA handoff is the moment work passes from one person, team or tool to the next. Why work waits and details get lost there, and how a system carries them.