A software development engagement should give you regular opportunities to inspect working software, resolve uncertainties and decide whether the project is ready for its next stage.
The proposal may describe a process, but the value comes from what you can see and verify during delivery. A useful project rhythm connects business decisions to working behaviour, rather than treating progress as a series of status presentations.
Use kickoff to establish decision ownership
Agree who represents the users, who approves priorities and who can make decisions about data, operations and access. One person may cover several responsibilities, but none should be left implicit.
Confirm what the first release needs to achieve and what is outside its scope. Record dependencies on content, other suppliers, access to systems and decisions your own team must provide.
A launch date without those responsibilities is only an intention. Ask which unresolved questions could affect the schedule and when they need answers.
Review a complete slice of the workflow early
Ask to see a small journey working from start to finish. A connected slice can expose assumptions about permissions, data and system boundaries that separate screen designs do not reveal.
Keep the first slice narrow enough to inspect. You should be able to understand what was built, try the relevant behaviour and give feedback before the same pattern spreads across the application.
This does not mean every early demonstration is ready for customers. Ask what is real, what is simulated and what is still missing. A useful review makes those boundaries visible.
Connect progress to acceptance
Agree how you will recognise completed work. A feature should have observable acceptance conditions, including the important failure and recovery paths.
During reviews, discuss what changed and what the team learned. If a requirement needs to change, record the decision and its effect on scope or timing. A growing backlog should not silently become an expanding commitment.
Keep a shared place for decisions, open questions and known issues. Important details should remain accessible when a team member is absent or someone new joins the project.
Give testing time and representative users
Testing needs to cover both the implementation and whether people can use it. Automated checks can exercise repeatable behaviour; user sessions can reveal confusing language, missing context and journeys that do not match how work happens.
Ask how the team tests access permissions, integrations, accessibility and recovery from failures. The scope depends on the application, but it should be discussed before the final days of delivery.
GOV.UK's quality-assurance guidance treats testing as recurring work throughout development. Use that principle when reviewing a delivery plan: a single testing phase at the end leaves less room to correct fundamental problems.
Separate deployment from a successful launch
Deployment makes the software available in an environment. Launch also involves people, communications, data and operational readiness.
Agree how existing information will move, who checks it and what happens if the release needs to be reversed. Confirm who handles incoming support requests and how the team will notice failures.
A limited initial rollout can help you observe behaviour before expanding access. GOV.UK's beta guidance describes this progression from a smaller invited audience towards wider use. The appropriate rollout for your project should follow its risks and operational constraints.
Require a usable handover
Your team needs more than a repository link. It should know who controls the accounts, how changes are deployed, where configuration lives, what is monitored and how to get help.
Ask the people who will operate the system to practise the relevant tasks before handover is complete. Documentation is easier to improve while the delivery team can still answer questions.
Finally, agree how defects and new requests are handled after launch. A clearly defined support arrangement lets both sides distinguish a failure to meet the original scope from a new requirement. That makes the next phase of the relationship easier to manage.
Sources and references.
Primary references. Checked 22 October 2026.
Abhay
Abhay handles marketing and content at Systemsvale. He writes practical guides to help business teams ask better questions about software, design, data and automation.
Meet the team ↗