Configure or build? A practical software decision

A team managing work across spreadsheets and email may need a better system. That does not automatically make a custom application the right investment. The first decision is which requirements can be met by configuring an existing product, which need integration, and which justify building something new.

Describe the work before the features

Write down who uses the service, what they need to achieve, and where the current process breaks down. GOV.UK’s technology guidance similarly begins with understanding user needs. For a commercial software decision, turn that understanding into a short set of scenarios that a supplier or engineering team can demonstrate.

• A normal case: a request arrives, is assigned, approved, and completed.
• An exception: information is missing, an approver is unavailable, or a request changes.
• A control: different roles must see or change different information.
• An operational failure: an integration stops, a record is duplicated, or a user needs help.
• An exit: records must be exported in a usable form if the arrangement ends.

Compare three delivery options

Compare the cost of operating the decision

An implementation quote is only one part of the comparison. Estimate costs over the same planning period for each option, state the assumptions, and show what happens if usage or scope changes. The purpose is to expose trade-offs rather than produce a precise forecast from uncertain inputs.

• Initial work: configuration or development, migration, integration, and training.
• Ongoing work: licensing, hosting, support, monitoring, and changes to the process.
• Responsibilities: who handles access, backups, incidents, and supplier coordination?
• Transition: how will the business recover its data and move to another arrangement?

Make the next commitment small enough to test

Ask for a demonstration using the scenarios that matter, with representative data where permitted. For an existing product, validate the configuration and integration limits. For custom software, test the riskiest requirement in a bounded discovery or prototype. Agree what that exercise must establish before authorizing a larger delivery.

The resulting decision should identify the selected option, the alternatives considered, unresolved risks, and an operational owner. A technically attractive system still needs a business that can support it. The right choice is the one that meets the important requirements with an acceptable ongoing commitment.