How we work
How we deliver software, end to end.
A clear path from a first conversation to a live product we keep improving. Five phases, planned to overlap so the work never stalls, with a checkpoint you sign off on at the end of each one.
The short version
Five phases, planned to overlap.
Most builds run through the same five phases: discovery and scoping, design and architecture, the build itself, launch and hardening, then support. They don't run in neat single file. Design stays a step ahead of the build, hardening starts before the last feature lands, and support begins the day you go live. Here's the cadence, what happens in each phase, and what you have in hand at the end of it.
Delivery cadence
How the phases run, side by side.
Each bar is one phase, laid on a shared timeline that runs left to right. Where bars sit next to each other, the work happens at the same time. That overlap is the point: it's how the build keeps moving instead of stalling between stages.
- 01Discovery
- 02Design and architecture
- 03Build
- 04Launch and hardening
- 05Support and iterate
The chart shows the shape and order of a typical build. Exact lengths depend on scope; we give you a real range during scoping.
Phase by phase
What each phase does, and what you get.
- 01
Discovery and scoping
We learn the problem, agree what we're building and why, and turn that into a plan you can sign off on.
What happens
- Workshops with your team to map users, goals and the systems we touch.
- We write down scope, risks and the order we'll build in.
- Rough sizing so you know the shape of the budget before any code.
Who's involved
- Our side
- A lead engineer and a product person, sometimes a designer.
- Your side
- Whoever knows the business and can make decisions on scope.
GateA scope document, a prioritised backlog and a build plan. You decide whether to go ahead before we move on.
- 02
Design and architecture
We shape how it looks, how it flows and how it's built, far enough ahead of the build to keep it moving.
What happens
- Interface design for the core screens, reviewed with you.
- Technical design: data model, services, the third parties we integrate.
- We pick the stack and set up the repo, environments and pipeline.
Who's involved
- Our side
- A designer and a lead engineer, with input from the build team.
- Your side
- Feedback on flows and screens, and your brand assets if you have them.
GateAgreed designs for the main flows and a technical plan. Design keeps running a step ahead once the build starts.
- 03
Build, in short cycles
We build in one to two week cycles, ship working software to a test environment each cycle, and you see real progress every week.
What happens
- Features built, reviewed and tested in small, releasable slices.
- A working build in a test environment you can click through, weekly.
- We adjust the order as we learn. Tests and reviews run the whole time.
Who's involved
- Our side
- The engineering team, QA, and a lead who runs delivery day to day.
- Your side
- A point of contact for questions and a short review each week.
GateWorking, tested software at the end of every cycle, and a clear view of what's done and what's next.
- 04
Launch and hardening
We get it production-ready, run a security and performance pass, and put it live with a plan for the first weeks.
What happens
- Final QA, a security review, and load and performance checks.
- Production setup, monitoring, backups and a rollback plan.
- Go-live, then a close watch over the first days in real use.
Who's involved
- Our side
- Engineering, QA and DevOps, with the lead on call around launch.
- Your side
- Sign-off on the release and a go date that suits the business.
GateA live product, the accounts and code in your hands, and documentation for your team.
- 05
Support and iterate
We stay on after launch: we fix issues, watch how it's used, and keep improving it on a cadence that fits you.
What happens
- Monitoring and quick fixes for anything that breaks in production.
- Small, regular releases driven by real usage and your roadmap.
- Reviews on a set rhythm so the next round of work is planned, not reactive.
Who's involved
- Our side
- A standing team or named people, sized to how active the product is.
- Your side
- Priorities for what to improve next, and feedback from your users.
GateA product that keeps getting better, with a support arrangement you can scale up or down.
How we work
A few things we hold to.
- 01
We work in short cycles. One to two weeks each, so plans stay close to reality and a wrong turn costs days, not months.
- 02
You see progress every week. A working build in a test environment you can click through, not a status slide that says it's nearly done.
- 03
Phases overlap on purpose. Design runs ahead of the build and support starts at launch, because strict, separate stages tend to stall.
- 04
Every phase ends at a gate. Something concrete in hand and your sign-off before we carry on, so there are no surprises and a clean place to pause.
- 05
You own the code from day one. We work in your accounts where you prefer and hand over everything with documentation. You're never locked to us.
Straight answers
Questions about timelines and working together.
How long does a project take?
It depends on scope, but a focused first release is usually a few months from scoping to launch. Discovery takes one to two weeks, design and the build overlap for most of the middle, and hardening before launch is short. We give you a realistic range during scoping and update it as we learn, rather than promising a date we can't stand behind.
How often will we hear from you, and how do we follow progress?
Every week. You get a short review and a working build in a test environment you can click through, plus a running view of what's done and what's next. Your point of contact can reach the lead between reviews. The point of small, frequent releases is that you're never waiting months to see whether the work is on track.
What if our priorities or scope change mid-project?
That's expected, and the short cycles are built for it. Because we work in one to two week slices, you can reprioritise the next cycle without throwing away work. For a fixed-scope project, a change to the agreed scope goes through a written change request so the timeline and cost stay honest. Either way you see the effect of a change before we act on it.
What is a phase gate, and do we have to approve each one?
A gate is a clear checkpoint at the end of a phase with something concrete in hand: a scope document after discovery, agreed designs and a technical plan after design, working software after each build cycle. You review and approve before we carry on. Gates keep surprises out and give you a natural place to pause, adjust, or stop.
Do the phases really overlap, or is it one after another?
They overlap. Design runs a step ahead of the build instead of finishing first, hardening starts while the last features land, and support begins at launch and runs long. Strict, separate stages tend to stall. Running them with a planned overlap keeps the work moving and lets each phase learn from the one before it.
Ready to map out your build?
Tell us what you want to build and where you are today. We'll walk you through how the phases apply to your project and reply to every serious enquiry within one business day.