Most build-versus-buy decisions are made on the wrong axis. People argue about the price, licence per month versus one-off project budget, and in the end the figure that looks smaller in the first year wins. This is the most expensive mistake in the entire digitalisation of SMEs. Because the question "SaaS or customised software?" is not a question of cost. It is a question of which processes differentiate you from your competitors and which simply need to run.
Everyone who has ever been wrong knows the worst-case scenario: You pay for a six-figure in-house development that ends up replicating exactly what would have been available as a standard subscription for 49 euros a month. Or two years later you're stuck with a purchased system that does roughly 80 per cent of the work well and the crucial 20 per cent not at all. If you know the right axis, you can make the decision in twenty minutes. Those who don't know it pay for the mistake for years.
Here's the axis you should really be deciding on, a matrix to go through, and the third way that almost everyone overlooks and is usually the right one.
Why comparing prices is misleading
Standard software as SaaS almost always costs less in the first year. You book, you log in, you pay per user and month. Customised development requires an upfront project budget before anything is even up and running. At first glance, the case is clear. This is exactly where most invoices fall down.
What is missing from the first invoice is everything that happens after the month of purchase. With SaaS, the price scales with every user, every additional function and every API connection that you need to integrate the system into your landscape. Do the maths: 49 euros per user per month quickly becomes a multiple of the list price with 30 employees, two mandatory integrations and the enterprise tier, which activates the interfaces first. The figure on the landing page is the entry price, not the operating price.
With customised software, the calculation flips in the other direction. The biggest cost block is not the development, but the maintenance over the years. Studies on the software life cycle regularly put the proportion of operation, maintenance and further development at 60 to 80 per cent of the total costs of a system. The initial creation is just the tip. If you budget for in-house development and forget about ongoing maintenance, you are building up a legacy that will later become a project in its own right.
In short: SaaS has low entry costs and a cost curve that rises as you grow. Customised software has high entry costs and a flatter curve that never falls to zero. Where the two curves intersect is the real decision point. It has nothing to do with the price in the first month.
The one axis that really counts: Differentiation
Forget price for a moment. For every process, every application, every module, ask yourself just one question: Does this process differentiate me from my competition, or does it just need to work reliably?
Your accounting doesn't differentiate you from anyone. Neither does your payroll system. Nobody buys from you because your payroll runs more elegantly. Such processes are pure hygiene: they have to be correct, legally compliant and low-maintenance, nothing more. Building an in-house development for them is a waste of money. Standard software always wins here.
Then there are the processes that actually make up your business. The special way you configure orders. The logic with which you dovetail production, warehouse and dispatch. The customer portal that sets your service apart from the rest of the industry. You can't buy these processes off the shelf. Because if you could buy them as a standard product, your competitors could too, and the advantage would be gone. Customised software justifies itself here because it represents something that does not and should not exist as a product.
This is the axis. Not "expensive or cheap", but "differentiating or hygiene". Everything else is downstream.
The decision matrix: SaaS, hybrid or individual software?
Cross the differentiation axis with the degree of standardisation of a process, i.e. how well the market already maps this process in finished products. Four fields are created. Go through your central applications once and sort each one into one of them.
| Process | Differentiation | Market standard | Recommendation |
|---|---|---|---|
| Accounting, Payroll, DATEV connection | low | high | SaaS / Standard buy, don't touch |
| CRM, email, collaboration | low | high | SaaS / Standard, easy to configure |
| Branch ERP with special processes | medium | medium | Standard core + customised modules |
| Configurator, pricing logic, Portal | high | low | Customised software build |
| Data consistency between systems | high | low | Individual integration / middleware |
The two edges are simple. Top left, low differentiation and lots of standard, you buy and stop thinking. Bottom right, high differentiation and no usable standard, you build because there's nothing to buy. You earn or burn the money in the middle.
Take the middle line, the industry ERP. A mechanical engineering company needs 90 per cent of what a standard ERP can do: Master data, orders, warehouse, posting logic. But its quotation calculation for special machines, with hundreds of variants and customer-specific surcharges, does not map any standard ERP cleanly. The wrong reaction is to replace the entire ERP just to get this one function. The expensive reaction is to customise the standard ERP until every update becomes a risk. The right response is to keep the standard ERP, build the calculation as a separate module next to it and connect the two via an interface. This cut is exactly what this article is about.
The third way that almost everyone overlooks
The question is almost always posed as an either-or: all standard or all homegrown. In practice, the best answer for SMEs is usually neither, but a combination. You take tried-and-tested standard systems for everything that is hygiene and only develop customised systems where you differ. The whole thing is connected via APIs.
This is what it looks like in practice: A company keeps its standard ERP and the DATEV connection for accounting and master data because there is nothing to differentiate. The product configurator, which is the real sales advantage, is built by the company itself. A lean integration layer keeps both worlds synchronised so that an order from the configurator ends up in the ERP without any manual retyping. Standard where standard is enough. Customisation where it counts.
This approach has been given a name in recent years: Composable Architecture. Instead of monolithic all-purpose software that can do a bit of everything, you put together a composite of specialised components. The link is a clean system architecture with clearly defined interfaces. Without this, the network quickly turns into an integration nightmare in which each system talks to each other via its own bridge and nobody knows which data is leading where.
The advantage is tangible. You don't pay for in-house development for accounting that nobody cares about. You are not stuck in a standard ERP that cannot map your core process. And if a standard module no longer fits at some point, you can replace it without having to rebuild the entire system. The price for this is discipline with the interfaces. Integration is the part where such projects fail if they are underestimated.
Four questions before you decide
Before you decide in favour of SaaS, individual software or the hybrid, answer these four questions honestly. They will catch the mistakes that become expensive later on.
How close is the standard to your real process? If an available product covers well over four-fifths of your process, buy it and adapt your process to the missing areas. This is cheaper than any in-house development. If, on the other hand, the gap is wide, customising the standard quickly becomes more expensive and more fragile than a targeted in-house development. The mistake you want to avoid: bending a standard product until it is more expensive than a clean in-house development and still doesn't fit.
Who owns your data and your process? With pure SaaS, your data is with the provider and you follow their roadmap. This is perfectly fine for a hygiene process. For your core process, you should think very carefully about whether you want to link its future to the product decisions of a third party.
How quickly do you need to be able to change? Standard software changes at the pace of the provider. If your market forces you to rebuild a process in six weeks, but the provider runs two releases per year, you have a problem that no price comparison can catch.
What does it cost over five years, not one? Calculate SaaS with realistic user and function growth and customised software with ongoing maintenance. Only this curve over the years tells you what is really cheaper, not the price in the first month.
What we recommend
Our position is clear and it is not sales logic: buy everything that doesn't make you different and only develop what makes you different. In the vast majority of SME projects, this means a hybrid in practice. Standard systems as a stable foundation, targeted customised development for the two or three processes that actually support your business, cleanly connected via APIs.
If you start with a pure "build everything yourself" strategy, you pay for replicating commodity functions and tie yourself to a maintenance burden that contributes nothing to differentiation. Conversely, anyone who squeezes their entire business into a single standard product will eventually lose the very process that makes them special.
The real work is in the cut in between, and this is neither trivial nor arbitrary. It starts with honestly categorising each central process on the differentiation axis instead of lumping everything together for the sake of convenience. It requires a clear decision as to which system is leading for which data before the first interface is built. And it stands and falls with the discipline of not bending a purchased standard again as soon as it pinches in one place. If you make this cut cleanly, you have a system that grows with you. If you slip up, in three years you'll have exactly the legacy system you wanted to avoid.
If you're faced with exactly this decision and want to make it on the differentiation axis instead of the price axis, it's worth talking about customised business software. Not to build you something that is available as standard, but to make the right cut between buying and building for your specific case. And if the legacy system is already there, a grown system that nobody wants to touch anymore, modernising it is the actual first step before even talking about new software.
In the end, the decision between SaaS and customised software is not a question of budget. It's a question of which parts of your company are replaceable and which are not. Answer that first. The price then sorts itself out.