Custom Software vs Off-the-Shelf: How to Decide

Feature lists are the wrong document

The custom versus off-the-shelf argument is usually conducted as a feature comparison, and feature comparisons mislead in both directions. They overstate what you will use from a packaged product, because vendors demonstrate the common case and buyers recognise their own requirement in it. They understate the cost of a packaged product, because the features on the list are the easy ones and the work is always in the fourth requirement nobody wrote down. And they say nothing about the two things that most often settle these projects: how the system fits the process you already run, and what it costs to live with in three years.

Start from the work instead. Write down the processes the system has to support, in the order they happen, and mark the steps where the current way of working has already bent around the tools rather than the other way round. Those bends are the real specification. A packaged product that does not match them will either be resisted or will force you to change how you work, and the second outcome is the expensive one.

Then note, separately, how the work is likely to change. Requirements that are stable are strong candidates for packaged software. Requirements that move with the commercial strategy are the ones that tend to outgrow a product after two or three years, because every commercial change arrives in the system as a requirement and a vendor’s roadmap is not aligned with yours.

The cost nobody adds up

Both options get compared on the wrong figure. The purchase price of packaged software, or the first invoice from a custom build, are the numbers that get quoted, and neither describes the cost over the life of the system.

For packaged software the running total includes implementation and configuration by somebody who knows the product, data cleansing and migration (usually the largest hidden item), the annual licence with its likely tier increase as user numbers grow, integration work if it does not already talk to your other systems, internal time spent administering it, the process changes needed to fit it, and the cost of replacing it if the vendor changes terms or is acquired.

For a custom build the running total includes the discovery, specification and design work that comes before anyone writes code, the build itself (rarely the biggest part), migration, the integration and infrastructure work, the first year of support after launch, which is when the cost of a rushed build becomes visible, and every subsequent change — because a custom system has no upgrade path and each change is priced as new work.

Compare across a realistic horizon, three to five years or whatever fits the business plan, and use ranges rather than single numbers. Label any figure that is a guess. A spreadsheet where every input is a range and the output is a range communicates far more honestly than a proposal showing one confident total, and it exposes which assumption the decision is actually sensitive to. SmartEdge IT Solutions builds that model alongside the recommendation, so a client can change an input and watch the answer move rather than being handed a number to accept.

When the process, not the software, is the problem

The most common finding on this kind of engagement is that the software was never the constraint. A team spends a year deciding between an off-the-shelf system and a custom one, then discovers the thing actually costing money is a spreadsheet held together by one person, or an approval chain with three redundant steps that exists because of a policy set when the business was a different size.

Signs that the process is the issue: the same data entered in more than two places, exceptions handled outside the system because the system cannot represent them, and the person who knows how it works being unavailable. Automation helps here, and so does cutting the approval chain — but buying software to solve a process problem usually makes that problem more expensive, because you then have to configure the software to accommodate it.

Custom development does buy real advantages in one situation: when the process is a genuine competitive difference and copying it would be strategically damaging. Where the system encodes something a competitor would pay to have, that is a defensible reason to build. Most requirements are not of that kind, and it is worth asking directly which ones are.

If the answer is none of them, the honest recommendation may be to standardise rather than choose. Our application consulting work at SmartEdge IT Solutions regularly ends with a recommendation to buy and stop customising, which is a disappointing sentence to write and a useful one to deliver.

Integration is where both options get expensive

Every system you add creates work at the boundaries. This is the part of the comparison that most often reverses the conclusion, because integration cost is underestimated on both sides.

Packaged systems are generally built to export data rather than to be integrated properly. If the requirement is that a quote, an order or a ticket appears in a second system without anybody copying it, ask the vendor for the documented API, the rate limits, the authentication model, and the cost of the interface tier. A product with no supported API is a product you will pay to integrate twice: once now, and again when the vendor changes something.

Custom systems can integrate properly, because the integration is designed in, and that is one of the stronger arguments for building. It is also where scope creep lives. Every additional system on the list brings its own edge cases — failure handling, retries, partial writes, reconciliation — and each needs to be priced and specified rather than assumed.

Both need something most specifications forget: a rule for when the two disagree. Which system is authoritative for a given record, what happens to an entry that exists in one and not the other, and who resolves it. Systems with no agreed answer to that question accumulate a manual reconciliation process nobody planned for.

Lock-in, and what exit looks like

Ask what leaving would involve, before signing anything. The honest answer is often uncomfortable.

With a packaged product the exit questions are: can we export our data in a usable format, in bulk, without a fee; is the schema documented; do we need the vendor’s own export tooling, and does that tooling keep working after cancellation; who owns the data on the other side. Data ownership should be unambiguous in the contract. Ask to see an export before you buy, using a small set of real records, and open the file. An export that requires the vendor’s support team to run a job is a dependency.

With a custom system the questions are different and more uncomfortable: do we own the source and the repository, and is the history intact; who holds the credentials for production; are the build and deployment scripts documented well enough that somebody else could deploy a change; what state is the documentation in. A custom system with undocumented infrastructure is not an asset — it is a dependency with extra steps.

There is a people risk on both sides as well. A packaged product puts future capability in the vendor’s hands and in the hands of whoever administers it. A custom build concentrates it in one codebase, which is a smaller number of named individuals than a mid-sized business can absorb when they leave.

A method you can run in one meeting

Score the options against the criteria that actually differ for your situation, rather than a generic scorecard. A version that works:

1. List requirements and mark each as essential, useful or nice to have. Anything the business cannot operate without is essential. This list is the only place features belong.
2. Score each essential requirement as met, adaptable, or not met for both options. Adaptable means achievable by configuration or a documented extension point, not by forking.
3. Draw total cost over the agreed horizon as a range, using the categories above.
4. Apply the vetoes. Some things are not tradeable: a legal requirement, an integration that must exist, a process the business will not change, a data residency condition. If an option fails a veto it is out regardless of its score.
5. Check delivery risk. A custom build carries schedule risk and depends on finding and keeping a capable team. A packaged purchase depends on the vendor’s roadmap and on implementation capacity, which is often the real bottleneck — the product is available and the people to configure it are not.

The point is not to reach a number. It is to have the same conversation on both sides of the table, with the criteria written down somewhere a disagreement can be located rather than argued about.

The answer most teams end up with

Few real choices are one or the other. The common outcome is a packaged system for the commodity parts of the business and something custom for the few processes that genuinely differentiate it — an integration layer, a portal, a pricing engine, a workflow the product does not model. The point of this shape is that each part is bought or built on the criterion that suits it, and the boundary is drawn once, deliberately, instead of emerging by accident.

The failure mode is choosing the wrong boundary. Customising a packaged product until it is unrecognisable usually costs more than building the specific thing, because every future upgrade then fights the changes. Build the exception separately and let the packaged system stay upgradeable.

Whichever way it goes, the business management software side of the work and the custom development side need the same discipline: a written specification, a testable definition of done, and change requests priced separately from the original scope.

What to put in writing before you sign

Whichever option you choose, the same short list governs the relationship, and it belongs in the contract or the statement of work rather than in an email.

• What is included, what is explicitly out, and what happens to the price if volumes change.
• Data ownership, export format, and the assistance provided if you leave.
• Who owns the intellectual property, and under what licence.
• Service levels, how they are measured, and what happens when they are missed.
• The maintenance model: what is included after launch, how changes are priced, and what response you get for a fault.
• Who owns each side of every integration, and what happens to the arrangement if the other party is acquired.

If the answer to any of these is vague, that is not a reason to walk away. It is a reason to put it in writing, which is far cheaper at this stage than at any other.