Off-the-shelf or custom? Five-year total cost

How the calculation works

Both columns are plain arithmetic. There is no weighting, no correction factor and no hidden model.

The off-the-shelf column

1. Accumulated subscription = users × monthly fee per user × 12 months × years. By definition this line never ends, and it grows linearly with headcount.
2. Workaround labour = monthly workaround hours × hourly cost × 12 × years. Spreadsheet bridges built around gaps in the package, manual transfers between two systems and “the software does not do that” routines all belong here.
3. Implementation and consultancy = one-off. Package rollouts almost always carry a separately invoiced configuration effort; including it makes the comparison honest.

The custom column

1. Build fee = one-off. The default of $12,000 sits inside the published mid band of $8,000 - $15,000. Replace it with the figure from your own quote.
2. Maintenance = build fee × selected percentage × years. Published plans are 12% (essential), 18% (professional) and 25% (comprehensive). Because maintenance is optional, a 0% option exists.
3. Hosting = annual cost × (years − 1). The first year is included, so it does not enter the calculation. If the system runs on your own infrastructure, leave it at zero.

The break-even point is calculated separately: the custom build fee, net of what you would otherwise have paid for package implementation, is divided by the annual difference in recurring cost. That line answers the “when does it overtake” question and is independent of the horizon you chose.

The line that decides everything: workaround labour

Most companies run this comparison on licence fees alone, and the package wins. In practice the deciding line is not the licence but the work that spills outside the package. If any of these three sound familiar, your workaround line is bigger than you think:

• The software does not handle a task, so the task lives in a spreadsheet and the result is typed back in by hand.
• Files move between two systems on a regular schedule; nobody calls this “work”, but it consumes hours every week.
• Reports do not come out of the software; someone exports the data and formats it manually.

Even a rough measurement of those three changes the comparison completely. To measure it properly, use the manual work cost calculator and divide the annual hours it produces by twelve to get the monthly figure for this form.

How to read the result

Look at the slopes rather than the totals. Raise the user count from 20 to 40 and recalculate: the off-the-shelf column doubles while the custom column does not move at all. That is the real difference between the two models — growth is expensive when you rent and free when you own. Do the same with the horizon: the package may lead at three years and lose at seven.

Note the items that sit outside the total and cannot be priced, because the decision is not made on arithmetic alone:

• Code ownership. With a custom build the source code and architecture documentation are handed over contractually; with a package the software stays on the vendor’s infrastructure.
• Process fit. With a package you adapt to the software; with a custom system the software is written around your process. Part of that difference shows up in the workaround line, but not all of it.
• Exit cost. How much of your data you can extract from a package depends on the contract; with a custom system the data and the schema are already yours.
• Delivery risk. A custom build carries project risk: scope creep, delay, a badly designed module. That risk is invisible in the arithmetic and is managed through phased delivery.

When off-the-shelf is the right answer

Let us be straight about it, because the job of this tool is to produce a decision, not to push you in one direction. If your process stays inside the industry standard, your user count is small, you are not maintaining a parallel arrangement for work the package cannot handle, and you spend only a few hours a year on workarounds, then off-the-shelf is the right choice for you. In that case a custom build is an unnecessary investment, and the tool will say so.

The reverse is equally clear. If you enter the same data twice, if you keep building spreadsheets around gaps, and if your headcount is growing, the cost of the package rises every year while satisfaction falls. At that point a single-process pilot in the published $3,000 - $6,000 band, delivered in 2-4 weeks, keeps both the risk and the budget small.

Phased migration beats a big-bang replacement

Even when the arithmetic favours a custom system, ripping out the package overnight is the wrong move. The sequence we recommend is: pick the single process consuming the most hours, build a working module for it, and leave the package in place. When that module proves itself in the field, take the second process. This protects three things at once — cash flow, your team’s adjustment time and the risk of designing the wrong thing. For the detailed migration plan see our SaaS-to-custom transition page, and for the decision criteria see off-the-shelf versus custom.

Frequently Asked Questions