Build vs buy: choosing between custom software and off-the-shelf packages
For every director, CTO or management team weighing a standard package against a platform of their own. This page isn't a sales pitch for custom software; it's an honest assessment. When does an off-the-shelf solution deliver more value than a custom build, and when is it the other way round? We work through the real decision factors: total cost of ownership, vendor lock-in, fit with the package, time-to-value and the strategic question of whether the process is your competitive advantage or a commodity. Want to read more? See also website build costs.
Request an independent assessment Go to the decision treeBuild vs buy: a decision that has little to do with software
Most build-vs-buy discussions get stuck in feature comparisons. "Package A has 84 modules, our process needs 12 specific adjustments, so we have to build." That is the wrong level. The real question is strategic: is this process your competitive advantage or a commodity? A logistics company that earns its margin from unique planning algorithms should not outsource that logic to a vendor. A law firm that differentiates itself on case quality does not need to build its own time-recording system. Want to read more? See also AI agents for businesses.
Geoffrey Moore calls this core versus context. Core processes deserve investment in custom development because they directly contribute to differentiation. Context processes — accounting, payroll administration, generic CRM flows — are best handled by packaged software because the market already offers mature solutions for them. The mistake directors often make is building custom software for context (expensive, no return on investment) or forcing packaged software onto core processes (friction, modification costs rise, and vendor lock-in limits every step forward).
There is also a second dimension that is usually underexposed: pace. How often does the process change? A process that changes structurally every year — new regulation, new business models, new markets — rarely fits a package with quarterly release cycles. A process that has remained unchanged for ten years and will continue for another ten is ideal for COTS (Commercial Off-The-Shelf). Build-vs-buy is therefore not only about what you build, but also about how quickly it must keep pace and who bears the friction.
Six reasons to build versus six reasons to buy
Not a marketing checklist, but the six arguments that consistently prove decisive in practice — on both sides of the trade-off.
When build (custom) wins
1. The process is your differentiator. If the way you work is itself the reason clients choose you, the logic should stay in your own hands.
2. Package fit is structurally below 70%. Below that threshold, modification costs over a five-year horizon almost always exceed the build cost of custom software.
3. Vendor lock-in is a strategic risk. For processes that affect your cash flow, you do not want a supplier that can unilaterally raise prices or stop supporting the product.
4. Integration requirements are fundamental. Deep integrations with specific ERP modules, industry APIs or legacy systems are often supported only superficially by packaged software.
5. Scale advantage lies in data processing. If processing each transaction costs money and you handle millions of them, it makes sense to own that layer yourself.
6. Your processes change faster than release cycles. Package vendors plan features for the entire market; your business cannot wait.
When buy (package / COTS) wins
1. The process is a commodity. Accounting, time tracking, leave administration: these are solved problems where there is no need to reinvent the wheel.
2. Time-to-value is critical. A packaged implementation can be live within weeks, whereas custom development requires a design phase, build, testing and stabilisation that can take anywhere from several months to years.
3. Compliance is already covered. Packaged software in financial domains (accounting, payroll, tax returns) is often already certified, and you rarely want to carry that burden yourself.
4. The volume does not justify a custom build. For twenty users and a hundred transactions a day, a bespoke platform is overkill.
5. The package fit is high (>85%). Above that threshold, the TCO benefits of packaged software almost always outweigh the gains of custom development.
6. There is a healthy vendor market. Competition keeps prices and quality in check; switching costs are acceptable when alternatives are available.
Cost curves: package and custom build over a 3- to 5-year horizon
Total cost of ownership is the only meaningful measure. Anyone who looks only at the entry price usually chooses wrongly. The curves develop quite differently.
The package curve: low start, rising tail
Packaged software starts cheaply. A licence per user per month, an implementation of a few weeks, and you're up and running. But the curve climbs. The monthly per-user cost grows linearly with your organisation. Modification costs arrive as soon as package fit drops below 80%, and they accumulate with every release. Integrations with other systems require partner hours or expensive connector licences. Switching costs build up the more custom work you layer on top of the package.
By year 5, expect total TCO of 2x to 4x the entry cost if package fit deteriorates.
The custom build curve: high start, flatter tail
Custom software requires a substantial upfront investment: analysis, design, build, testing and deployment. Thereafter you run on hosting costs plus a further development budget that you control. The curve flattens once the platform is stable. No per-user licences. No vendor raising prices unilaterally. The maintenance burden is predictable if the architecture is set up correctly. Opportunity cost, meaning what you gain because the system fits your process precisely, works in your favour.
In year 4 or 5, the break-even point lies for many organisations with more than 50 daily users, or where package fit is insufficient.
The mistake made most often: comparing only year 1. A package that starts at €50,000 and reaches €180,000 a year by year 3 loses out to a custom build of €250,000 that runs at €40,000 a year in maintenance from year 4. Do the TCO calculation over at least 5 years, and factor in opportunity cost: how much more do you earn (or save) because the system matches your process exactly?
Build-on-buy: the hybrid model that often wins
In practice, build-versus-buy is rarely binary. The most successful architectures we come across are hybrid: a strong package for the commodity layer, plus custom development for the processes that truly differentiate you. This is known as build-on-buy, and for many mid-sized organisations it is the best route.
A concrete example: a trading company uses Exact Online for financial administration (commodity, proven, certified) and builds a custom trading platform on top of it with dynamic pricing, stock allocation and a customer portal (core, differentiating, integrated via API). Another example: a training provider uses a standard payroll package but commissions a bespoke LMS, because the learning journey is the product itself. In both cases they gain on two fronts: a low total cost of ownership on the mundane layer and high value on the strategic layer.
This model calls for a carefully designed integration layer: API-first thinking, middleware that connects the package and the custom software, and clear agreements about which system is the leading source for which data. Get this wrong and you end up with two sources of truth and permanent data friction. Get it right and you get the best of both worlds.
Build-on-buy also makes MVP validation easier. You can first use a package to validate whether a process works in practice, and only later, once volume and differentiation justify it, move to custom development for specific components. That reduces the risk of a large up-front investment that may not fit.
Six sectors and the typical outcome of the trade-off
No sector has a fixed answer, but there are patterns. Below is the outcome we most often see recur in each sector, along with the reasoning behind it.
Logistics and transport
Often hybrid. A standard TMS package for the basics, custom development for planning algorithms and a customer portal where these make the difference in the market. Package fit for planning is usually below 70% for specialist carriers.
Care and healthcare
Often a buy approach with a thin custom layer. Strict compliance requirements make building a new EHR package almost unfeasible. Custom work comes into play in patient engagement, integration with proprietary measuring equipment and record extensions.
Construction and building services
Often build or hybrid. Packages such as Bouw7 cover part of the need, but project-specific costing, materials management and site apps are typically differentiating and worth building in-house.
Retail and e-commerce
Often build-on-buy. Shopify or Magento for the storefront, custom development for PIM flows, B2B portals or fulfilment logic. Package fit for pure retail is high; for operations it is often low.
Financial services
Often hybrid with a strong build component. Compliance packages for KYC and AML, custom development for advisory flows, pricing engines and customer portals that set you apart.
Manufacturing and industry
Often build for MES and operations, buy for ERP. Production processes differ so much from one factory to another that MES packages rarely fit well. ERP is another matter, where the standard usually wins.
The decision tree: four questions that settle the choice
A simple sequential test. Answer them in this order; the first to yield a clear "yes" or "no" usually gives you the answer.
Is it core or context?
Does the process define your distinctiveness in the market? If so, building is worth seriously considering. Is it a commodity (bookkeeping, payroll)? Then buying is almost always better.
What is the package fit?
Above 85%, the package wins. Below 70%, custom development wins. In between, look at build-on-buy, or an adaptable low-code platform as an intermediate solution.
What is the five-year TCO?
Calculate licence + customisation + integration + switching costs. Compare with build cost + maintenance + opportunity cost. Make it quantitative, not emotional.
How quickly does the process change?
Does the process change structurally within package release cycles? Then a package fits. Does it change faster (regulation, market pressure, business model)? Then custom development is more agile.
After these four questions, the direction is usually clear. If the outcome is not obvious — which does happen — build-on-buy almost always emerges as the best hybrid option. Ask for an independent assessment from someone who implements both packages and custom solutions; anyone who only does one or the other will inevitably give biased advice.
Frequently asked questions about build vs buy
An independent build-versus-buy assessment
We implement both packaged software (Exact, AFAS, Shopify, Bouw7) and custom software. This means we can give you an honest assessment of which route will serve you best, rather than which route suits us best.
Book a no-obligation conversationIf you lean towards building your own, it helps to see what custom software actually involves in your sector. applatenmaken.com has an overview of custom software by sector and process.