The biggest argument against building custom tools has always been maintenance.

You build it, it works, the person who built it moves on, and now you have a codebase nobody wants to touch. Classic. Fair criticism. I’ve seen it happen more than once.

But something shifted recently. And I think most teams haven’t fully processed how big the shift is. A year ago, building a production-grade internal tool meant pulling an engineer off the product for weeks, most likely months. You’d weigh that cost against a 50€/month SaaS and the SaaS would win every time. Obvious.

That math broke.

The time to go from “I need this thing” to “I have a working version” collapsed. Not by 20%. By an order of magnitude. One person can now build in days what used to take a small team weeks. And the result isn’t a hacky prototype — it’s a real thing, with tests, with proper architecture, that you can actually hand to someone else.

That changes everything downstream. The maintenance argument? If you can iterate on a feature in an afternoon, carrying it costs less. The bus factor? If the architecture is clean enough that someone new (or something new) can reason about it, the risk drops.

I’m not saying build everything. Most of the time, buying is still right. But the threshold for when building makes sense quietly moved, and it moved a lot further than the “just buy a SaaS” crowd realizes.

We tested this internally. One person. One tool. In Production for months.

More on that soon.

Media