liquid software: why now is the time for mid-sized companies to invest in custom software
the economics of build-vs-buy have shifted irreversibly. not someday. now.
"who's going to maintain all of this?"
anyone who has worked in a company with a responsible cto has heard this sentence. for the last 30 years it was usually the end of any discussion about building custom software. and it was justified.
the math was clear: custom software for internal tasks — marketing tools, hr workflows, industry-specific processes — it almost never pays off. you need at least two developers, months pass before anything goes into production, and then the real work begins: updates, security patches, adapting to new requirements, infrastructure.
the ongoing costs were systematically underestimated. not by ten or twenty percent, but by multiples.
you can observe this best in germany's public digitization projects [1, 2]. the logic was always the same: we build project a, then b, then c. this logic never worked.
a paper-form-driven process can be designed once by qualified employees and then maintained for years with minimal effort. a digital project requires permanent ongoing work by specialists. this was the real reason: not a lack of will, but a fundamentally flawed cost calculation.
the old equation: saas was always cheaper than building it yourself
this exact cost equation made saas the dominant model. and saas providers exploited it shamelessly.
pricing was always calibrated precisely so that custom development wouldn't pay off. five euros per user per month sounds like nothing — until you realize that for 200 employees you're paying 12,000 euros a year for a tool that does eighty percent of what you need.
the missing twenty percent? you adapt your workflows to the software. not the other way around.
companies have built their processes around the limitations of their saas tools for years. the lock-in didn't come from technical barriers alone, but from economic ones: as long as "building it yourself" was unaffordable, there was no exit option.
add to this the dark patterns of the saas industry: usability isn't the priority — lock-in is. the ui looks simple at first glance, but beneath the surface there are dozens of small quirks that employees need to be trained on, or worse, that need to be maintained manually.
anyone who has ever watched someone from the marketing department manage google ads knows exactly what i'm talking about.
the disruption: one person can now do what used to require a team
these rules have changed. not gradually, but fundamentally.
ai-assisted software development has reached a point where the build-vs-buy equation tips. a single person can now build an internal tool that would have previously required three months with a small team, in one to two weeks.
this is not a marketing claim. this is my daily experience.
"plan for a long time, develop for a long time, then discover that the stakeholder actually needed something different" becomes "i build the prototype in a few days and iterate directly with the users."
the leverage isn't just speed. the real breakthrough is what happens to the development process itself: the feedback loop that used to take months shrinks to days.
this applies especially to internal tools: applications on the intranet that don't need to meet the harsh requirements of the open internet. no compliance with every browser since 2015. no scaling to millions of users. instead: a tool that does exactly what the thirty people in the department need. and it's ready tomorrow.
the maintenance question, revisited: ai handles the routine work
and maintenance?
"who's going to maintain all of this?" was the right question in a world where every code change meant human labor. in a world where ai can handle routine updates, security patches, and adjustments, the answer changes fundamentally.
humans steer conceptually: what should the software do? how should processes evolve? the machine handles the implementation.
i deliberately don't say that maintenance will be "fully automated." anyone who claims that has never seen a legacy system. but the cost of maintenance drops so dramatically that the old calculation — "ongoing costs make custom development uneconomical" — no longer holds.
what this means for saas: the numbers speak clearly
the saas industry already feels it.
aggregate net new arr across all cloud software companies fell from $2.33 billion in q1 2024 to $1.65 billion in q1 2025 [3, 4]. valuation multiples have dropped from above seven to below five [5].
"in the agent era, business applications will collapse. all business logic migrates to the ai layer."
— satya nadella, bg2 podcast, december 2024 [6]
saas won't disappear. but the balance of power is shifting. the lock-in breaks because the alternative — "building it yourself is even more expensive" — is falling away.
the new role: software designer, not ticket worker
everyone says software development is over. that's only partially true.
what disappears is the job where someone works through tickets without understanding the context. that was never particularly useful. now it's redundant.
the software designer asks: how should this actually work? they think in systems, understand processes, ask the right questions — and put the answer in the hands of users as a working prototype within days.
this is a fundamentally different competency than programming. it's the ability to see a problem, understand it deeply, and design a solution that optimizes the workflow — instead of pressing it into an existing tool.
this competency becomes the new playing field where companies build real competitive advantages.
from rigid to liquid software
the transformation can be summarized in one image: from rigid software that dictates processes, to liquid software that adapts to processes.
before: a lengthy, structured development process that should be avoided wherever possible, because costs were always multiples higher than planned.
now: software that does what the company actually needs. that can be adapted agilely. that maps the optimal workflow, instead of adapting the workflow to a saas tool.
ai will never be worse than it is at this point. the tools that enable a tenfold productivity gain today are the worst version of what's coming.
whoever doesn't make the switch now won't fall behind slowly. they'll suddenly realize that the competitor who builds their own internal software iterates faster, is better adapted to their customers — and pays less for tools that can only do eighty percent of what they need.
the question is no longer "does custom development pay off?" the question is: "can we afford not to do it?"
five implications, if this is right
1. change management becomes a survival question
change management is hard and fails more often than it succeeds. every software development department now faces a transformation with few historical parallels — and the few that exist are sobering.
when electric motors replaced the steam engine in the 1890s, most factory owners simply swapped the drive: same factory, same layout, barely any productivity gain. economic historian paul david showed [7]: only the companies that rethought their entire production around distributed electricity made the real leap. that took a generation.
the parallel is almost uncanny: whoever simply plugs ai into their existing development process — same jira boards, same sprints, just faster — will barely benefit. whoever rethinks the process itself, wins everything.
2. the old tools can go
jira boards, sprint plannings, story point estimates: artifacts of an era where development time was the scarcest resource.
the problem: it's not yet clear how to effectively manage the new work organization. it will have new problems that require new structures. whoever clings to the old structures, loses.
3. good developers aren't automatically good software designers
the software designer can communicate well, can think themselves into other people's workflows, can structure and creatively develop solutions. these are soft skills that barely appear in traditional developer education.
some developers will make this leap, others won't — and that's less a question of intelligence than of personality.
4. companies without their own development should start now
not hiring ten developers, but two or three people who think in systems and can work with ai tools. that's tomorrow's competitive advantage.
5. it's ok to be sad
whoever has drawn pride from carefully thinking through detailed tasks and writing elegant code is losing something that meant something to them emotionally. that's sad and that's ok.
but it doesn't change reality.
translated from the german original by claude opus 4.6
how did you like this post?