Your Developer Can Build It. That Is Not the Question
An internal build competes with your roadmap rather than with a deadline, and that difference decides more of these projects than any technical comparison.
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.
01Is it cheaper to build automation in-house?+
On the invoice, almost always. In total cost, it depends on something most comparisons leave out entirely, which is what your developer stops doing. An internal build has a real price equal to whatever was next on the roadmap, and that price is invisible because it never appears as a line item. If the thing they would otherwise be building is the product your customers pay for, the automation is far more expensive than it looks, even though no money changes hands. If your developers are genuinely under-loaded, the calculation flips and building internally is straightforwardly the right answer. The useful move is to make the opportunity cost explicit before deciding: name the feature or fix that will slip, put a date on it, and see whether the trade still looks obvious to whoever owns that roadmap.
02Why do internal automation projects take so much longer?+
Because they compete with a roadmap rather than with a deadline, and a project without a 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 someone leaves, and the automation becomes the thing that gets picked up between other things. Six weeks of work spread across eight months is not the same as six weeks of work, because the operational problem it was meant to solve stays unsolved for those eight months and the requirements drift underneath it. External delivery is not faster because the people are better; it is faster because the work has a date, a defined scope and nothing else competing for the same hours. If you build internally, the fix is to give the project the same three things rather than to hope.
03What does an in-house developer genuinely do better?+
Two things, and both are worth real money. They know your systems, including the undocumented ones, the field that means something different from what its name suggests, and the integration that somebody wrote four years ago and nobody has touched since. An external team spends its first days discovering exactly that, and in an unusual estate those days can be a meaningful share of the project. The second advantage is permanence: they are still there in month four when a supplier changes a form, and their knowledge of the workflow compounds instead of leaving with a contract. This is why the strongest arrangement is usually not a choice between the two but a division: external delivery against a date, internal ownership from the first week, so the person who inherits it has been in the room the whole time rather than receiving a handover document.
04Should we hire someone specifically for automation work?+
Only if you have enough of it to keep them interested, and that bar is higher than it first appears. One automation engineer is a single point of failure in a way an agency is not, and the work has a retention problem that nobody warns you about: building the first three workflows is genuinely interesting, and maintaining them while the surrounding systems shift is not. Companies that hire for this and then have nothing new to build tend to lose the person within a year and inherit a system only they understood. If the pipeline is real β a workflow a quarter, indefinitely β hiring is the better economics by a wide margin. If it is one or two projects and then maintenance, buy the builds and keep the ownership, which costs a fraction of a salary and does not depend on one person staying.
