Off-the-shelf or custom software: which fits your business?

Describe an important transaction through its starting data, roles, decisions and expected outcome. Include a normal case and an exception. In sales, this might be a quotation whose scope changes after internal approval. In an ERP, an additional service might become billable only after customer approval.

Ask each proposed solution to work through the same case. Record what already works, what needs configuration and what manual work remains. An extra entry is not automatically a reason to reject a product. Consider how frequently it occurs, the consequences of a mistake and who would perform it.

Distinguish necessary requirements from familiar habits. A second approval may have a sound business reason; a particular column order may simply be familiar. If a sensibly simplified process works in an existing product, that is a reason to consider the product seriously.

These three illustrative situations show why no route always wins:

A licence fee cannot be compared directly with a development proposal. First give both options the same initial scope, number of users and evaluation period. Separate confirmed prices, estimates and unresolved items. An empty cost field does not mean zero.

Depending on the proposal, implementation can include configuration or development, migration, integrations, business testing and training. Your employees also need time for decisions and acceptance. Operation can involve subscriptions, hosting, support, updates, administration and maintenance of added functionality.

One product provides a concrete example of why these boundaries matter: Odoo lists implementation services and maintenance of custom code as exclusions from its subscription. This is not a general conclusion about the cost of packaged software. It shows why the scope of a service must accompany its price. Odoo plan inclusions and exclusions, checked on 24 September 2026.

Our guide to ERP implementation and operating costs provides a structured list of cost items. Assess potential benefits separately: which current work would disappear, which would remain and which new maintenance tasks would arise? An assumed saving should not enter the calculation as an achieved result.

With a standard product, the vendor influences available features and supported versions. With custom software, changes depend on development capacity and how well the system can be understood. An extension can combine both dependencies. Every route needs an agreed support arrangement.

Ask what would be required to change provider later. Which documentation, exports and access details would be handed over? Is it clear how to establish a working test and production environment? Which components come from third parties? Agree on the required use and handover arrangements explicitly rather than assuming them from the word “custom”.

Check internal capacity too. Someone in the business must be able to clarify requirements and accept results. Even when a provider operates the technology, decisions about working practices remain with your organisation. A larger software package cannot replace an accountable process owner.

Request a concrete change scenario for each option: adding a required field, changing an approval or updating a connection. Who implements it, who tests it and what does the proposal include? Those answers are more useful than a general claim of flexibility.

The template separates essential requirements from criteria that can be traded off. Each mandatory requirement needs a clear test and a status of “met”, “not met” or “unverified”. An option with an unresolved mandatory requirement is not ready for a final decision. A high usability score must not conceal a demonstrated business constraint.

For the remaining criteria, assign weights from 1 to 5 before the demonstrations. Then evaluate each option on the same scale from 0 to 4: 0 means not met, 1 means major gaps, 2 means partly met, 3 means met and 4 means a demonstrated additional advantage. Empty fields remain unverified; do not treat them as zero. This scale is a planning aid, not a scientifically validated measure.

Multiply each weight by its score and add the results for each option. Compare only the same fully assessed criteria. The total structures the discussion; it does not replace mandatory checks or the rationale. If the results are close, check whether a small change in weights reverses the order. That identifies assumptions worth investigating further.

Download the decision matrix as CSV · Download the worksheet as Markdown

The files provide a register for requirements, evidence and open questions. Scores are intentionally blank. Record the vendor, product version and test date with the evidence so a demonstration can be traced later. A CRM requirements specification with acceptance criteria helps turn sales and customer-work needs into precise tests before scoring them.

Record which route was selected, the scope it covers and the reasons. Include remaining gaps, accepted manual work, responsible people and assumptions still to be checked. Note what would trigger a reassessment, such as a different sales process or an additional legal entity.

A suitable standard product can be the right decision. A limited extension may also be more practical than rebuilding a whole system. Where a demonstrated gap remains, custom ERP development can be assessed specifically for that workflow.

For an initial discussion with SYNQ, prepare the affected process, the options already checked and the unresolved mandatory requirements. These provide a useful basis for an assessment without deciding the outcome in advance.