What we built to use ourselves first.

Automating other people’s processes is a job made of choices. On almost every project there comes a point where one step in the flow depends on an off-the-shelf tool, and deciding which one to use falls to us. For a long time we made that call from the outside: reading documentation, testing for a week, trusting the pricing page. The client found out the rest: the limit that only shows up under month-end volume, the support team that takes three days to reply, the price increase that lands on the contract anniversary.

Building our own was how we brought part of that decision in-house. None of the tools above came out of a portfolio meeting. Each one came from a bottleneck that hurt our own operations or a client’s first, and that we couldn’t solve by buying something. When the same problem shows up for the third time at three different companies, it’s no longer an exception, and it becomes worth the cost of building.

The bar for starting is conservative on purpose, and it’s worth stating: only what we use in our own day-to-day becomes a product. It’s an annoying filter, because it throws out good ideas nobody in here would use. But it’s the only one that keeps a project-based firm from turning into a software factory that nobody operates.

The most useful part is the most boring to explain: we now have firm opinions on maintenance cost. When an automation can be solved three ways, the choice is rarely technical. It’s about who will maintain it eighteen months from now, how often the vendor changes the rules of the game and what happens the day the person who understood it leaves the company. Whoever delivers and walks away doesn’t have to answer that.

It also changed what we’re willing to build from scratch. Having written our own software makes the size of the commitment behind every new tool very clear: documentation, updates, migrations, the day it breaks. That’s why a good share of the recommendations that come out of our projects is not to build: use what already exists, or simply stop doing the step whose purpose nobody can explain.

And there’s a direct effect: sometimes the missing piece in the flow has already been built. When that happens, we say where it comes from and what it costs, and the decision stays with the client. What doesn’t happen is one of our products entering the scope for convenience. The bar is the same one we apply to third-party tools.