In the beginning of the year, I became a board member of a small parent-initiative daycare in Germany, a Kita-Elterninitiative. It's about as unglamorous as it sounds: law of associations, funding applications, staffing regulations, and GDPR compliance for an organisation that runs on volunteers and goodwill. At some point the question of Kita management software came up, because the old system of hand-crafted Excel sheets and still too much actual paper that was passed to us from board to board across the generations clearly didn't cut it. So me and my fellow newly-elected board member evaluated the options, picked one, and moved on.

It was only later that I realised what had happened during that evaluation. I had accidentally run a clean little test case for the question the tech industry has been arguing about for two years: is SaaS dead?

The argument for SaaS being dead goes roughly like this: Agentic development and large language models are making it possible to build custom software fast and cheaply. Generic tools, the ones that exist to manage workflows any competent developer could model from scratch, are suddenly vulnerable. Why pay a monthly subscription for a project management tool when an AI agent can build you exactly the one you want in an afternoon? The AIpocalypse, in this framing, does not kill software. It kills the business model of selling standardised software to people who would be better served by something tailored.

There is something to this argument, though many a proponent of it seems to ignore Brooks' tar pit. But watching it play out from a daycare board felt really instructive.

The software I did not want to build

The tool we chose is called Kitaplus. For our small Elterninitiative Kita, it costs less than 100 euros per month and handles the administrative side of running a Kita: child records, parent communication, billing, attendance, and the various reporting obligations that come with receiving public funding in North Rhine-Westphalia.

I am a software consultant by profession. The thought of building Kitaplus myself crossed my mind for approximately thirty seconds. The thing that stopped me was not technical difficulty. What stopped me was the domain.

German childcare financing is genuinely intricate. Parental fees are calculated based on household income, with bracket tables that vary by municipality. Sibling discounts apply, with their own rules. OGS (extended day care) is funded in NRW, comes with its own reporting requirements and data exchange formats. GDPR in a childcare context is particularly sensitive: you're handling health information, custody arrangements, records about children. Audit trails for public funding applications need to meet specific standards. None of this is arbitrary bureaucratic bloat. It is the genuine shape of the domain. The essential complexity, in the DDD sense.

Here's the detail that I think makes the point clearly: Over the previous months I had spent a considerable amount of time getting to grips with NRW childcare regulations as part of my board duties: the Kinderbildungsgesetz, the Personalverordnung, the mechanics of Förderanträge. Even with some domain exposure under my belt, it was clear that the domain runs deeper than any reasonable solo effort could justify.

The vendor on both sides

Warren Buffett's moat taxonomy is well known: network effects, switching costs, economies of scale, intangible assets, and cost advantages. These are the structuralfeatures that protect a business from competition even when competitors havecapital and talent.

Kitaplus does not fit cleanly into any of these categories. Their actual protective barrier is something slightly different, and I think undernamed. The company that builds Kitaplus also built KiBiz.web, the official system used by youth welfare offices across NRW to manage childcare funding on the public side. They also operate it. They are, in other words, the vendor on both sides of the most critical data exchange in the German Kita ecosystem.

Other Kita software vendors integrate with KiBiz.web too. But there is a difference between integrating with a system and having built and operated it for years. The incumbent knows its data model from the inside, its undocumented edge cases, its update cadence, the institutional context behind its design decisions. It's unlikely that this kind of knowledge appears in any official API documentation. You cannot throw money at this. You cannot throw LLMs at it either. The moat is accumulated domain expertise combined with structural institutional embeddedness. The software is the vehicle. What it carries is the asset.

The same pattern without the software

A few weeks after choosing Kitaplus I came across KitaShield, a service offering external data protection officers specialised exclusively in Kitas. The person behind it is Felix Leicht, a lawyer with TÜV certification as a data protection and IT security officer, who has been advising Kita operators and childcare software vendors for years.

KitaShield is not a software product. It's pure expertise delivered as a service. And yet the pattern is identical: Data protection expertise for daycare institutions is a highly regulated niche with a lot of essential complexity that takes years to understand deeply. It's a context where mistakes carry legal consequences, and a market that's too small to attract generalist competitors and too complex to serve without deep specialisation.

Both Kitaplus and KitaShield are doing the same thing. They have taken years of domain immersion in a specific, regulated, unglamorous corner of German public life and made it available as a service.

This is Domain Expertise as a Service. DaaS, if you are into acronyms.

What actually survives the AIpocalypse

The "SaaS is dead" discourse has identified something real. Generic software, tools whose value lies primarily in their interface and workflow convenience rather than in any deep domain knowledge, is indeed under pressure. If your product is a project management tool with a nice Kanban view, the question of why a user could not get something exactly tailored to their individual needs from an agentic system is a fair one.

The mistake is treating this as a statement about SaaS as a delivery model. What's actually under pressure is software whose value is shallow. The delivery model is incidental.

Kitaplus is delivered as SaaS. So is most enterprise software. The question that determines survival is not the pricing model or the deployment architecture. It's whether the thing being delivered required years of domain immersion to produce, and whether replicating it would require the same. The diagnostic is something like this: could a well-resourced team with good AI tooling build a credible competitor in twelve months? For generic project management, probably yes. For a system that integrates deeply with KiBiz.web and handles NRW-specific childcare regulation and billing logic correctly, almost certainly not.

The SaaS that survives looks, from the outside, like software. But what is actually being sold is accumulated domain knowledge, packaged into something a non-expert can use without becoming an expert themselves. It was always DaaS, not SaaS.

A microcosm

The German Kita software ecosystem is small, regulated, and invisible to almost everyone who writes about the future of software. Nobody at a developer conference is doing a talk about childcare management platforms.

And yet it is a surprisingly clean illustration of what durable software value actually looks like. Essential domain complexity. Institutional embeddedness. Expertise that compounds over years. A market that rewards depth over breadth.

Night of the living SaaS: it walks, it persists, it will not die. Not because it is undead, but because it was never merely software to begin with.