Commissioning
How to commission a bespoke web application
The strongest brief describes the business problem, users, constraints and measures of success. It does not pretend every screen and feature is already known.
By the Voodoo AI product, design and engineering team
9 min read
01
Begin with the situation, not a solution diagram
Describe who is doing what today, where information begins, what gets repeated, which exceptions cause trouble and what the consequences are. Include the tools already involved and the people who will operate the service after launch.
This gives a prospective supplier room to challenge the proposed solution while keeping them accountable to the real problem. A requirement such as ‘build a dashboard’ is weak; ‘help account managers see which client decisions are blocking delivery without checking four systems’ is testable.
The GOV.UK Service Manual explains why testing assumptions early reduces the risk of building the wrong thing. Read the source at GOV.UK Service Manual
02
Define the first complete journey
A first release should complete one valuable journey end to end. If a client portal lets someone upload a document but staff cannot review, request a correction and record approval, it is not a smaller complete product—it is an unfinished workflow.
Ask suppliers to identify the central journey, supporting administration, required integrations and deliberate exclusions. Keep future ideas in a visible roadmap without allowing them to quietly enter the first release.
03
Make data, access and security part of the brief
Before build, identify the types of information involved, who can see or change them, retention needs, export requirements and the systems that remain authoritative.
- Request a clear organisation, user-role and permission model.
- Agree authentication, account recovery and high-risk action controls.
- Ask how development, testing and production data are separated.
- Define backups, recovery, monitoring and responsibility for incidents.
- Record privacy and security decisions throughout the product lifecycle.
The NCSC secure development principles provide a useful baseline for evaluating a supplier's development approach. Read the source at National Cyber Security Centre
04
Evaluate evidence, not confidence
Ask to see a relevant live product and have the supplier explain one difficult workflow, one trade-off and one operational lesson. A polished homepage proves visual ability; it does not prove role-based access, data integrity, migration or support capability.
The proposed team should be visible. Understand who is responsible for product decisions, interface design, engineering, quality and delivery—and whether those people remain involved after the sale.
05
Contract for clarity and change
The agreement should cover deliverables, review rhythm, acceptance, change control, payment stages, confidentiality, data handling, intellectual property, third-party licences, hosting access, documentation, support and exit.
- Tie milestones to observable outputs or decisions, not vague percentages complete.
- Make the route for new information and scope changes explicit.
- Ensure your organisation can access its code, infrastructure, domains and data as agreed.
- Define the defect-support period separately from later enhancements.
- Do not leave migration and operational handover until the final week.
ICO guidance requires data protection to be considered at design stage and throughout the lifecycle, not added at the end. Read the source at Information Commissioner's Office