Process
From first call to live product.
Seven stages, each with a defined deliverable and a decision at the end of it. So you always know what is being worked on, what comes next, and what is waiting on you.
- 01Discovery
- 02Scope & Strategy
- 03UI/UX
- 04Development
- 05Quality Assurance
- 06Launch
- 07Support / Improvement
The Seven Stages
How the work moves
Nothing below is a formality. Each stage is here because skipping it doesn't save time — it shows up later as a rebuild.
- 01
Discovery
We start with the business behind the build: what it sells, who it serves, and where it is currently losing time or money. Then the people who will actually use the thing, and what they are trying to get done.
- Business
- Users
- Requirements
- 02
Scope & Strategy
Discovery becomes a decision. We agree what is in this build and what is explicitly not, map the flows a user moves through, and choose the architecture against the version after this one — not just the launch.
- Requirements
- Features
- User flows
- Technical planning
- 03
UI/UX
Wireframes settle hierarchy before anything is styled, then interface design settles the look. You get a prototype you can click and react to while changing it is still cheap.
- Wireframes
- Design
- Prototype
- 04
Development
The build runs against the agreed scope: interface, application logic, and the integrations between them. It goes to a staging URL you can open from the first build week, not at the end.
- Frontend
- Backend
- Integrations
- 05
Quality Assurance
Every flow tested against what it was scoped to do, on real devices rather than a desktop window resized narrow. Performance is measured here against the budget agreed in planning.
- Functional testing
- Responsive testing
- Performance
- 06
Launch
Deployment, DNS and redirects, analytics verified, and a walkthrough of anything you will be editing yourself. Launch is a scheduled event with a checklist, not the moment the work stops being watched.
- 07
Support / Improvement
After go-live the product starts producing real behaviour, and that is the first honest information anyone has had about it. We stay available to fix, tune, and build the next thing the data argues for.
Communication & Project Management
How we stay in sync
Most project pain isn't technical. It's not knowing where things stand — so this part is designed as deliberately as the build.
- 01
One point of contact
You get a single person who is accountable for the project and close enough to it to answer without going to ask.
- 02
A standing check-in
A recurring call on a cadence we agree at kickoff, with a short written summary afterwards so decisions don't live only in someone's memory.
- 03
An environment you can open
A staging URL from the first build week. Progress is something you look at, not something you're told about.
- 04
Decisions written down
Scope changes, trade-offs, and anything agreed on a call gets recorded — which is what stops the same conversation happening three times.
On every project
- An agreed scope document
- Stage-by-stage deliverables
- A staging URL from week one
- Written notes after every call
- Change requests scoped before they start
- Direct access to the people building it
- Handover documentation at launch
- A named contact after go-live
FAQs
Questions about working together
What do you need from us to get started?
Less than most people expect. A conversation about what the product has to do is enough to begin — we don't need a finished brief, a spec, or wireframes. If you have existing research, analytics access, or brand assets, they shorten Discovery; if you don't, producing what's missing is part of it.
Who do we actually talk to during the project?
The people doing the work. There is one point of contact accountable for the project, but designers and engineers are not held behind an account manager — questions about the build get answered by whoever is building it.
What happens if the scope changes mid-build?
It gets scoped before it gets started. A change request is written down, estimated, and either agreed into the current build or parked for the next one. What doesn't happen is work quietly absorbing additions until the schedule stops meaning anything.
Do we see the work before launch?
Continuously. You review a clickable prototype during UI/UX, and from the first build week there's a staging URL you can open any time. Nothing is revealed at the end.
Do we have to write the content?
You own it, but you're not left with a blank page. Layouts are designed against real copy rather than placeholder text, so we'll draft structure and, where it helps, first-pass wording for you to correct — which is far easier than writing from nothing.
What happens after launch?
Support and improvement is stage seven, not a separate relationship. You get handover documentation, a walkthrough of anything you'll edit yourself, and a named contact for fixes and the next round of work.
Can you pick up a product someone else built?
Often, yes. Discovery in that case includes reading the existing codebase and being honest about what is worth keeping — sometimes the answer is a rebuild, and sometimes it's a much smaller intervention than you were braced for.
Get Started
Know the process. Start the project.
Tell us what you're trying to build and what it has to do. We'll come back with how we'd approach it, which stages it needs, and what the first one would produce.
Or read more first