DIY automation vs bringing in an engineer
2026-07-29 · 4 min read
The tooling got good enough that a determined owner can build real automation without writing code. That is genuinely new, and it means the honest answer to "should I just do this myself" is now sometimes yes.
It is also where a specific kind of expensive mistake starts, and the mistake does not show up for about a year.
The short answer
Do it yourself when the workflow is small, when you find the building interesting, and when nothing breaks badly if it stops. Bring someone in when the system becomes load-bearing, when it needs to survive you being on vacation, or when you have rebuilt the same thing twice because you could not tell why version one stopped working.
Side by side
| Doing it yourself | Bringing in an engineer | |
|---|---|---|
| Cash cost | Tool subscriptions | Build fee plus a flat monthly |
| Real cost | Your evenings | Money, which is easier to plan |
| Speed on simple things | Very fast | Slower, there is a scoping conversation |
| Speed on complicated things | Slows down sharply | About the same as simple things |
| When it breaks | You debug it, at whatever hour | Monitoring catches it, someone else fixes it |
| Documentation | Usually in your head | Part of the deliverable |
| Bus factor | One, and it is you | Handoff docs so your team can run it |
| Learning | You get better at this | You get your evenings back |
Where doing it yourself genuinely wins
You learn what you actually need. Owners who have built a few of their own automations are the best clients I get, because they arrive knowing which parts of the process matter. Nothing teaches you your own workflow like trying to describe it to a computer.
Small things stay small. A reminder, a notification, a form that files itself. Bringing in help for that is overkill and you would be waiting on someone else's calendar.
You can iterate at the speed of your own thinking. No scoping call, no back and forth. You have an idea at 9 p.m. and it exists at 10.
It is cheap to find out you were wrong. The best argument for DIY is not the money saved. It is that throwing away a bad idea costs you an evening instead of an invoice.
Where the hidden cost shows up
The system becomes load-bearing without a decision being made. This is the pattern, almost every time. Something built to save an afternoon becomes something the business cannot run without, and it is still held together by knowledge that exists only in one person's head.
Debugging is a different skill than building. Building an automation is satisfying. Working out why it silently stopped firing three weeks ago, and how many customers fell through in the meantime, is not. The second skill is most of the job, and it is the part DIY tooling helps with least.
Nothing is monitored. Owner-built systems almost never have monitoring, because monitoring is boring and invisible until the day it is the only thing that matters. The failure mode is not a system that crashes. It is one that quietly stops and nobody notices for a fortnight.
It stops being fun. Fine at first, then it is a Sunday obligation. When the interesting part is done and only maintenance is left, maintenance loses.
Nobody else can touch it. If you are away and it breaks, the business waits for you.
The version I actually recommend
Build your own small things. Keep building them. Then hand over the two or three workflows that the business genuinely runs on, the ones where a silent failure costs real money, and make sure those come with logging, monitoring, and documentation your team can follow.
That split respects both facts: you know your business better than any outsider will, and production systems need somebody who is on the hook when they break.
Fair warning about hiring anyone, including me
Ask whoever you bring in what happens when they disappear. If the answer does not include documentation, access you own, and a system that keeps running without them, you have swapped one bus-factor problem for a more expensive one.
At New Face Design every build ships with handoff docs so your team can run it, on tools you already pay for, in accounts you own. The free 20 minute process audit will tell you honestly which of your workflows are worth handing over and which you should keep building yourself. Sometimes the whole answer is "keep doing what you are doing," and you keep the process map either way.