Scope and requirements
We map the workflow, existing services and data. Together we agree what the software must do, who may use each part and how we’ll check that the finished work meets the requirements.
Development and review
We build the interface, backend and integrations together. Reviews use working software so that requirements and dependencies can be checked against the way people will actually use it.
Verification and handover
We test access rules, interruptions and recovery, then prepare the deployment configuration and the handover needed to operate the software.
What we agree before development
Start with one workflow that can be described from beginning to end. For a customer portal, that might be a customer signing in, finding an order and requesting an update. For an internal application, it might be a member of staff reviewing a request and passing it to the person who can approve it. The useful inputs are the current process, the people involved, the existing systems, and examples of records they already use.
We turn that into acceptance cases with a clear outcome. In the portal example, a customer sees their own orders, staff see requests assigned to their team, and an update goes to the system that owns the order. We also agree what happens when the order service is unavailable, when access has expired, or when an update is rejected.
What a working review covers
Review a complete flow in a working build. Check the input in the interface, the rule applied by the backend, and the resulting record in the connected system. A review should establish whether someone can finish the job and understand what happened when part of it fails. For an integration, include an example response from each relevant service and check how the application handles missing information or an interrupted call.
Changes to scope are easier to make when the discussion identifies the record or operation affected. For example, allowing a second role to approve a request changes the permission check, the interface and the expected record of who approved it.
Release and handover
Before release, review which environment and configuration the software will run with, how access is provisioned, and how to verify the deployment. Agree who will investigate a failed operation, which records help trace it, and which actions can safely be retried. The handover also needs enough information to identify the deployed version and restore service after an interrupted change.
For practical examples of recovery and handoff, read the Reesponder handoff design or the Cheapwork delivery section.