Our process
Seven phases, 21 artefacts.
Process is only worth publishing if it tells you what you actually receive. Every phase below ends with something concrete — a document, a running system, a test result — rather than a percentage complete.
Our process
Seven phases, and what you get from each.
No phase ends with a status update. Each one produces something you can read, run or hold us to.
- 01
Discover
Understand the problem well enough to argue about the solution.
What happens
- Interview the people who do the work today
- Map the current process, including the workarounds
- Identify the constraint that actually limits you
- Agree what success would look like in numbers
What you get
- Problem statement
- Current-state process map
- Success criteria
- 02
Plan
Scope, sequence and price before anyone writes code.
What happens
- Break scope into independently shippable slices
- Choose architecture and record why alternatives lost
- Surface the risks that could change the estimate
- Fix scope and cost for the first phase
What you get
- Architecture decision records
- Phased delivery plan
- Fixed-scope quote
- 03
Design
Interface and data model designed together, because they constrain each other.
What happens
- Design the critical flows first, not the marketing pages
- Model the data alongside the interface
- Build a clickable prototype for the risky flows
- Check contrast, keyboard paths and states before build
What you get
- Interactive prototype
- Data model
- Component inventory
- 04
Develop
Weekly working software, not weekly status updates.
What happens
- Ship a working increment every week
- Every change reviewed before it merges
- Automated checks run on every commit
- Decisions that change the plan are raised immediately
What you get
- Weekly deployed increment
- CI pipeline
- Reviewed commit history
- 05
Test
Verify behaviour, load and accessibility — not just that it compiles.
What happens
- Automated coverage on the paths that matter most
- Load test against the real architecture
- Keyboard and screen-reader pass on every flow
- Failure modes rehearsed, including rollback
What you get
- Test suite
- Load test results
- Accessibility report
- 06
Deploy
A cutover that has already been practised.
What happens
- Rehearse the migration on production-like data
- Verify rollback actually works before you need it
- Configure monitoring and alerts ahead of traffic
- Go live with a named person watching
What you get
- Migration runbook
- Monitoring dashboards
- Tested rollback path
- 07
Maintain
Ongoing ownership, so the system does not quietly decay.
What happens
- Patch dependencies and vulnerabilities on a cadence
- Review performance against the original baseline
- Keep runbooks current as the system changes
- Report monthly on changes, incidents and risk
What you get
- Monthly report
- Upgrade cadence
- Current runbooks
What we need from you
Projects fail on decisions, not code.
Almost every delayed project we have seen was blocked on an answer, not an implementation. Three things from your side make the difference.
One person who can decide
Not a committee. Someone empowered to choose between two reasonable options within a day or two, because that is the cadence weekly delivery requires.
Access, arranged early
Repositories, cloud accounts, the systems we need to integrate with. Waiting on credentials is the most common and most avoidable delay in this work.
Honesty about constraints
Budget ceilings, immovable dates, internal politics around a legacy system. We would rather design around a real constraint than discover it in week six.
Start here
Tell us the problem.
We'll be honest about the fit.
A first conversation costs nothing and is useful even if you go elsewhere — you'll leave with an architecture opinion and a realistic sense of scope.
- Reply within 24 hours
- No sales sequence