How a project actually runs, stage by stage
Including what you get at the end of each phase, roughly how long it takes, and how much of your own team's time it will need. No stage exists to fill a slide.
your team's time is planned, not assumed
- A costed plan you own after discovery
- Working software every two weeks
- A rehearsed rollback before launch
Four stages. Each one hands you something real.
Every phase, with durations and what you get
- 01
Discovery
1–3 weeks
We map how the work actually happens today, including the exceptions people handle informally and never wrote down. Those exceptions are usually where off-the-shelf software failed you, and they are the most common cause of scope surprises later.
What you get
- Process map of the current state
- Scoped requirements with priorities
- Risks named, with the riskiest assumptions identified
- Costed plan you own — build with us or take it elsewhere
- 02
Architecture
1–2 weeks
System boundaries, data model, integration points, and a phased roadmap. This is where the decisions that are expensive to reverse get made deliberately rather than by accident — tenancy model, where authorisation lives, how money is represented.
What you get
- Architecture and data model
- Integration plan for systems you are keeping
- Phase plan with a usable first release defined
- Technology choices with the reasoning stated
- 03
Design
2–4 weeks
We design the frequent path first and make it fast, then make the rare path findable. Delivered as a system — components, tokens, rules — so the twentieth screen stays consistent with the first without a designer reviewing each one.
What you get
- Interactive prototype of the core flows
- Design system with components and tokens
- Responsive behaviour and accessibility considered
- 04
Build
Phased
Two-week cycles with something demonstrable at the end of each. AI assists implementation throughout; every change passes human review, automated tests, and a security check before it reaches your branch. You see progress continuously rather than at milestones.
What you get
- Working software in a staging environment each cycle
- Automated test coverage on the paths that matter
- Reviewed, documented code you own outright
- 05
Testing
Continuous
Testing runs alongside the build rather than as a phase at the end, because defects found six weeks after they were written cost far more to fix. Before launch we add the checks that only make sense against a complete system.
What you get
- Automated regression suite running in CI
- Security review of auth, data handling, dependencies
- Performance verified against a stated budget
- User acceptance testing with your team
- 06
Launch
1–2 weeks
Deployment pipeline, monitoring, and a rollback path that has been rehearsed rather than assumed. Where we are replacing a live system, we run in parallel and shift traffic gradually instead of betting on a single cutover weekend.
What you get
- Production deployment with automated pipeline
- Monitoring and alerting configured
- Tested rollback procedure
- Handover documentation and team training
- 07
Support
Ongoing
Launch is the middle of the project. Dependencies get advisories, platforms deprecate APIs, and usage reveals things no amount of testing would have. A retainer means someone is responsible for noticing.
What you get
- Monitoring with agreed response times
- Security patching on a defined cadence
- Budgeted capacity for improvements, not only fixes
How we work at every stage
You talk to engineers
No account manager relaying messages. You are in direct contact with the people building your software.
Phased, not big-bang
Something usable ships early. A specification agreed six months ago is a worse guide than a system your team has actually used.
Decisions are written down
Architectural choices and their reasoning are documented, so nobody has to reconstruct them from the code a year later.
Changes are expected
Requirements move. Regular checkpoints exist so change gets absorbed into the plan rather than fought as scope creep.
Questions about how we work
01Do we have to start with discovery?
For anything substantial, yes — and we price it as a fixed-price phase so it is a contained commitment. It produces a real scope, architecture, and costed plan that belongs to you. You are free to build it with someone else afterwards; that has happened and it is a fair outcome.
02How much of our time will this take?
Discovery is intensive — expect several hours a week from people who know the process. During the build it drops to a demo and feedback session each cycle. We would rather set that expectation up front, because projects stall when the client side has no time allocated.
03What if we need to change direction mid-project?
Phased delivery exists precisely for this. Changes get discussed at the cycle boundary and folded into the plan. Significant scope changes affect timeline and cost, and we tell you that at the time rather than absorbing it silently and resenting it.
04How do you handle disagreements about scope?
By having written scope from discovery to refer back to, and by raising concerns early rather than at delivery. If we think a request is a mistake, we say so and explain why — then build what you decide.
05Do you work fixed-price or time-and-materials?
Discovery is fixed price. Build phases can be either — fixed price where scope is genuinely well defined, time-and-materials where it is exploratory. We recommend whichever fits the actual uncertainty rather than whichever suits us.
Tell us what you are building.
Share the problem and we will come back with an approach, a rough shape of the work, and what it would take to deliver it.