We plan the work, then work the plan.
Most digital projects fail because nobody worked out what the business actually needed before the building started. We structure engagements to discover the real problem, deliver working software early, and adapt when things change.
Six stages from idea to impact.
Discover
What happens
- Interviews with leadership, operations and frontline teams
- Review of the systems and processes you run today
- Analytics, support tickets and the spreadsheets people maintain by hand
- User research where the people who'll use this are reachable
Your part
A kickoff workshop, then a few hours of interviews. The most useful thing you can give us is access to the people doing the work.
What you own
- Current-state map, including the undocumented workarounds
- Findings summary with the problems ranked by cost
- A shared vocabulary for the rest of the engagement
Define
What happens
- Turning findings into discrete, comparable opportunities
- Sizing each one by business impact against delivery effort
- Agreeing the first increment and what sits outside it
- Baselining the metrics this work is meant to move
Your part
One decision session. We bring options and trade-offs; you own the call on sequence and scope.
What you own
- Prioritised roadmap with dependencies made explicit
- Scope definition for the first release
- Success metrics, measured before anything ships
Design
What happens
- Information architecture and flow design before any styling
- Low-fidelity prototypes tested with real users early
- Interface design against accessibility requirements from the first sketch
- Component and pattern library so the next screen is faster
Your part
Weekly reviews. Changing a prototype costs hours; changing shipped software costs weeks — this is the cheapest place to disagree with us.
What you own
- Clickable prototype of the core journeys
- Design system: components, tokens, patterns and usage rules
- Accessibility specification per component
Build
What happens
- Two-week cycles, each ending with working software
- Risky integrations and unusual data shapes proven first
- Automated tests, accessibility checks and performance budgets in the pipeline
- Security and access review before launch, not after
Your part
A demo every two weeks and a named decision-maker who can unblock us. You see progress in the product, not in a status report.
What you own
- Working software in an environment you can use
- Integrations to the systems that already hold your data
- Test suite and CI/CD pipeline running in your organization
Launch
What happens
- Migration, cutover planning and rollback path
- Performance and accessibility verification on real devices
- Training, documentation and runbooks for your team
- Monitoring and alerting so problems surface before users report them
Your part
Communications to your users, and the internal sponsor who tells people this is the new way of working.
What you own
- Live product
- Handover package: documentation, runbooks, walkthroughs
- Support arrangement for the first weeks
Evolve
What happens
- Measuring against the metrics baselined in Define
- Usability review once there's real behavior to look at
- Prioritising the next increment from evidence rather than opinion
- Capability transfer so your team can carry it forward
Your part
A regular review cadence. Some clients keep us on a retainer; others take it in-house at this point, which is a good outcome.
What you own
- Performance report against the original success metrics
- Prioritised backlog for the next phase
- A clean exit whenever you want one
How we run the week.
One team, one channel
Strategy, design and engineering sit on the same team for the whole engagement, in a shared channel with your people. Nothing gets thrown over a wall, because there isn't one.
Two-week cycles
Every cycle ends with something you can look at and react to. No long silences followed by a reveal.
Decisions written down
Every significant choice is recorded with its reasoning, so nobody has to reconstruct why six months later.
Bad news early
If a date is slipping or an assumption was wrong, you hear it in the next demo, not at the end. It's the only way a fixed timeline means anything.
Engagement models.
Discovery sprint
A fixed, low-commitment start. You get a roadmap and a business case you can act on with us or without us.
Best For
You know something needs to change and not yet what to build.
Project delivery
A defined outcome delivered by a dedicated team, in two-week increments with working software at the end of each.
Best For
The problem is understood and you need it built well.
Ongoing partnership
A standing team that keeps improving what's live — measuring, iterating and shipping against a shared backlog.
Best For
The product is live and needs to keep getting better.
Embedded team
Our designers and engineers work inside your team, on your board, to your rituals — adding capability rather than taking work away.
Best For
You have the team and need more of a specific skill.
Logistics & details.
Do we have to run all six stages?
How much of our team's time will this take?
What happens if the scope changes mid-project?
Can we stop partway?
Who owns the work?
Ready to change the way you work?
Tell us about your challenges and we'll tell you how we'd approach them.
Discuss a project