Most bespoke software projects are not decided by the code itself. They are decided in the weeks leading up to it, during which these three questions are either answered honestly or skilfully sidestepped. Those who sidestep them only realise it eighteen months later: in the form of a system that could have been bought off the shelf, a budget that was only calculated up to go-live, or a service provider without whom nothing works anymore.
Question 1: Custom or off-the-shelf software — when is which option worth it?
The first question is the toughest, because the honest answer is often: no custom software at all. For bookkeeping, payroll or email, there are tried-and-tested off-the-shelf products. If you build your own solutions in these areas, you’re paying for in-house development for a process that doesn’t set you apart from anyone else.
The deciding factor isn’t price, but differentiation. Ask yourself a question for each process: does it set you apart from the competition, or does it simply need to run reliably? You buy standard off-the-shelf solutions for routine processes. You only build bespoke solutions for what actually defines your business: the product configurator with your pricing logic, the customer portal, and the integration of production, warehousing and dispatch – aspects that no off-the-shelf product can accurately replicate. Whatever you can buy off the shelf, your competitors can buy too. By definition, that’s no advantage. It is precisely for these processes that custom software development is worthwhile.
The grey area in between is where money is made – or lost. The classic pattern looks like this: The ERP covers master data, stock and accounting logic perfectly, but the tiered pricing logic that the sales team actually uses to sell products exists in an Excel file alongside the system. Nobody dares to touch it, and every quotation is produced via copy-and-paste.
The wrong response to this is a new ERP. The right one: keep the standard ERP, build the pricing logic as a separate module alongside it, and connect the two via an interface. We’ve set out in detail how to make this assessment systematically, including a decision matrix, in our article on SaaS or custom software.
Question 2: What does custom software really cost?
The most common answer to this question is a figure that tells only half the story: the project budget up to go-live. This figure is real, but it is not the price of the software. It is the entry fee.
The bulk of the costs comes afterwards. Studies on software maintenance estimate that the share of operation, maintenance and further development over the entire life cycle accounts for 60 to 80 per cent of the total costs; the 60/60 rule, which is common in software engineering, points in the same direction.
As a rule of thumb for budget planning: expect running costs of roughly 15 to 20 per cent of the original development costs per year. A system that costs 200,000 euros to develop will, realistically, incur a similar amount over five years for maintenance, updates, security patches and the customisations that your business will require anyway.
This is not an argument against bespoke software, but rather against making false comparisons. The SaaS alternative follows its own trajectory: a low entry price that scales with every user, every add-on module and every integration. Bespoke software costs a lot upfront but then levels off. My rule of thumb: if the process stays close to the standard and the number of users grows moderately, SaaS remains ahead in the long term. However, as soon as you start adding up enterprise tiers, add-on modules and workarounds for your core process, the cost-benefit analysis typically tips in favour of in-house development between years two and three.
What really drives the budget in the end is rarely the service provider’s hourly rate. It’s the scope: a project that starts with a focused MVP and grows in phases is predictable in terms of cost. A project that tries to do everything at once costs whatever it costs.
The second most common cost driver is hidden in a single line of a quotation. ‘ERP integration: 3 person-days’ sounds harmless until it turns out that the ERP doesn’t have an API, but only a CSV export via a night-time job. Then three days turn into three weeks – and that’s after the contract has been signed. Every integration with legacy systems deserves its own, well-justified estimate in the quotation rather than a flat-rate line item.
And underlying all this is the quality of the architecture: a cleanly designed system can be extended in five years’ time, whilst a convoluted one becomes a liability.
In short: the right question regarding costs is not ‘How much will development cost?’, but ‘What will the system cost over its lifetime, and what will the alternative cost over the same period?’. Anyone who compares only the first figure is making decisions based on the wrong criteria.
Question 3: How does a project work — and how do you recognise the right partner?
A reputable bespoke software project does not begin with a quotation, but with a discovery phase. Requirements are refined, processes are reviewed, and technical constraints are clarified. Only then can a reliable estimate be made.
By the end of the discovery phase, three things should be on the table: a prioritised backlog that distinguishes between what belongs in the MVP and what can wait; an architectural sketch showing the critical integration points; and an estimate that is justified on a component-by-component basis rather than being a total figure plucked out of thin air. If any of these are missing, it wasn’t a Discovery phase at all, but a protracted sales pitch. A service provider who quotes you a fixed price for a complex system after just an initial meeting isn’t assessing your project anyway. They’re assessing their sales opportunity.
This should be followed by an iterative process: an MVP that maps the core process in production, then expansion phases in short cycles with genuine user feedback. The benefit isn’t just methodological rigour. You can see early on whether the team is delivering and make adjustments before the budget is used up. A robust system architecture belongs at the start of this process, not at the end, because it determines whether the subsequent development phases are built on a solid foundation or on quicksand.
As far as the partner is concerned, two requirements are non-negotiable, and both must be included in the contract. The code belongs to you, in its entirety, including repository access from the very first sprint. And there must be a clearly defined maintenance and further development model for the period after go-live, with response times and terms and conditions, not just a letter of intent.
The real litmus test is more difficult, because it cannot be written into a contract clause: Does the partner build in such a way that you could switch to another provider? A market-standard tech stack such as Node.js or TypeScript rather than an exotic, bespoke solution; clear documentation; and developers whom you’ll still be able to find on the market in five years’ time. A partner who builds with interchangeability in mind binds you through quality rather than dependency. That is precisely why you will probably never need to switch to another partner.
What counts in the end
The three questions build on one another, and their order is the crux of the matter. Only once it is clear that a process warrants bespoke software is it worth carrying out a cost analysis. Only once the total cost analysis is in place is it worth looking for a partner. Anyone who reverses the order and starts by selecting a service provider will get an answer before they’ve even asked the question.
My recommendation is therefore uncomfortable, but simple: spend more time on these three questions than on comparing quotes. A mediocre service provider with a clearly defined brief will deliver a better result than an excellent one with the wrong brief. And if you get stuck on any of the three questions, that is precisely the right time to discuss bespoke business software, not only once the specification has already been drawn up.
Custom software isn’t a product you buy. It’s a decision you make. Make it in the right order.