Consider packaged, custom, and hybrid options
There is no universal technology choice. GDS purchasing guidance considers building, buying, and combining approaches, alongside needs, maintenance capability, and the lifecycle. We use it as a decision-making reference; UK government procurement rules are not general obligations for your business. A hybrid option might keep standard operations in a product and address one material gap through a custom integration or interface.
Technical sources for this section: Government Digital Service [1]
Set critical requirements before scoring
Express a critical requirement through reviewable evidence: branch-level permissions, a complete order export, or connectivity to the stock system of record. If an option fails and the remedy is unproven, record it as currently unsuitable. Compare the remaining options using weighted criteria. Agree weights before supplier demonstrations so an attractive secondary feature does not redirect the decision.
| Comparison criterion | Proposed evidence |
|---|---|
| Process fit | Run the main scenario and exceptions with an actual user |
| Integration and data | Sample exchange, API limits, and usable export |
| Ownership cost | Equivalent scope and a common time horizon |
| Security and operations | Roles, audit events, recovery, and support ownership |
| Changeability | A sample change, upgrade impact, and supplier or team dependency |
Calculate ownership cost using shared assumptions
Choose a common planning horizon, such as three years in an illustrative comparison. For each option, combine starting costs, recurring costs over that period, foreseeable changes, and exit or transition costs. Include staff time for data cleansing and training. Do not enter zero for an unknown: record a range and its assumption. This model supports comparison; it is neither a project quotation nor a guarantee of return on investment.
- Start: discovery or evaluation, procurement or development, migration, integration, and training.
- Recurring: user- or usage-based licensing, infrastructure, support, and maintenance.
- Change: more users and data, new rules, upgrades, and compatibility testing.
- Exit: usable data and attachments, documentation, knowledge transfer, and overlapping systems.
Give every option the same scenario
For an illustrative wholesaler, follow an order with contract pricing through stock reservation, approval, and cancellation. Ask each supplier to run that journey with anonymized data: a product video or screenshot does not establish scenario fit. If a live integration cannot be tested, mark that element unproven. For custom development, a prototype likewise demonstrates only the assumptions actually tested, not every future capability.
- Separate evidence into observed behavior, written commitment, and unproven claims.
- Involve the daily user, data owner, and operations owner.
- Run an exception such as insufficient stock and an access-control test alongside the successful path.
Write down ownership, upgrade, and exit questions
Code ownership alone does not establish transferability. Repository access, build instructions, dependency licenses, and operating documentation also matter. In a packaged product, an export entitlement does not establish a usable export: ask about format, attachments, identifiers, cost, and delivery time. Turn a change of supplier or support team into a reviewable exercise. Contract commitments need review against the specific project.
- Who creates backups and who tests recovery?
- How do upgrades affect extensions and integrations, and who tests them?
- Which access rights, documents, and datasets transfer when the engagement ends?
- Who owns incidents, urgent changes, and end-of-support communication?
When is each approach worth investigating?
This table starts a discussion; it is not a universal verdict on products or teams. Configuration might cover an unusual process, while limited maintenance capacity might make a custom build unsuitable. Verify the claimed fit in your own evaluation.
| Approach | Promising signal | Risk to investigate |
|---|---|---|
| Packaged | The workflow fits supported product behavior | Roadmap dependency, exit limits, and customization cost |
| Custom | A proven material gap, with product ownership and maintenance capacity | Scope uncertainty, delivery quality, and reliance on individuals |
| Hybrid | The standard core is sufficient and the remaining gap has clear boundaries | Integration ownership, version compatibility, and data authority |
Create a decision record you can revisit
Record the problem, rejected options and reasons, critical requirements, trial evidence, cost assumptions, residual risks, and decision owner on one page. Set a review date or a trigger for revisiting the choice, such as a material price, scale, or integration change. If the result hinges on an unproven assumption, test that assumption before making a broad commitment. Once a build is chosen, a discovery brief clarifies the delivery detail.