The build-versus-buy calculus has quietly shifted. For a lot of internal tooling, building something exact is no longer the expensive option.
For years, the build-versus-buy conversation had a predictable ending. Unless you had genuinely unusual requirements, or deep enough pockets to justify the overhead, the sensible move was almost always to buy. Off-the-shelf software had the safety of scale behind it: a bigger team, a longer roadmap, thousands of other customers finding the bugs before you did. Bespoke development was the expensive, slower option you reached for only when nothing off-the-shelf would bend far enough to fit.
Over the last few years, that calculus has quietly shifted.
We noticed it properly when we set out to fix our own HR management. Like many small agencies, we’d gotten by for a long time with patched-together tools and processes - using whatever was fastest at the time and got the job done. But prompted by a growing team and maturing processes, frustrations with the platform we were using started to pile up. Limited by the available tools and with a long list of feature requests, our need for a system that fit our needs had us searching high and low for the right SaaS offering. A few spreadsheets of feature comparisons later, the writing on the wall was clear: nothing out there quite had our backs.
Each offering came with the same quiet tax that off-the-shelf HR tools always carry: workflows that almost matched ours, fields we didn’t need sitting next to fields we did, whole sections of functionality we didn’t have a use case for, or whole features that were missing from certain choices. None of the systems were wrong, exactly. But none really fit the bill either.
So we did what any responsible software agency would do: we built our own.
We might not have made this choice a few years ago. The price of building a tool for ourselves would be measured not just in internal cost, but in lost revenue while resources worked on internal tooling - a scary prospect for any boutique agency.
So why did we choose to do so now?
The economics have moved
The answer starts with the team, not with the market. Over the past two years, every designer, analyst and developer has effectively had an upgrade - not a new laptop or a faster pipeline, but a genuinely different way of designing and creating software with LLMs. The initial 70% of any internal tool - scaffolding the data model, generating first-pass CRUD interfaces, wiring up authentication and role-based permissions - used to be where weeks quietly disappeared. That work is now compressed into days. We’ve created a template application from which any new tool can begin development, baking in our preferred auth patterns, SaaS organisation, permissions, CI/CD baselines and anything else we think of.
That’s not quite the same as saying the work got easier. What changed is where the hard part sits. The scaffolding got faster, which meant the team’s attention - the part that’s genuinely expensive and can’t be automated - went where it actually mattered: capturing and designing the workflow logic specific to how we operate. We started the journey with a list of feature requests, and because the foundations were quick to lay down we could get straight into those features from the first week.
It wasn’t frictionless throughout. Learning how to work effectively with AI has been a long road, and it’s an ever-changing landscape. Early efforts were focused on getting the best results via the most specific prompts, ensuring that vibes didn’t generate slop, lack of specificity didn’t cause spaghetti, and that the output was reviewable in a sustainable way. Things went wrong, code had to be thrown away, assumptions caused delays - but still the evidence was clear. There were serious productivity gains to be had.
The troubles we experienced while navigating this new process are worth stating plainly, because the pitch for AI-accelerated development too often skips the part where you still need to know what good looks like in order to catch what doesn’t. The acceleration is real, but it accelerates a process that still needs a competent engineer steering it. It certainly doesn’t replace the need for one.
A different default
So what’s changed over the last two years isn’t that bespoke software has become free. Rather, the gap between “buy something close enough” and “build something exact” has narrowed to the point where, for a lot of internal tooling, building is no longer the expensive option.
That reframes the decision. The old logic was: buy unless your requirements are unusual enough to justify the premium. The new logic is closer to: build unless the off-the-shelf option is a perfect fit, because the premium for building your own has dropped far enough that “close enough” no longer looks like good value.
An HR system that exactly matches how a 20-person agency actually operates - the right features for our team, no workflow compromises, and no vendor roadmap dictating what we can and can’t do next - is a meaningfully better outcome than a good-enough SaaS product.
This isn’t an argument that off-the-shelf software is obsolete. For genuine commodity problems - accounting, payroll compliance, anything where the regulatory surface area is the hard part - buying still wins, for now.
But for the layer of internal tooling that sits closer to how a specific team actually works, the case for reaching for a subscription by default is weaker than it’s been in a long time.
We build solutions to other people’s specific problems for a living. It would be a strange kind of inconsistency to keep buying generic tools for our own.
How many of the “close enough” services we currently rent could now be replaced with something ideal?
See the original post on Matt's website: tiltedsky.net(opens in new tab)