Custom software or off-the-shelf: where the decision actually turns
For CRM, ERP and industry-specific tools, off-the-shelf is usually the right answer. The three cases where custom software genuinely pays, and the calculation that decides it.
“We need custom software” is rarely the right diagnosis. The real problem is usually this: a process is jamming somewhere, and nobody has written down exactly where.
This piece is for making that call. The short answer: start with off-the-shelf and move to custom only when the arithmetic says so. The long answer is below.
A note on scope: ecommerce works differently and is covered separately. What follows is about CRM, ERP, inventory, field operations and internal line-of-business tools.
What off-the-shelf actually buys
When you buy a packaged product you are not just buying software. You are buying the bugs that thousands of companies have already found over years of use, ready-made integrations, documentation, and a development roadmap that continues without you.
In exchange you give up two things: a monthly fee and flexibility. If your process does not resemble the one the product assumes, you are expected to change your process.
Do not dismiss that second point. In most companies, a large share of what gets called “our business is different” is habit nobody has questioned. Being pushed toward a standard is sometimes the most valuable thing a packaged product does for you.
The three cases where custom genuinely pays
1 · When the process is your competitive advantage
If what makes your work different from your competitors’ is the process itself, forcing that process into a standard product erases the advantage.
The question that separates them: is this process the reason a customer pays you, or is it just internal plumbing? Accounting is plumbing — buy it. If your pricing engine is what wins customers, that is a custom build.
2 · When licence cost overtakes build cost
This is the arithmetic half of the decision, and it usually goes undone.
Take the per-user monthly fee, spread it over three years, and multiply by your expected user growth. Compare that with the build cost plus three years of maintenance.
For small teams, off-the-shelf almost always wins. As headcount grows, the curve turns. The crossover point varies by sector, but the shape does not: packaged software gets more expensive as users grow, a custom build does not. That asymmetry is the heart of the decision.
3 · When the integration chain keeps breaking
If you run three separate products and move data between them by hand, the cost is not in the licences — it is accumulating in that manual handling.
Even here, custom software may not be the first step: in most cases an automation layer that connects the existing products costs far less than rewriting everything.
The calculation that decides it
Write the three-year total cost of ownership in two columns:
Off-the-shelf: licence × users × 36 months, setup and training, integration work, and the cost of process adaptation — what it costs you to change how you work in order to fit the product.
Custom: discovery, build, testing and deployment infrastructure, three years of maintenance (15–20% of build cost per year), servers and services.
If the two columns are close, pick off-the-shelf. The reasoning is simple: a custom project can run late, a packaged product cannot. The side carrying the uncertainty needs a clear advantage to earn the risk.
Three common mistakes
“Let’s build custom first, then grow into it.” Investing in infrastructure before validating product-market fit is building a factory before you know which product sells. Run on a packaged product first, measure the bottleneck, then write something custom for that bottleneck.
Defining the scope as “everything.” This is the number one reason custom projects overrun, covered in detail here. The right approach is to pick the single most painful process and build that.
Not planning the handover. The biggest risk in custom software is not cost, it is dependency. The repository, servers and service accounts must be in your name; why that matters more than the price is covered in software development pricing.
A practical sequence
For most companies the right order is:
- Start with a packaged product and use it for six months.
- Keep a written record of where you do things by hand and where the product fights you.
- Read that list. If most items are habit, change the process. If most are genuine differences, you now have the scope for a custom build — grounded in six months of observation rather than a guess.
For an overview of the types of software and which ones a business needs, see what software is.
One of the most common places this decision comes up is CRM; a concrete example is in CRM software.
The same decision applies to ERP; more in building ERP software.
If you would like to read that list together, let’s set up a scoping call. What to ask when picking an agency is covered separately, and turning that list into a brief is covered here.
