When is standard software the better choice?

Almost always, where a product exists that covers most of the process. The rest usually costs less as configuration of that product than as an application of your own plus the running of it. We say so even when it argues against the engagement.

Build or buy: how do you decide?

In order. First, does a system you already own do it, perhaps in a module nobody switched on? Second, is there a product that covers most of it, with the rest as configuration? Third, can it be an automation between the systems you have? Only if all three fail do we build. The process has to be part of what makes your business different, frequent, and around for years.

You do. Source, repository and documentation transfer to you, with dependencies that are freely available. An application only we can run is a dependency we do not want to sell.

What if we change supplier?

Then somebody else takes over. That is exactly what the documentation, a small technology choice and tests on the parts that carry weight are for. We build for the case where we are no longer involved.

With the smallest piece that is usable in daily work, and with the people who will use it. An application first shown after six months has been a guess for six months.

Who runs it afterwards?

Either your own IT, your IT service provider, or us, for as long as you want. Which of the three is agreed before the build, because it changes what we build: an application your own people will run is built with the tools they already know.

All services

Custom software for mid-sized companies, where off-the-shelf stops

Off-the-shelf software covers most of it, but rarely all of it. Where something is missing, we build it ourselves.

Last reviewed: September 2026

Where the product stops

For most processes there is a product. For some there is none: because your business has a quirk, because two systems do not know each other, or because the process touches four tools none of which was meant for it.

The gap then gets filled with a spreadsheet, a shared mailbox and a rule one person keeps in their head. You notice it when that person takes leave. You notice it when the spreadsheet has a second copy with different numbers, and when a new colleague takes months to learn what is nowhere written down. The cost is that one person is the process, and the process stops with them.

Build or buy: the order we check in

Custom software is the last answer, not the first, and we check the others in order.

Does a system you already own do it? ERP and CRM products carry modules nobody switched on. This is the most common answer, and it costs configuration rather than a project.
Is there a product that covers most of it? Then the rest usually costs less as configuration of that product than as an application of your own plus the running of it.
Can it be an automation between the systems you have? If the process is a route between existing systems and needs no screens of its own, it is process automation, not software.
Only then: build. The test is whether the process is part of what makes your business different, whether it runs often, whether it will still exist in a few years, and whether somebody will own the application after us.

We say which answer it is even when it argues against the engagement.

How we build

Cut the process until the smallest piece that is usable in daily work is left. That piece goes first.
Build it with the people who will use it. The verdict comes from them, not from an acceptance meeting.
Anchor it in your systems rather than beside them, so it reads the order from the ERP instead of asking for it; see integration into your systems.
Test what carries weight. The calculation, the interface, the rule that decides. Not every button.
Document and hand over from day one. Plain technology choices, a repository in your name, and documentation somebody else could take over from.
Operate it for as long as you want it from us, and hand it to your IT or your service provider when you do not.

Where AI helps, it is a part of the application rather than its purpose. Most of these applications are mostly forms, rules and interfaces, and in one or two places a model that takes over a judgement: it classifies, it extracts, it drafts. The rest is boring on purpose, because boring is what somebody can maintain at three in the morning.

A worked example: the complaint

A manufacturer in North Rhine-Westphalia handles complaints across four places: the mailbox where the customer writes, the ERP that holds the order and the item, the quality system that holds the findings, and a spreadsheet that tracks the status. The ERP has a complaint module, but it does not know the quality system, and the spreadsheet is the only place where the whole case is visible.

The application is one screen. The complaint comes in, the order is pulled from the ERP, the photos and the finding are attached, and the decision is recorded with a reason: replace, credit, or reject. A model suggests the category from the text and drafts the letter to the customer. The head of quality decides and signs off the letter before it goes out. The status lives in the application, and the spreadsheet retires.

What you need to bring, and when it is not worth it

You need a process worth owning. You need people with time to look at the early versions, because the verdict is theirs. You need somebody on your side who will own the application after handover, or an agreement with us or your IT service provider to run it. And you need to accept “buy” as an answer, because it is the most common one.

It is not worth it when a product covers most of the process. It is not worth it when the process changes every quarter, because the application will always lag behind. It is not worth it for a process that exists for one person. And it is not worth it when the volume is small enough that the spreadsheet is fine.

How it differs from the neighbouring services

Custom software fills a gap where no product exists. Integration connects the products you already have. Process automation runs a route between them without screens of its own. An AI agent is a worker with a job; an application is a place where work is done, and it often hosts one. Whether your case is the gap or one of those three is the first question we ask.

The next step

In the free introductory call, describe the spreadsheet and the person who keeps it running. Whether the answer is build, buy, configure or automate is what the assessment settles, and the most common answer is that a system you already own can do it.

Common questions

When is standard software the better choice?: Almost always, where a product exists that covers most of the process. The rest usually costs less as configuration of that product than as an application of your own plus the running of it. We say so even when it argues against the engagement.
Build or buy: how do you decide?: In order. First, does a system you already own do it, perhaps in a module nobody switched on? Second, is there a product that covers most of it, with the rest as configuration? Third, can it be an automation between the systems you have? Only if all three fail do we build. The process has to be part of what makes your business different, frequent, and around for years.
Who owns the code?: You do. Source, repository and documentation transfer to you, with dependencies that are freely available. An application only we can run is a dependency we do not want to sell.
What if we change supplier?: Then somebody else takes over. That is exactly what the documentation, a small technology choice and tests on the parts that carry weight are for. We build for the case where we are no longer involved.
How do you start?: With the smallest piece that is usable in daily work, and with the people who will use it. An application first shown after six months has been a guess for six months.
Who runs it afterwards?: Either your own IT, your IT service provider, or us, for as long as you want. Which of the three is agreed before the build, because it changes what we build: an application your own people will run is built with the tools they already know.

Check your potential, free