The ‘build vs. buy’ decision is made in the boardroom and paid for in the code. In the presentation, licence costs are weighed against the project budget; in reality, webhook retries are weighed against technical debt. Anyone who calculates the decision purely from a business perspective overlooks the items that will dominate the backlog three years down the line.
We have already addressed the strategic side of this question: Differentiation is key, not price. This article takes the other perspective. Assuming the strategic aspect is clear: as a technician, how do you determine whether ‘build’ or ‘buy’ is the right answer?
There are three cost items that rarely feature in a business case but nevertheless tip the balance: the integration surface, the exit path and the glue code. After that, only one question remains, and it concerns people, not technology.
The feature list lies: The integration overhead is the real cost
No SaaS product stands alone. It has to communicate with your shop, with your ERP, with your identity provider, with your data warehouse. Each of these interfaces is code that you write, test and maintain, regardless of whether the product has been purchased or not.
That’s why the first engineering question isn’t ‘What can the tool do?’, but: ‘How many integration points does it have with my core systems, and how good are they? A clean, versioned REST API with webhooks, idempotence support and usable sandboxes makes a purchased product cheap. A CSV interface with nightly batch exports makes it expensive, even if the licence only costs 49 euros a month.
It’s not the product that costs money, but the integration. Two integration points with a good API are better than five with a poor one, and once you reach a certain number of poor integrations, in-house development is not a luxury, but the cheaper architecture.
Lock-in is not a feeling, but a date
Vendor lock-in sounds abstract until the provider disables a feature on which your customisations run. Shopify has permanently discontinued its scripts as of 30 June 2026; anyone who had built checkout logic on top of them had to migrate to Shopify Functions, whether it fitted their own roadmap or not. That is the crux of the problem: with purchased software, you inherit the provider’s roadmap, its deprecations and its pricing policy.
The latter has been in flux for years. Salesforce increased its list prices by 9 per cent in 2023 and again by 6 per cent in August 2025; across the market, AI features are being moved into more expensive bundles that come into effect at renewal. And even the models behind them are constantly evolving: following its experiment with pure consumption-based pricing, Salesforce has back to seat-based licences with credit quotas. A price you compare today will be different in three years’ time, and possibly in a different unit.
The engineering solution to this is an exit path. Before buying, check three things: Can you extract your data in full and in an open format? Do you own the schema, or just an export? And realistically, how many person-days would a switch cost? If the answer to the third question is “unknown, probably a lot”, then the licence price isn’t the real cost.
Glue code is also software
The second biggest fallacy in make-or-buy calculations: ‘Buy’ supposedly means zero engineering. In reality, it merely shifts the engineering work elsewhere. Instead of business logic, you end up writing synchronisation code: mappings between data models, retry logic for webhooks, rate-limit handling, and monitoring for a service whose inner workings you cannot see.
The classic scenario looks like this: the provider changes the structure of its webhook payload, announced in a changelog that nobody has subscribed to. Order transmission carries on, but with empty fields. Many a team has only noticed this sort of thing when the accounts department asked why the tax rates were missing from the ERP. The fix takes two hours; the clean-up takes two weeks.
It is precisely this glue code that has some unpleasant characteristics. It is rarely tested because it is ‘just integration’. It belongs to no one because it exists between two systems. And it breaks at times determined by the provider, not by you.
On the build side, there’s one item that newcomers chronically underestimate: maintenance. Studies on software economics regularly put the share of maintenance costs in the life cycle at 60 to 80 per cent.
Work it out for yourself: A project with a development budget of 200,000 euros will therefore incur total costs of roughly 500,000 to 1,000,000 euros over its lifecycle. The difference – that is, 300,000 to 800,000 euros – is maintenance: patches, dependency updates, minor enhancements, and operation. Anyone who only approves the development budget has approved the smallest figure in the project.
In simple terms: with ‘Buy’, you pay for third-party software and patch things up. With ‘Build’, you pay for your own software and look after everything. An honest TCO calculation compares both maintenance costs side by side, rather than pitting the licence fee against the project budget. An in-house development without a designated owner is therefore not an investment, but a future legacy project in the making.
When to build? Three conditions that must all be met
After considering the three cost items, the key question of people remains, and this allows the decision to build to be precisely defined. Build it yourself if all three conditions apply simultaneously.
Firstly: the process sets you apart. This is the strategic axis from the SaaS vs. Custom Software Decision Matrix, and it remains the key to entry. Nobody seriously builds their own solutions for bookkeeping, ticketing or newsletter distribution.
Secondly: The domain is stable enough for the investment to pay for itself. A process that changes fundamentally every six months because the market dictates it is a poor candidate for a five-year in-house development project. A core process that has, in principle, been running the same way for ten years but has simply never been properly implemented is an excellent candidate.
Thirdly: there is a team that owns the software. Not the one that built it, but the one that owns it. With a budget, responsibility and a name on the organisation chart. If this ownership is lacking, buying in almost always wins out, even where there is strong differentiation, because orphaned custom software is the most expensive software of all.
If any one of the three conditions is missing, buy. This is not a surrender, but portfolio hygiene: engineering capacity is the scarcest resource in-house, and it should be devoted to code that only you can write. If all three are met, bespoke software solutions are not a luxury, but the more cost-effective architecture.
Build vs. Buy: The decision matrix for engineers
| Criterion | Arguments in favour of Buy (SaaS) | Arguments in favour of Build |
|---|---|---|
| Integration interface | Few integration points, clean API, webhooks, sandbox | Many poor integration points with core systems, legacy batch/CSV issues |
| Data sovereignty & Exit | Full export, open format, predictable migration | Data only in the provider’s schema, exit costs unknown |
| Roadmap dependency | Provider’s roadmap meets requirements; deprecations are manageable | Critical logic depends on features that the provider can discontinue at any time |
| Pricing trends | Predictable costs, low renewal risks | Usage/credit models or AI bundles make costs unpredictable |
| Ownership | No team with long-term ownership | Designated team with a budget and operational responsibility |
| Differentiation | Commodity process | Process is a competitive advantage |
The matrix is deliberately inconvenient: It forces you to quantify exit costs and ownership before the first licence is signed or the first ticket is issued. If two or more rows clearly fall on one side, the decision has usually been made.
The third way is usually the right one
The purely binary question is a simplification anyway. The most robust architectures combine: off-the-shelf commodity services at the edges, a slim, in-house developed core layer where differentiation lies, and, in between, deliberately designed, documented interfaces rather than ad-hoc ‘glue code’.
This third way has a variant that is missing from traditional make-or-buy analyses: running software yourself rather than renting it. Open-source and fair-code tools such as Metabase, Plausible or n8n provide SaaS functionality without a SaaS subscription, run on your own infrastructure with Coolify – even without platform costs. Data sovereignty and an exit strategy are, by definition, taken care of; the cost is borne through operational responsibility. For commodity tools handling sensitive data, this is often the best compromise between the two worlds.
Which approach is right for which system is an architectural question, not a procurement one. This is precisely where we come in with system architecture and design: drawing the line between buying, building and operating in such a way that it will still hold up in five years’ time.
Conclusion: Make decisions in code review mode, not in sales meetings
Back to the beginning: Build vs. Buy is decided in the boardroom and paid for in code. You can change this by treating the decision as if it were a code review. Read the API documentation before you read the pricing PDF. Quantify the exit before you celebrate the launch. And appoint the owner before the first line of code is written or the first contract is signed.
Those who stick to this order will make the decision that still looks right three years down the line. Everyone else optimises the figure that seems smallest in the first year, and that is precisely the one that ends up being the most expensive.