Standard Subscription, Custom Platform, or Hybrid? A Decision Guide for the Mittelstand

This question comes up in every other conversation: do we take something off the shelf, or build our own? It’s usually debated as a matter of principle, even though it’s really a matter of detail. What matters isn’t the philosophy, but what you want to achieve, what data is involved, and who will run the result afterward.

What each of the two routes costs in the end is worked through on the page AI costs at a glance.

The four realistic options

Option 1: Public service with a standard plan

A generally available AI service, used through business accounts. Available immediately, low cost, no setup.

Suitable for: Drafting, translating, summarizing, research on general topics, brainstorming.

Limits: The service doesn’t know your company. It’s unsuitable for questions about your own documents. Data processing is outside your control; for personal or confidential content, you need to check exactly what the particular plan guarantees.

Option 2: Platform connected to your own data

A ready-to-use platform connected to your systems: documents, permissions, login via your directory. The model runs with a provider, ideally in Germany, on a contractual basis.

Suitable for: the large majority of Mittelstand use cases – knowledge access, proposal support, internal inquiries, document work.

Limits: You operate within the platform’s feature set. Very specific workflows require extra work or can’t be mapped at all.

Option 3: Platform plus custom extensions

Like Option 2, supplemented with connections to specialist systems and workflows tailored to your business – for example, a link to ERP, inventory management, or an industry-specific solution.

Suitable for: Companies where the value only emerges from the connection to the specialist system. Invoice processing with purchase-order matching is a typical case.

Limits: Higher one-time effort, and you need a partner who knows both: the platform and your system landscape.

Option 4: Custom development

Building your own solution based on models and libraries, run in your own data center or your own cloud environment.

Suitable for: Companies with their own development team, special requirements for data handling, or an AI component in their own product.

Limits: The effort isn’t in the first prototype – that’s ready in a few weeks and impresses everyone. It’s in operations: model changes, security updates, permission checks, logging, availability, ongoing development. Anyone who can’t staff this permanently is building themselves a liability.

The questions that actually decide it

Do the answers need to draw on your own knowledge?

If so, Option 1 is ruled out for this use case. This question alone sorts out most cases.

Which categories of data are involved?

General business information is less critical than personnel data, health data, or design documents. The more sensitive it is, the more important the processing location, the data processing agreement, and the question of whether content is stored or used for training become.

Who will be running this in three years?

The most honest question there is. Custom development carried by a single person is a risk – regardless of how good that person is. If you can’t answer this question clearly, Options 2 and 3 speak for themselves.

How specific is the workflow really?

Many companies consider their processes unique. Often the distinctive part isn’t the workflow but the data source. In that case, a connection is enough – no custom development needed.

How fast does it need to work?

If a result needs to be in place within a quarter, custom development is unrealistic. If you have a year and a development team, it becomes an option.

The mistake that costs the most

The most expensive mistake isn’t choosing the wrong option. It’s answering the question in general terms instead of case by case.

In practice, a mix is almost always right: a standard tool is enough for general drafting. Questions about your own knowledge need a connected platform. For the one workflow that really defines your business, a custom extension pays off. Full custom development is the wrong path for most Mittelstand companies – not because of the technology, but because of running it over years.

An approach that makes the decision easier

List your three most important use cases. Answer the five questions above for each one. You’ll find that different cases get different answers – and that’s exactly the point.

Then start with the case that promises the greatest benefit for the least effort. Usually that’s an Option 2 case. Once it’s running, the connection, permission model, training, and operating model are in place – and the custom case under Option 3 becomes significantly cheaper than it would have been at the start.

What to look for in providers

• Processing location and contract: Where does the model run, who is the contracting party, is there a data processing agreement, which subcontractors are involved?
• Permissions: How are they checked at the moment of the request, and how fast does a permission revocation take effect?
• Model independence: Can the underlying model be swapped without rebuilding the solution? Given the pace of development, that’s a concrete advantage.
• Traceability: Are sources cited for answers?
• Exit: Can you get at your configuration and content if you want to switch?
• Point of contact: Is there someone who knows your system landscape – or just a support form?

This last point is often underestimated and matters more day to day than any feature. That’s exactly why we work with our own platform that connects to your existing systems, instead of selling you a closed product – and we look first at whether Option 1 might already be enough for your case.

A scoring grid for comparison

When several options or providers are side by side, a simple scoring approach along the same criteria helps. Assign points per criterion and weight them for your situation.

• Subject-matter fit for your twenty to thirty real test cases.
• Permission model: Checked at the time of the request, speed of permission revocation.
• Processing location and contract including subcontractors.
• Connectability to your existing systems.
• Model independence and handling of model changes.
• Traceability: Source citations, logs.
• Exit: Export of configuration and content.
• Support: Does the point of contact know your system landscape?
• Total cost over three years, not just the license.

It’s notable that subject-matter fit is just one of nine criteria. That matches experience: the differences between workable solutions are rarely in text quality.

Why the prototype is deceptive

An observation that matters for the choice between Option 3 and 4: a first prototype of a custom build is ready in a few weeks today and impresses everyone involved. That’s exactly the trap. The effort isn’t in building it, but in running it – permission checks, logging, model changes, security updates, availability, ongoing development, covering for people on vacation.

So don’t ask whether you can build it, but whether you want to run and keep developing it for three years – with more than one person who understands it.

Frequently asked questions

Can we start with Option 1 and switch later?

Yes, and that’s often sensible. Just be careful not to build workflows on top of it that would be hard to change later – and decide from the start what data is allowed in.

What’s the argument against a pure in-house build on open source?

Nothing, if you have a development team and can staff operations permanently. With a single person doing it on the side, you create a dependency that weighs more heavily than any vendor lock-in.

How do we avoid vendor lock-in?

Through three points: a model-open architecture, the ability to export configuration and content, and avoiding deeply embedded special logic that only works with one provider.

Should we wait for a market standard?

Waiting costs you the learning curve. The fundamentals you’ll need anyway – clean permissions, well-maintained content, trained staff – keep their value regardless of which tool wins out.

Four typical starting points

Instead of comparing in the abstract, it helps to look at the situation a company is actually in. Four patterns cover most cases.

Starting point 1: We first want to understand what this brings. No clear use case, but pressure to engage with the topic. Option 1 is right here – a standard plan for a manageable group, combined with a clear rule on what data is allowed in. The goal isn’t productivity, but for participants to develop a feel for the possibilities and limits. After three months, you’ll know where the first real case lies.

Starting point 2: Our knowledge exists, but can’t be found. Proposals, project files, service reports – everything exists, nobody can find it. This is the most common case in the Mittelstand and the clearest one for Option 2. The value comes from the connection, not from special features.

Starting point 3: One workflow defines our business. Quoting in specialized machine building, document processing in a trading company, incident handling in service. Here Option 3 pays off, because the value only emerges from the connection to the specialist system. It’s important to still start with Option 2 and plan the extension as a second step.

Starting point 4: AI is meant to become part of our product. Then we’re no longer talking about internal tools, but about product development – with everything that involves: operations, liability, and depending on the product, classification under Annex I of the EU AI Act. That’s Option 4, and it needs a development team.

What a proof of concept is allowed to cost

A pilot project is often proposed to demonstrate feasibility. That can make sense – if three conditions are met.

First, a defined success criterion. Not “we’ll see what’s possible,” but “at least twenty-five of our thirty test cases get answered correctly and with a source citation.” Without this criterion, every pilot project ends in a debate about taste.

Second, real data. A pilot project with sample documents proves nothing. The interesting part is always how the system handles your data as it has actually grown over time.

Third, reusability. What emerges from the pilot project – the connection, permission model, test list – must be able to carry over into production. A throwaway prototype on a different foundation costs time and proves little.

As a rule of thumb: a pilot project should cost well under what the full implementation costs, and should be completed in four to six weeks. If it takes longer or costs more, it’s no longer a pilot project, but a rollout without a decision.