I talk to agency owners every week who say some version of this: we built our own automations, it took a while, but they work.
When I ask how long a while was, the answer is usually somewhere between forty and two hundred hours. When I ask who built it, it is almost always the owner, or a producer who got technical.
That cost has a name worth using, because naming it is what makes people count it. Call it the builder’s tax.
I want to be careful with this piece, because it sits in a room full of people who are about to go build things, and I am not trying to talk anybody out of it. Building your own is frequently the right call. The point is to count the cost before you commit to it rather than a year in.
What the tax is made of
Most agencies track the software line item. Almost nobody tracks the other four.
The build. Learning the platform, mapping the process, building it, testing it. This is the part people do estimate, and it is the smallest part.
The maintenance. Fixing what broke, handling the edge case nobody predicted, updating the thing when the process changes. This never ends and it does not shrink. It grows with the number of things you have built.
The opportunity cost. If you are a producing owner, every hour spent building is an hour not selling. That is real money and it does not appear on any invoice, which is exactly why it feels free.
The knowledge risk. This is the expensive one. When the person who built it leaves, or just gets busy, you inherit a black box. Nobody knows how it works. Nobody wants to touch it. When it breaks, it stays broken.
Why people build anyway
Three reasons, and two of them are mistakes.
You can see the monthly price of the thing you would buy. You cannot see the hundred and twenty hours you are about to spend. Time feels free until you total it up, and then you discover you paid thirty thousand dollars for the free option.
You want control. Building it yourself means you can change anything, any time. That is genuinely valuable right up until you notice you are also the only person who can fix it, and it will need fixing.
And the third reason, which is fair: a lot of what you could buy is too generic, or it forces you into somebody else’s idea of how an agency runs. If the tool does not fit how you operate, building is the correct answer. The mistake is not evaluating the tool at all and assuming it will not fit.
The era three version of the tax
Everything above was true when the thing you built was a rule tree. It is still true, and there is a new line item.
Skills and scheduled tasks break when a vendor changes their interface.
The endpoints have been reasonably stable for close to a year now. That is long enough to feel permanent and it is not permanent. This is a when, not an if. Somebody will restructure an API, deprecate a field, change how authentication works, or ship a model update that reads a document slightly differently than the one you tested against.
When that happens, your build stops. Possibly loudly, which is the good case. Possibly quietly, which is the case that costs you, because a scheduled job that silently stops producing output looks exactly like a quiet week.
So the questions to ask before you build have gotten shorter and blunter.
The second question is the one people skip, and it is the more important of the two. A build that fails loudly and dumps the work back into a queue somebody is already watching is a fine build. A build that fails silently is a liability regardless of how well it works on a good day.
What actually reduces it
You cannot eliminate the tax. Somebody has to build this stuff and somebody has to own it. You can make it smaller.
Do not build what is genuinely common. If ninety percent of agencies do lead routing the same way, that is not where your judgment is worth spending.
Build fewer things and finish them. Three things running well, that you understand, that fail loudly, beat twelve half finished ones. This is the same discipline as everywhere else in this hub and it keeps being the answer.
Write down how it works while you are building it, not after. Not a manual. A page. What it does, what it touches, what it looks like when it is broken, and who to call. The version of this you write during the build takes twenty minutes. The version you write a year later, from memory, under pressure, takes a day and is wrong.
And be honest about which category you are in. Some agencies have someone who genuinely enjoys this work and will still be there in three years. That is a real asset and building is a good use of it. Most agencies have an owner who got interested on a Sunday, and that is a different situation with a different right answer.