Process
Commit after understanding. Build after planning.
Most delivery failures are decided before the first commit — in the gap between what was promised and what was understood. This is how we close that gap.
The nine stages
- 01
Qualification
We check that the idea is defined enough to build against: who it is for, the problem it solves, the main workflow and what the first version must achieve. If it is not, we say so rather than starting and discovering it later.
- 02
Discovery
For complex work, a focused phase to understand users, constraints, existing systems and the decisions that will shape the build. Complex projects may begin with a paid discovery and architecture phase.
- 03
Scope
Deliverables, dependencies, exclusions, assumptions and client responsibilities, written down. Naming what is excluded is as important as naming what is included.
- 04
Architecture
Data model, integrations, infrastructure, security and technical risk. This happens before we commit to a delivery date, not after.
- 05
Proposal
Scope, cost and timeline together, based on the planning that preceded them rather than on a number offered in a first conversation.
- 06
Build
Execution in controlled milestones with visible progress. Risks are raised as soon as they are known rather than at the deadline.
- 07
QA
Functional testing, responsive behaviour, accessibility, performance and release checks — part of the build rather than a phase bolted on at the end.
- 08
Launch
Deployment, verification of production behaviour, and handover of what the client owns.
- 09
Support
Maintenance, bug fixing and further iterations where the engagement includes them.
The one rule
Why we do not promise a serious deadline before technical planning.
A date given in a first conversation is a guess wearing a suit. We would rather commit later and hold the commitment than commit early and renegotiate it.
- Architecture
- The data model and system design decide how much of the build is straightforward and how much is genuinely hard. That is not knowable from a description.
- Integrations
- A third-party API can be an afternoon or a fortnight. Its documentation, sandbox and failure behaviour all have to be checked before a date means anything.
- Dependencies
- Approvals, access to existing systems, provider accounts and decisions that only you can make all sit on the critical path.
- Content readiness
- A build waiting on copy, images or product data is not a build that is running. The clock starts when the inputs are in hand.
- QA obligations
- Devices, browsers, accessibility and performance verification are part of the work, and their weight varies enormously by product.
- Specialist availability
- Where a project needs branding, copy or another specialism, their availability shapes the schedule — and we plan for it rather than discovering it later.
If planning shows a date cannot be met safely at the required quality, we say so — and we will not rescue a bad estimate by shipping work we know is broken or by burning out the team. Ownership means making sound delivery decisions, not agreeing to everything.
Start here
Bring us a clear idea.
Who it is for, the problem it solves, the main workflow, and what the first version must achieve. With those four answers we can scope the rest.