The quiet democratisation of software creation in the German mid-market

**Lead.** A clerk at a tax-aid association on the Lower Rhine built a web application using an AI coding assistant. Before it went live, a code review by the in-house IT partner surfaced two structural gaps no one at the desk could have spotted alone. The full success story sits elsewhere: [efiniti.de/en/about/success-stories/hilo-ev](https://efiniti.de/en/about/success-stories/hilo-ev/). This piece steps one floor up and asks what such episodes say about the changing division of labour between Germany's mid-sized companies and their IT partners.

## When the idea no longer starts in the IT department

Until recently, nearly every software initiative in a German SME began with the same sentence: "We should talk to our IT provider about this." Today it more often begins with an open editor and a model writing code in the background. This is not a rebellion against the IT partner. It is simply the shortest available path from an idea to a working prototype. People who feel a concrete friction in their daily work can now address it the same evening.

That shifts something that had been stable for decades: the order in which requirements come into being. Previously, an employee idea ran through a funnel of specifications, quotes and sprint plans before reaching a screen. Today it exists first, often as a runnable draft. Only then comes the question whether it is operable. The provider no longer receives a wish to be realised, but half-finished code to take over.

## What DIY AI does not solve on its own

This shift produces a new class of gaps. AI coding assistants are excellent at generating plausible-looking code. They are visibly poor at three other things that production in a regulated environment cannot do without.

First, model choice. Which model is fit for which use case depends on licensing, data residency, update cadence and output quality. No assistant makes that judgement for its user. It is made silently the moment the user accepts the default model.

Second, security architecture. Input validation, permission models, secret handling, secure defaults, audit trails. Generators emit what occurred most frequently in their training data. That is not necessarily what an OWASP checklist wants to see.

Third, the lifetime perspective. An application does not live on the day of go-live, but in the three years that follow. Patches, library updates, compatibility, recovery, monitoring, data migration. All of that is software too, not just its first successful run. An AI assistant does not know this dimension, because it lies outside its output window.

These three gaps are not a weakness of the tools, but a property of their task. Tools build workpieces. They do not operate them.

## The quiet redefinition of the MSP role

This also changes the job description of the managed service provider. Classically, an MSP was the extended arm of the customer IT department or, in the SME, its substitute. It took requests, costed them, delivered, maintained. Initiative almost always sat with the customer, but it arrived through conversation, not as a finished code tree.

When the customer now begins themselves, the order changes. What is asked of the MSP is no longer "build me X" but "review X, harden X, operate X, guarantee X for me". That is a fundamentally different order structure. It demands capabilities the provider did not need three years ago, at least not at the same depth: reading comprehension across frameworks and languages, AI model evaluation, threat modelling for AI-generated code, migration between hosting layers, compliance mapping in both directions.

An MSP that cannot deliver this will leave its customers stranded the moment those customers ship something themselves. And customers will ship things themselves. That cannot be stopped any more.

## Sovereignty as it actually happens

A second point deserves more attention than the current debate gives it. Digital sovereignty is, in public discourse, a political word. In a consulting office, an insurance broker office or a tradesman bookkeeping, it is a daily decision. It is settled not in Brussels and not in Berlin, but at the point where a receipt, a personnel file, a customer record passes through an AI model for the first time.

If that model lives in a foreign cloud, the sovereignty question has been answered in that moment. Not in principle, but in fact. Anyone claiming that a retrospectively signed data processing agreement restores sovereignty has misunderstood the term. Data processed once in another jurisdiction has been processed there. Full stop.

The obvious consequence: anyone in an SME working with personal or mandate-related data must have the option to run AI inference inside their own jurisdiction. And this option is not something an SME can build for itself. It demands its own GPU hardware, its own data centre, its own operations team. That is not SME scale. It is precisely the scale at which a specialised mid-market MSP is needed today.

## What this means for other industries

Tax advisory is just the first visible field, because the regulatory sensitivity there is high and the data volumes are manageable. The same pattern will surface over the next twelve to twenty-four months in insurance broker offices, in care services, in trades, in law firms, in architectural practices. Anywhere people with domain knowledge sit, who feel a recurring pain point in their daily work and have enough technical curiosity to build a prototype in an evening.

The question for these industries is not whether their employees will start, but how their IT partners respond. An MSP that today still explains that software development is its business and the customer should leave that to the professionals will find itself, in two years time, baffled by customers suddenly speaking of "the internal tool" that has quietly been running in production for months. Probably not productive in the sense of data protection, but productive in the sense of daily work.

## What an IT partner has to be able to do today

If I had to compress this shift into a single sentence: an IT partner for the mid-market is moving from contract developer to completer of other people initiative. That is more demanding, not less. It requires a different mix of humility and rigour. Humility, because the domain idea no longer originates in your own house. Rigour, because responsibility for secure, lawful, durably operable running ends up with the partner anyway.

Concretely: an MSP wanting to occupy this role needs a platform onto which it can take over foreign code without rewriting it. It needs inference infrastructure under its own control. It needs established review processes that are perceived not as a brake but as a contribution. And it needs a self-image that treats customer initiative not as competition, but as the entry door to its own actual value creation.

That is exactly what we are trying to build at EFINITI with Pandora. Without any claim that it is the only answer. But with the observation that the question itself has by now become unavoidable.

## What remains

The democratisation of software creation is not a coming trend. It is happening already, in offices that would never describe themselves as software houses. That is good news for the mid-market, because initiative no longer hinges on the budget of a specification document. It is a demanding piece of news for the IT service industry, because it has to set down a self-image that worked for decades.

Anyone who wants to be an IT partner for the mid-market today has to do two things at the same time: step back when the customer starts, and step in with full competence when the customer gets stuck. Either one without the other is half a job. Both together describe a role that has not existed in this form before.