Build or buy a business system? Test the workflow first

Separate necessary rules from old habits

A spreadsheet problem does not automatically require custom software. Nor does a broad feature list prove that a purchased system fits. Start with the work: who enters information, who approves it and who uses the result.

Map one complete process, such as a purchase request through approval and receipt. Distinguish mandatory controls from habits people can change. Record exceptions, including rejection, cancellation and corrections after approval. These details make a demonstration meaningful.

• List essential outcomes, not preferred screens.
• Ask process owners which rules can change.
• Separate required controls from optional conveniences.

Make each option prove its fit

Ask vendors to demonstrate your scenarios using safe sample data. Check permissions, audit history, reporting and exception handling. Mark every requirement as standard, configurable, custom or unsupported. Request written confirmation for important gaps.

For a custom build, use the same scenarios to define a narrow first release. Ask what remains manual and what integrations are necessary. A small proof of integration can answer a question that a polished screen cannot.

• Test a normal case and an exception from start to finish.
• Verify export formats, APIs and access restrictions.
• Confirm whether upgrades preserve required customizations.

Compare the whole ownership burden

Use a shared planning horizon for all options. Include licenses, configuration, migration, integration, training, support and internal administration. For a custom system, include maintenance, hosting, security updates and future changes. State uncertain estimates rather than hiding them.

An open-source license does not remove implementation or operating work. UK Government Digital Service guidance explicitly asks buyers to consider total migration costs, including exit and transition. The same questions are useful outside government, although its procurement rules do not automatically apply.

• Check how price changes with users, usage and modules.
• Assign owners for backups, access and incident response.
• Estimate the effort to export data and move elsewhere.

Choose the smallest sustainable commitment

Buying may suit a standard process that the organization can adopt. Building may suit a critical workflow with requirements available products cannot meet. A hybrid can combine a packaged core with a focused integration or custom interface.

Write a decision record with the chosen option, rejected alternatives, unresolved risks and evidence still needed. Before committing broadly, pilot one complete workflow with actual users. Agree on acceptance, migration reconciliation and a fallback if the pilot fails. Judge the choice by usable work, not the number of features shown.

• Name a business owner and a technical owner.
• Document data ownership and exit responsibilities.
• Expand only after users can complete the agreed process.