Choose the delivery approach your project needs.
A small review, a defined build and ongoing support solve different problems. Start with the outcome, then agree who owns each part of delivery.
Three practical ways to begin.
Discuss the scope that fits your current stage.
Describe the task, current setup and the result you need.
Check deliverables, exclusions, recurring costs and responsibilities.
Use the portfolio and a scoping conversation to assess relevant experience.
| Planning question | Focused review | Defined build | Ongoing support |
|---|---|---|---|
| Best fit | An unclear brief or existing system that needs review | A defined website, application or workflow | A live system with a continuing backlog |
| First output | Findings, priorities and a recommended scope | An agreed release with acceptance criteria | A prioritised work plan and support process |
| How work is agreed | A bounded assessment or discovery brief | Written scope, milestones and review rounds | Coverage, capacity and escalation in the agreement |
| What to confirm | Inputs, access and the decision the review supports | Content, integrations, ownership and handover | Service hours, included changes and reporting |
What we put into a useful project agreement.
Clarity at the start makes delivery and handover easier to assess.
A testable outcome
Define the users, key workflows, deliverables and criteria for accepting the work.
Accounts and assets
Confirm code, design files, domains, licences and access responsibilities.
Milestones and review
Agree feedback points, required inputs and how changes to scope are handled.
Support you can understand
Set the support period, service hours and process for fixes and future changes.
Bring the brief you have today.
A sketch, an existing system or a short description is enough to begin the scoping conversation.