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 of a digital solution 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 move on to 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 why digitization in germany has failed so often: not a lack of will, but a fundamentally flawed cost calculation.

the old equation

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.

this is a trade-off that is systematically underestimated. companies have built their processes around the limitations of their saas tools for years. not because the tools were bad, but because the alternative, custom development, was always more expensive than adapting your own processes. 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.

fundamental disruption

these rules have changed. not gradually, but fundamentally.

ai-assisted software development has reached a point, at the latest with the release of claude opus 4.5, 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.

the leverage isn't just speed. the real breakthrough is what happens to the development process itself: "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 future users." 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. no saas-level security audits. instead: a tool that does exactly what the thirty people in the department need. and it's ready tomorrow.

the maintenance question, revisited

and maintenance? here comes the second part of the shift.

"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. and that changes everything.

what this means for saas

the saas industry already feels it. the quarterly numbers speak clearly: aggregate net new arr across all cloud software companies fell from $2.33 billion in q1 2024 to $1.65 billion in q1 2025, a decline of 29 percent [3, 4]. while the s&p 500 rose 17.6 percent in 2025, the saas index fell 6.5 percent. valuation multiples have dropped from above seven to below five [5].

satya nadella put it bluntly in the bg2 podcast in december 2024: in the agent era, business applications will collapse, all business logic migrates to the ai layer [6].

this isn't a dystopia for saas companies. it's a paradigm shift. saas won't disappear; but the balance of power is shifting. the lock-in breaks because the alternative that stabilized it, the argument "building it yourself is even more expensive," is falling away.

the new role: software designer

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.

what emerges is something different: the software designer. the systems analyst. the person who asks creatively and disruptively: how should this actually work? who thinks in systems, understands processes, asks the right questions, and then puts the answer in the hands of users as a working prototype within days. together they optimize rapidly.

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.

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.

and one thing needs to be understood: ai will never be worse than it is at this point. it will only get better. 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 i'm 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 this in an influential study [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.
all tools, processes, and workflows that have governed software development can be thrown out. 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.
companies that haven't built their own software should seize the opportunity: build a small software design team. 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.
for all developers and the people who will accompany developers through the coming years: 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