Sometimes I keep my Computer open for multiple days in a row, and, recently it got me into a situation where it ran out of memory:
The machine has 48 Go of RAM. ghostty reached 43 Go usage and was increasing indefinetly, 16 Go for Zed…
These memory leaks, in a far stretch made me think about how complexe these apps must be under the hood, and how professional and experienced software engineer also make mistakes. Even in the age of agentic coding, if not more.
Which led me to think about, how is the standard company or normal day to day person, supposed to replace all of their software, by coding themselves, as predicted by the “SaaSpocalypse” rational ?
Not everyone can build what they want#
Agentic coding lowers the barrier, but it doesn’t remove it. Someone who can’t read code can’t tell whether the output is correct, secure, or even doing what they asked. They can get a demo working, but when it breaks in a way the agent can’t fix, they’re stuck.
The gap between “it runs on my screen” and “it’s reliable” is exactly where engineering lives, and that gap is what a memory leak in a mature tool reminds us of.
Someone still has to maintain, host and secure it#
Writing the code is the cheap part of software’s life. What comes after is the real cost: hosting, monitoring, upgrading dependencies, patching vulnerabilities, handling backups, being on call when it fails at 3am.
Every tool a company builds is a tool it now owns, forever. Buying software is largely buying someone else’s commitment to keep it alive.
Some people don’t know exactly what they want#
A blank page is a hard place to be. Many users can’t specify their ideal tool upfront, and they discover what they need by using something that already has a point of view.
Opinionated software makes decisions for you: a workflow, a vocabulary, defaults that come from watching thousands of teams. Building your own means making all those decisions yourself, and most people would rather not.
Software is made of accumulated edge cases#
A mature product is years of bug reports, odd inputs, and “oh, that case too”. That knowledge is invisible in the interface but it’s most of the value.
An agent can generate the happy path in an afternoon. The long tail only appears after real users have broken it, which is exactly what a rewrite throws away.
Shared tools are also shared standards#
Software isn’t only a feature set, it’s a common language. Onboarding is easier on a tool people already know, integrations exist because many companies use the same products, and hiring is simpler when candidates have used your stack.
A bespoke tool is, by definition, one nobody else knows how to use.
Maybe the question is right after all#
I’ve spent this article defending existing software, but let’s be honest about the other side.
Many companies pay for large products while using a tenth of the features, and a small internal tool could cover that tenth for much less. As building gets cheaper, the break-even point between “build” and “buy” moves, and it will keep moving. Plenty of tools that never justified an engineer’s time before suddenly do.
The model may also change: fewer giant platforms, more small, disposable, tailor-made tools, with professional software retreating to the hard, critical, and shared parts. And my memory-hungry terminal is the reminder in both directions: if experts ship leaks, maybe the standard isn’t perfection, only “good enough for the job”.
So where does the line fall? What would you rather own, and what would you rather pay someone else to worry about? I tend to personally think a lot of people pay for convenience. And in an era where much cognitive load is being offloaded to LLMs, this might be even truer.