Choose an off-the-shelf ERP when its standard processes fit your business well enough and you can adopt them without expensive workarounds. Consider bespoke software when a valuable operational requirement cannot be met adequately through configuration or a supported extension. Keep the current system when its limitations can be addressed more economically through targeted improvements.
For a UK SME, the decision is rarely whether custom development is inherently better. It is whether a particular combination of software, process change and ongoing support produces a sensible result. The strongest proposal may keep your accounting package, connect existing tools and build one specialised operational module. Start with that freedom rather than deciding the answer before reviewing the work.
Separate business requirements from familiar habits
Ask people to describe the outcome they need before showing the current screens. “An approved order must reach dispatch without rekeying” is a requirement. “The new screen must contain the same twelve tabs” might simply describe an old implementation. Copying familiar screens can preserve unnecessary steps and make every alternative look unsuitable.
Identify requirements that protect commercial value. A manufacturer might need traceability across subcontracted work, while a service company might depend on unusual contract pricing. Explain why each matters, how often it occurs and what happens when it fails. Include examples of exceptions; they often reveal more than a long list of generic features.
Then challenge the rules with the people accountable for them. Some exist because of customer commitments; others survive because a previous system could not work differently. Record the difference. This prevents development effort being spent on a workaround that could disappear through a modest change to the process.
Put four options on the table
Compare retaining and improving the current system, adopting a standard product, extending a product and building a defined bespoke capability. Describe the same operational scenario for all four. Microsoft documents fit-to-standard and fit-gap analysis as part of Dynamics 365 implementation planning; it is a useful reference when evaluating product fit.
A standard product can be attractive when its workflow already covers the core journey and your team can work within it. Check the exact edition and configuration being proposed. Features demonstrated in another module, an extra subscription or a partner add-on should not silently become assumed inclusions in the price.
An extension or bespoke module can address a specific gap while other systems continue doing useful work. That creates integration and support responsibilities which must be named. Keeping an older application is also a legitimate option, provided you understand its support status, recovery arrangements and the cost of the remaining manual work.
Test a business scenario rather than a feature list
For a hypothetical wholesaler, ask every supplier to demonstrate the same journey: a customer places a repeat order, one item is unavailable, a substitute needs approval and the dispatch quantity differs from the original order. Follow the information through customer service, the warehouse and invoicing. Use representative examples rather than a supplier's easiest demonstration record.
Record whether each step works as supplied, needs configuration, needs custom code or cannot be demonstrated. Ask who will maintain any addition and what happens during a product upgrade. A simple spreadsheet is enough for this comparison, provided each score links to evidence and an agreed explanation.
Give critical requirements a pass or fail gate. A product that cannot preserve required traceability should not win because it scores highly on attractive dashboards. After those gates, compare usability, implementation effort, support and cost. Include the people who will run the process, not only those approving the purchase.
Compare total ownership cost over the same period
Choose a common planning period, such as three years, and use the same user and transaction assumptions. Include implementation, migration, integration, licences, hosting, support, upgrades and internal staff time. Bespoke software still has operating costs, and subscription software still needs implementation and change management. Neither route makes those responsibilities disappear.
Ask what drives each recurring charge: named users, active users, modules, storage, transactions or another measure. Include expected growth and one downside scenario. If the business acquires another branch or adds a customer portal, determine which line items change. The model should be understandable enough for a finance lead to challenge.
For cloud-backed options, Microsoft's cost optimisation principles provide a reference for considering lifecycle costs. Your comparison should also show uncertainty. A fixed subscription fee alongside an uninvestigated migration allowance is not a fully known project cost merely because one part has a published price.
Consider ownership, exit and supplier dependence
For bespoke work, clarify the contractual rights to source code, documentation and modifications. Identify third-party components and any supplier-owned modules separately. Ask whether your company will have appropriate access to repositories, cloud accounts and deployment instructions. Ownership wording alone is not enough if another team cannot build or operate the application.
For a standard product, check available exports and how integrations access data. Ask for an example export with relationships and attachments, not just a promise that reports can be downloaded. Establish what assistance is available when leaving and how long information remains accessible after termination. Include those answers in the buying comparison.
Supplier dependence exists in both approaches. A specialist custom system can depend on a small team; a heavily customised commercial platform can depend on one implementation partner. The practical response is documented operation, sensible boundaries, transferable knowledge and an agreed exit process. Compare the actual arrangements instead of assuming one software category eliminates the issue.
Choose a first phase that can change the decision
A discovery or pilot should resolve the uncertainties that matter most. If product fit is uncertain, demonstrate the difficult workflow. If integration access is uncertain, prove the connection using an appropriate test environment. If migration quality is uncertain, inspect a representative extract and rehearse its transformation. Avoid spending the pilot only on the easiest screens.
Define what evidence allows the next investment and what evidence would stop it. In the wholesaler example, the first phase could prove partial fulfilment and the accounting handover for a limited group. It need not replace every department. Agree who makes the decision, what users will test and which unresolved issues remain acceptable.
The UK government's Contracting for Agile guidance discusses commercial governance for iterative delivery. It is public-sector guidance, not a contract template for every SME. For your project, make stage outcomes, spending authority and change handling explicit with your chosen provider.
Turn the comparison into a clear recommendation
A useful decision paper can be short. State the business problem, the options reviewed, the evidence from the scenario tests and the ownership cost assumptions. Explain why the preferred route meets the critical requirements, which compromises you accept and what remains to be validated. Record the reasons while the people who made the decision are available.
Worktechlabs can help assess ERP options, improve legacy applications and connect systems through business integrations. Bring your current process, its recurring exceptions and the constraints that matter most. Discuss the options with us to define a first phase that tests the decision before committing the company to a wider replacement.
Put numbers and a delivery plan behind the decision
Use our UK bespoke ERP development cost guide to turn a preferred option into a first-phase budget, including migration and running costs. The phased ERP rollout guide then helps you define a usable pilot and the responsibilities of running old and new systems together.
Official sources and further reading
