Bespoke vs off-the-shelf software: build, buy or connect

Follow an order before writing a feature list

Take a recent customer request and follow it until someone can call it finished. A feature list might say “approvals”. The useful detail is what the approver checks, what happens when they refuse and how the next person knows they can proceed.

Now choose a request that changed halfway through, perhaps an order amended after approval. Find the record accounting used and the message the coordinator sent. If those disagree, write down where the disagreement began.

Keep business rules separate from habits. A manager’s approval limit may need to stay. Printing an email so another department can type it into a system deserves a closer look. Record the consequence, such as an incorrect invoice, rather than preserving every existing step.

The GOV.UK discovery guide begins with users, the problem and the constraints before committing to a service. Stopping after the investigation is a valid result. The guide concerns public services; its useful starting point for a business buyer is to understand the work before committing to software.

Choose the route that closes the gap

Off-the-shelf software is an existing product you adopt and configure. Bespoke software is built for agreed requirements. Integration lets products exchange information or trigger actions. Your project may need a combination.

The government’s purchasing guidance considers building, buying and a combined approach. It recommends assessing the full cost and the ability to support the result. For the task you just followed, check what each route would require your team to take on.

Fulcrum’s business-systems service follows the workflow first, then assesses whether to improve existing tools, connect them or build the missing part.

• ·Buy and configure when a product handles the important tasks through supported settings. Have the supplier demonstrate your exception using the subscription you would actually buy. Check that the team can operate it.
• ·Connect when the individual tools work well and the task stalls between them. Check what each system lets a connection read or change. Decide which record staff should trust when two systems disagree, and who corrects a failed transfer.
• ·Build when a necessary rule or customer experience remains poorly served after checking products and connections. Describe the missing behaviour precisely. Include maintenance and future changes in the decision, alongside the initial build.

The awkward order makes the comparison useful

Consider a hypothetical equipment supplier. Requests arrive through its website. A coordinator checks availability; a manager approves special terms. The coordinator then copies the accepted order into accounting, and customers email for updates.

The supplier wants an accepted request to become a traceable order while retaining approval for exceptions. Give each proposed solution the same test: the customer changes an approved request before invoicing. Watch which record changes and whether the amended terms need approval again.

• ·Configure an existing product: trial order-management software with approval settings and customer updates. Ask it to handle the amendment. A small adjustment to the process may be acceptable. Losing a necessary approval control would be a reason to reject it.
• ·Integrate the current tools: keep the website and accounting system, record the approval, then transfer the accepted order through supported connections. Check that the amended request can reach the right record. The coordinator needs to see missing information and failed transfers, with a way to correct and retry them.
• ·Build the missing workflow: create a request and approval interface around the supplier’s particular rules, then connect it to accounting. This is worth considering if the tested products cannot adequately handle the required combination. Specify which amendments require approval, who can override a decision and which version the invoice uses.

Follow the handoffs

Leave the demonstration running when something fails

Ask the supplier to reject an approval, then show what the coordinator sees. Try the changed request. Ask how staff would find an order that failed to reach accounting. The person doing the next task needs enough information to put it right.

Repeated messages are worth testing too. Shopify’s webhook documentation says an app may receive the same event notification more than once, for example after a timeout or retry, and describes detecting duplicate deliveries. The buyer’s question is straightforward: if the order message arrives twice, does accounting get one order or two? Check other platforms’ delivery rules separately.

Run the trial with the access each role would have. If the demonstration works only because everyone has administrator access, you have another question to resolve before accepting it.

A manual step can be a sensible tradeoff if someone owns it. An exception in a visible queue is a different proposition from one that needs a customer to call before anyone notices.

Copy this worksheet into the project brief

Complete an entry for each important task. Use observed examples where you have them and label assumptions. The final line should tell you what to check next.

• ·Task and completion: who needs to do what, and which record tells them it is finished?
• ·Current problem: where does the work stall or go wrong? Attach an example with sensitive information removed.
• ·Required rule: what must hold when the request changes? Identify which parts of the process the business is willing to adjust.
• ·Product fit: what has been demonstrated through supported settings? Record the subscription needed and any workaround.
• ·Connection and access: can the systems read and change the required records? Name who grants access and who resolves a failed transfer or conflicting records.
• ·Owner after launch: who handles staff questions and decides on changes? Record the technical support arrangement as well.
• ·Full cost: include setup or development, subscriptions, migration, staff training, support and future changes. Include your own team’s work.
• ·Unanswered question: what could change the choice? Name the demonstration, sample-data review or technical check needed to answer it.

Commission an investigation with a decision attached

Before paying for detailed discovery, agree which decision it should support and what you will receive. A workflow map should show where the problem sits. An options comparison should explain why one route fits, its assumptions and what the next stage would include.

If the main doubt is whether the website and accounting system can exchange the required records, test that connection first. The result may justify the wider project or change its scope. If a supported setting resolves the problem, improve the existing system. Keeping the current process is also a valid outcome when the case for change remains weak.

For a new digital service, follow the task a customer needs to complete. Identify the part existing products cannot provide, then assess whether that gap justifies custom development. Established products can still serve the rest of the service.

The ONTOUR build case study shows mobile apps, data services and a public website delivered as a connected product. Use your own task and its exceptions to decide which parts your project needs.

Sources and editorial note

Sources checked on 13 October 2026: GOV.UK discovery guidance, GOV.UK purchasing strategy and Shopify webhook delivery documentation. The comparison and worksheet are editorial advice. The equipment-supplier workflow is hypothetical.