Individualsoftware oder Standardpaket? Wie man entscheidet

The choice between custom software and an off-the-shelf package is a question of fit, not quality. A package has been shaped by the shared needs of thousands of businesses; that does not make it bad, it makes it blind to the part that is specific to you. Custom software is the opposite: it knows only your business, but it has not seen the edge cases of thousands of others. Both approaches have blind spots, and the right decision depends on which blind spot is cheaper for you.

We can write this without taking sides because we build both. On one hand we have ready products developed for specific sectors — cafés, clinics, real-estate agencies. On the other, systems written from scratch for a particular organisation. Because the same team runs both lines, telling a client 'our ready product does not fit your business' is not a commercial loss for us, only a redirection to the right room.

Every business sees itself as unique, and usually it is right — but that uniqueness does not always translate into software. A café's coffee blend is unique, its order flow is not; a clinic's relationship with patients is unique, its appointment calendar is not. The most useful exercise before deciding is to write out the steps of the work and put the question 'how is this different for us' beside each one. Every line where the answer stays blank belongs to the package.

When the difference is real, it usually concentrates in one place: pricing logic, an approval chain, production planning or a rule imposed by regulation. In that case a third path opens — a ready base for the core, custom development where the difference lives. That pattern repeats often in our product family: sector-specific modules on top of the same core.

One warning: a software team alone cannot tell whether a difference is real. Behind 'this is how we do it' there is sometimes a solid business reason and sometimes only habit. Baking habit into software is the most expensive kind of customisation — because it gets maintained for years and nobody remembers why it is there.

A package is cheap on day one and custom software is expensive on day one, which is why a first-year comparison always gives the same answer. The meaningful comparison is total cost of ownership over three years, and it has four lines: licence or subscription, setup and migration, ongoing maintenance, and the most forgotten one — the cost of people doing by hand what the system does not cover.

That fourth line is usually the largest and appears in no proposal. A flow the ready system does not cover migrates into a spreadsheet, into email, or into someone's memory. Its monthly price is invisible but real: five hours a week from two people reaches a serious figure over three years, and that figure often covers the gap to custom development.

The reverse is true too: custom software's hidden line is maintenance. A system built for you does not live without a team working on it — security updates, framework upgrades, changing regulation. A custom decision that ignores that burden reaches the point of 'nobody can touch it' by year three. Put the invisible line of both sides into the calculation.

A time constraint drives the decision more strongly than most cost calculations. If you need a working system within three weeks, custom is not an option; you start with a ready product and address the difference later. With six months the picture changes. So the first question should be the calendar rather than the budget: when must this system be running, and why that date?

Under schedule pressure the common mistake is trying to speed custom development up. Holding scope fixed while shortening time lowers quality; the right move is to shrink scope. Starting with a ready product and writing the custom part in a second phase is a less risky route for the same budget — and what you learn in the first phase improves the design of the second.

Whichever path you choose, the one shared question is: can I take my data out, in full and machine-readable, on any day I choose? A solution that cannot answer that clearly carries a risk however good it is. In ready products this is usually an export feature; in custom software the database itself is already yours.

The second kind of lock-in is subtler: knowledge lock. If only one person or one vendor understands the system, you are dependent even when you hold the code. The antidote is documentation — architectural decisions, environment configuration and deployment steps written down. When you buy custom software, ask for that document alongside the code; it is worth as much.

In practice the path that works most often is between the two: taking everything standard from a ready base and writing only the genuinely different part. Technically this requires drawing clear boundaries — the custom piece must live as a separate module rather than as patches scattered through the core. Otherwise every core update breaks the customisations and you end up with a fork detached from the product.

We apply this principle in our own products too: when a need arises to talk to an external system, each one is written as an independent adapter and the core is left untouched. Adding a new system means a new adapter and one registration line. Thanks to that discipline, an integration written for one client puts no other client's product at risk.

The hybrid path has a commercial benefit too: the cost of the custom piece is the cost of the difference, not of the whole system. The client benefits from the maturity of a ready core without losing the flow specific to their business. In return they accept a constraint — the core works the way it works, and wanting to change that means leaving the hybrid path and returning to full custom.

Once the decision for custom software is made, the second question follows immediately: who writes it? Building an in-house team keeps the knowledge inside the organisation and is the cheapest route long term — but it requires hiring, management and continuity. An in-house team built around a single developer resets when that person leaves; calling fewer than three people a 'team' is usually optimism.

A vendor starts quickly and moves risk outside, but the knowledge accumulates outside too. The way to balance that is putting three clauses in the contract: ownership of the source code, delivery of technical documentation, and a defined handover process. Without those three you end up with a working system and nobody able to touch it.

The third path that works best in practice is a hybrid: an external team writes the system while one technical person from the organisation stays inside the project. Even without writing code, that person knows the architecture, takes part in decisions and does not face a blank page on handover day. The cost of that role is small against the project total; what it buys is independence.

The first is translating the existing process into software as it stands. A process that has run for years in an organisation is usually shaped by the constraints of old tools; coding it one-to-one makes those constraints permanent. The question to ask before building is 'why does this step exist' — half the steps whose answer is 'we have always done it this way' are unnecessary in software.

The second is trying to fit every request into the first release. Custom software's greatest advantage is that you can have what you want, and that advantage is also the main cause of uncontrolled scope. Keeping the first release narrow and learning from real use is both cheaper and more accurate than writing a six-month list up front.

The third is not planning maintenance. A commissioned system does not end when it is delivered; security updates, framework upgrades and changing regulation continue. Without a budget and an owner for maintenance, the system becomes 'untouchable' within three years and the organisation has to start a new project.

After choosing a ready product most organisations want to make it look like themselves, and up to a point that is possible: settings, field definitions, workflow configuration, report design. The limit is where you start changing the product's core behaviour. Cross that line and you are no longer using a ready product; you are using a fork whose maintenance is yours.

The practical test for that line is the upgrade: when the product moves to a new version, do your customisations survive? If they do, you are working in the right layer. If you have to rework them at every release, that customisation sits in the wrong place and in time you will become unable to upgrade at all.

When you notice you have crossed the line there are two honest options: undo the customisation and follow the product's path, or move that piece outside the product as a separate module. The third option — continuing to change the core — works in the short term and blocks both the product's road and yours in the long one.

One: which step of the work is genuinely different — and does that difference rest on a business reason or on habit? Two: when must the system be running? Three: have you calculated the three-year total cost including the price of work done by hand?

Four: can you take your data out in full on any day? Five: who will maintain the system, and what happens if they leave? Six: can you keep the place where the difference lives as a separate module? If you can answer yes to the last one, the hybrid path is usually the most balanced option.

The choice between custom software and a package is not a matter of belief but the answer to a few concrete questions: where your difference lies, what your calendar is, what three years cost, who holds your data and who will maintain it. The answers usually point somewhere in the middle — a ready core with custom development only where the difference genuinely is.

Because we do both, the direction of our advice changes with the client; sometimes we say 'our ready product will not fit you', sometimes 'this does not need custom software'. Describe the work you have, and we can calculate together which path is cheaper for you.