The capability question is the easy one
Your developer can build it. In most cases that is simply true, and any comparison that opens by casting doubt on it should be treated with suspicion.
The interesting questions are different. What stops being built instead, and does a project with no deadline ever get finished.
The invisible price
An internal build costs whatever was next on the roadmap. That price never appears as a line item, which is why it rarely appears in the decision either.
If the thing your developer would otherwise ship is the product your customers pay for, the automation is expensive in a way the invoice will never show. If your team is genuinely under-loaded, the arithmetic flips and building internally is plainly right.
The useful move is to make it explicit. Name the feature or fix that will slip. Put a date on it. Show that date to whoever owns the roadmap and see whether the trade still looks obvious.
Why internal projects stretch
They compete with a roadmap rather than with a deadline, and a project with no delivery date has no mechanism for being finished.
The pattern is consistent enough to plan around. The build starts quickly and well. Then an urgent customer issue arrives, then a release, then somebody leaves, and the automation becomes the thing picked up between other things.
Six weeks of work spread across eight months is not the same as six weeks of work. The operational problem stays unsolved for those eight months, and the requirements drift underneath the half-built system.
External delivery is not faster because the people are better. It is faster because the work has a date, a fixed scope, and nothing else competing for the same hours. If you build internally, the fix is to give the project those three things rather than to hope.
What each side actually wins
| In-house | Agency | |
|---|---|---|
| Knows your undocumented systems | Yes | Learns them, at a cost of days |
| Has a delivery date | Rarely | By contract |
| Has seen this fail before | Sometimes | This is what you are buying |
| Still there in month four | Yes | Only if contracted |
| Depends on one person staying | Usually | No |
| Cost on the invoice | None | Real |
| Cost to the roadmap | Real | None |
The last two rows are the whole comparison, and they point in opposite directions. Everything else is a detail.
The arrangement that usually beats both
Not a choice. A division.
External delivery against a date, internal ownership from the first week. The person who will own the workflow sits in the build rather than receiving a handover document at the end, so the knowledge transfers by participation instead of by paperwork.
That is the model we work to, and it is why the named-owner condition belongs in the proposal rather than in the final week. It also produces the thing an internal build produces naturally and an external one often does not: somebody who genuinely understands why the system does what it does.
On hiring for it
Only if you have enough automation work to keep the person interested, and that bar is higher than it looks.
One automation engineer is a single point of failure in a way an agency is not. The work also has a retention problem nobody mentions: building the first three workflows is interesting, and maintaining them while the surrounding systems shift is not. Companies that hire for this and then run out of new things to build tend to lose the person inside a year and inherit a system only they understood.
If the pipeline is real, a workflow a quarter indefinitely, hiring wins on economics by a wide margin. If it is two projects and then maintenance, buy the builds and keep the ownership.
Before either
Neither route helps if the process is not ready, and neither vendor nor employee should be quoting before somebody has counted. The measurement week applies identically to an internal build, and an internal team is if anything more likely to skip the measurement because they already believe they know the process.
They usually know their part of it. That is a different thing, and why most process maps are useless is about exactly that gap.
Top comments (0)