The five questions that decide it, a three-year total cost comparison, the hidden costs on both sides, and the hybrid approach that is most often right.
"Should we buy off the shelf or build custom?" has no general answer — but there is a set of questions that produces one. This article reduces the decision to five questions, compares the hidden costs of both options, and describes the hybrid approach that is most often right in practice.
The decision is usually framed wrongly: "which is better" or "which is cheaper". Both are the wrong question. The right one is: is this a process that differentiates you from competitors, or standard work everybody does the same way?
The five questions that decide it
- How specific to you is the process? For standardised work — accounting, email, HR — an off-the-shelf solution is almost always right. For processes that arise from how you work and that competitors do differently, a package will try to force you into its own shape.
- How often does the process change? Frequently changing business rules mean a "customisation" negotiation every time in a packaged product. If your rate of change is high, control needs to be yours.
- Who owns the data? Can you export it, in what format, and how quickly? The answer determines today the lock-in you will face later.
- How many systems must it connect to? Where deep integration is required, the package's API sets the ceiling. A product with a weak API can push integration cost above the cost of building.
- How many users, at what volume? With per-user pricing, growth raises cost non-linearly.
If three or more answers come back as "specific to us / changes often / deep integration", custom development is on the table.
Hidden costs
| Item | Off the shelf | Custom software |
|---|---|---|
| Initial cost | Low | High |
| Time to go live | Short | Long |
| Annual cost | Grows with users/volume | Maintenance and development |
| Customisation | Limited, sometimes chargeable | Unlimited, you set the cost |
| Integration | As far as the API allows | As far as you need |
| Knowledge dependency | On the vendor | On the build team / documentation |
| Exit cost | Data migration and rebuild | The code stays with you |
The hidden cost of a package usually comes from three places: per-user pricing rising with growth, "can this screen work differently" requests turning into a customisation package, and the lock-in discovered when you try to move your data.
The hidden cost of custom software is maintenance: the work does not end at delivery. Servers, updates, security patches and the development requests that arrive as business rules change all require continuity. Without someone owning that, custom software becomes a system nobody dares touch within two years.
The most frequently correct answer: hybrid
In real projects the decision rarely sits at either extreme. The most efficient setup is usually: an off-the-shelf solution for standard work, a custom layer for differentiating processes.
A concrete example: using a packaged e-commerce platform such as Shopify while custom-building your own pricing logic, dealer order flow or ERP integration. You hand over payments, security and infrastructure maintenance to the platform while keeping the part that differentiates your business under your own control.
We cover how to do this on Shopify in our app development article — most needs are solved by a small extension written at the right point rather than an entire system.
Decision matrix
| Situation | Approach |
|---|---|
| Standard process, low volume | Off the shelf |
| Standard process, high volume, deep integration | Package + custom integration layer |
| Process specific to you, frequently changing rules | Custom software |
| Specific to you but not yet clear | Clarify the process first; vague requirements are the most expensive kind of development |
| The process that is the source of your competitive advantage | Custom — control of it should not sit outside |
Where the answer is unambiguous
Definitely off the shelf: accounting and e-invoicing, email marketing, help desk, file sharing, basic CRM. Solutions in these areas are mature, cheap and compliant; writing them from scratch is almost never sensible.
Definitely custom: the software that runs your differentiating process — how your dealer network operates, your bespoke pricing and discount logic, your production planning, or the digital experience you offer customers. Forcing those into a package's shape means becoming identical to your competitors.
Common mistakes
- Deciding on initial cost alone. Three-year total cost often reverses the picture.
- Heavily customising a package. When customisation cost approaches build cost, the package's advantage is gone — and it breaks on updates.
- Starting development before requirements are clear. Ambiguity is the single factor that doubles custom software cost.
- Not planning maintenance. Unowned custom software becomes unusable within two years.
- Not asking about data export. Lock-in is noticed when you want to move, not when you sign.
Conclusion
The right decision lies not in "which is better" but in how specific the process is to you. Buy the standard work; own what differentiates you. For most companies the healthiest setup is a packaged core with a thin custom layer carrying their own business logic.
For integration decisions, see ERP integration and API integration.
At Commerslab we both build custom layers on packaged platforms and deliver end-to-end custom software. See our custom web software development service or let's assess your requirement together.
