Custom Development or Off-the-Shelf? Five Questions That Decide

We sell custom development, and yet we often talk clients out of it. Five questions a company or public authority should ask before deciding, and an honest answer on when off-the-shelf software is the better choice.

Jozef Krivaček · 14/08/2026 · 7 min read

Custom development is one of our services. So I ought to write that bespoke software is always better. It is not. For most things a company needs, there is a ready-made tool that costs a fraction of the price and works from tomorrow. We ourselves run invoicing, stock and sales opportunities in an off-the-shelf system and it never occurred to us to build our own.

At the same time, over the past few years we have seen plenty of companies and public authorities buy a package, bend it for two years, and end up running it at a higher cost than software built to measure would have been. The difference between the two cases is not the budget or the size of the organisation. It comes down to five questions that someone did, or did not, ask at the start.

1. Is this process how you make money, or is it overhead?

Accounting, payroll, attendance, e-mail, document sharing. Every company in the world runs these processes the same way, and nobody gains an edge over the competition through them. For these things there are ready-made tools developed by hundreds of people and used by millions of companies. Building your own invoicing is like building your own power plant.

Conversely, a process in which you are better than your competitors is exactly what a package takes away from you. A ready-made tool is designed for the average customer, so it forces you to do things averagely. When a company that inspects technical equipment runs its scheduling, reports and approvals in one system tailored to its own procedures, that is its advantage. If it did the same in a generic task-management tool, it would be like everyone else.

So the first question is: if this process were identical to your competitors', would it matter? If not, buy the package.

2. Do you fit into the package at least eighty percent?

Every off-the-shelf product can be "customised". In practice that means configuration, add-ons and modifications from the vendor's partner. Up to a point, that is fine. The trouble starts when customisation turns into reconstruction.

Our experience is that the line lies somewhere around twenty percent. If a ready-made tool covers eighty percent of what you need and the rest can be handled by configuration or a small add-on, it is a good choice. If it needs more modification than that, you are paying to alter a package that was never designed to be altered. Every update from the vendor can break what you had built on top, and the company that made the modifications is the only one who understands them. That is the worst of both worlds: the price of custom software and dependence on two suppliers instead of one.

The practical test is simple. Write down the ten most frequent things your people do in the process and have them demonstrated in the package. Not in the vendor's presentation, but on your data and your scenario. If the presenter starts making excuses on three of them, you know where you stand.

3. How often does the process change?

A stable process with a small number of people, one that looks the same as it did five years ago, is the ideal candidate for a package. Buy it, set it up, forget it.

A process that changes with every amendment to the law, every new type of customer or every change in operations is a different story. There, the deciding factor is not the cost of implementation but the cost of every change. With a ready-made tool you wait for the vendor to implement the change, and the vendor implements it when enough of its customers need it. With your own software, a change is a matter of a brief and a few days of work.

This is why we build custom software for pharmacies, cities and operators of technical equipment, even though at first glance it might seem that a register is a register. It is not. A register that the law rewords every quarter is a living organism.

4. Who will run it in five years?

A package has one enormous advantage that people only appreciate when they do not have it. As long as the vendor exists and has thousands of customers, the software will keep being updated and someone will know how to operate it even after your IT person leaves.

Custom software does not have that certainty automatically. It has it only if you demand it. Source code, documentation, an operations manual and open interfaces, so that another supplier can take it over. We describe what that should look like in a piece on an information system built to run without us. If your custom-development supplier cannot promise you that, you do not have custom software. You have a package with one customer, and that customer is you.

So the fourth question is not "package or custom" but "who will know how this works in 2031". The answer has to exist in both cases.

5. What data goes into it and where is it allowed to be?

Ready-made tools today are almost always cloud-based and almost always operated outside Slovakia, often outside the European Union. For marketing contacts that does not matter. For health records, citizens' data, vehicle registration numbers or security footage it can matter, and sometimes the law simply forbids it.

That is why the public sector and regulated industries often arrive at custom software on this question, not because a package could not do what they need, but because they are not allowed to use it. The same applies to artificial intelligence over sensitive data, where running the models in the EU is a condition, not a luxury.

The third path nobody talks about much

Most decisions are in fact not either-or. The best-working solutions we know are a combination: a ready-made system for the overhead and a custom layer for what the company makes its money on.

For us that means invoicing and stock run in an off-the-shelf system, but on top of it we have our own automation that processes documents and saves hours of work every day. We wrote about it in The Receipt and Invoice Tamer. We did not build accounting. We built only the part where we wanted to be better than average.

KALM:IT, our platform for cities and operations, works the same way. The core is ready-made and proven across hundreds of installations, but the applications on top of it, whether pedestrian-zone access or processing offences from speed cameras, are built to measure for a specific city. The client gets neither a package nor a project from scratch, but something in between that is cheaper than both.

How to decide in an hour

Take the process you want to solve and go through these five questions. If you answered "overhead" to the first, "we fit" to the second and "it does not change" to the third, buy the package and stop worrying. If you answered "this is how we make money" to the first and "it changes every year" to the third, consider custom development, but with the conditions from question four. If the answer to the fifth question is "this data must not leave Slovakia", your decision is made regardless of the rest.

And if you are not sure, get in touch. We will look at the process and tell you straight whether it makes sense to build something of your own. Sometimes our best advice is to buy the package.