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.
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.
Two commissioning decisions from our own work
Waypilot has two different customers for its interface: the operator provisioning schools and the people running each school. A brief that simply requested a driving-school dashboard would miss tenant boundaries, school setup and the separate office, instructor and learner journeys. The commissioning question is not how many dashboards to build, but which records belong to each school and which actions each role needs.
At The Driving Training Centre, the enquiry is only the beginning. Allocation, lesson delivery, teaching progress and payments need to stay connected. A useful acceptance scenario follows one learner from enquiry through an assigned instructor to a recorded lesson, then checks what the office and learner can see. Testing each screen separately would not establish that the hand-offs work.
These are examples of product scope and design decisions, not claims of a measured return on investment. The linked studies include simplified interactions with sample data so you can examine the reasoning without access to private accounts.
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.
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.
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.