Custom or off-the-shelf software? Calculate the cost of the whole operating model.
Licence price and development cost are not enough. Compare 24-month cost, fit with the critical process, integrations, pace of change and the consequence of choosing the wrong system.
Short answer
Buy off-the-shelf software when it handles your critical process, roles, data and integrations without expensive workarounds. Build custom only where the process is unique or drives your advantage, and only after you have compared the full 24-month cost and tested the riskiest part on real data.
Off-the-shelf wins when the process is standard
If an available product handles the critical roles, data, permissions and integrations without expensive workarounds, buying it is usually faster and less risky.
Do not compare feature lists alone. Walk the critical path from input to outcome and record every exception, manual handoff and point where people work around the system.
Off-the-shelf is the better choice when:
- the process follows a common, stable pattern
- integrations are available and maintained by the vendor
- the company’s advantage does not depend on system behaviour
- configuration covers expected changes without custom code
Calculate two years of operation, not only the starting price
For a standard tool, count licences, implementation, integrations, paid add-ons, user growth and work performed outside the system. For custom software, include discovery, delivery, hosting, maintenance, security and continued development.
Add the cost of change and the cost of a wrong decision. A cheaper tool may force manual work or limit the product. Flexible custom software may be unjustified when the problem is standard.
| Area | Off-the-shelf | Custom software |
|---|---|---|
| Process | Standard and stable | Unique or critical to advantage |
| Integrations | Available in the product | Unusual data, roles or systems |
| Change | Configuration is enough | Direction evolves with feedback |
| Cost | Predictable licence | Investment in control and fit |
| Risk | Vendor constraints | Responsibility for your own product |
Before building everything, test one critical path
If the comparison is inconclusive, select the flow that determines whether the project makes sense. Agree on a success criterion and test the largest unknown using representative data and constraints.
Good validation may recommend buying a standard product, building the first increment or stopping the investment. Each outcome is better than funding a large project without evidence.
- Map the critical path and its exceptions.
- Compare the full 24-month cost.
- Test the largest risk before committing to full scope.
- Decide whether to buy, build or stop.
This is the job of the Decision Sprint: five working days on one agreed part of the sales process, ending with a scope, a cost estimate and a recommendation.
What a custom build looks like when it is justified
When the answer is to build, the first release should cover the critical path and nothing else. Alufix is a complete e-commerce solution the team built on Medusa.js, and Rader is a company website with an AI chatbot and 3D previews built in Next.js. Both case studies describe the verifiable scope of the work rather than promised results.
If your process is a mix of standard and unusual parts, see how separate B2B and B2C stores can share one catalogue before deciding to replace everything.
Frequently asked questions
When should you choose off-the-shelf software?
Choose an existing product when it supports the critical process, roles, data and integrations without costly workarounds. Walk through a real scenario including exceptions instead of comparing feature lists alone.
How do you compare custom and off-the-shelf costs?
Compare the same scope over 24 months. For an existing system, include licences, implementation, add-ons, integrations and work outside the system. For custom software, count discovery, development, hosting, maintenance, security and future changes. Include switching costs and the risk of choosing incorrectly in both options.
What should you test before commissioning a complete system?
Describe one critical path, its exceptions and a measurable success criterion. Then test the largest uncertainty, such as an integration or data availability, in a limited experiment. The result should support a decision to buy, build or stop.
Written by
Piotr Graczyk
Helps translate sales goals and business operations into e-commerce scope and the buying experience. Connects product strategy with design and implementation, guiding the collaboration from the initial brief to a working solution.
Want a second opinion on your platform decision?
Describe the sales process and the platform you are considering. We prepare a hypothesis before the call and name the largest unknown.