Process
From idea to impact.
Five stages, run in short cycles. You see working software throughout rather than only at the end, and you always know what is being worked on and why.
The five stages
5 stages
What actually happens, and when.
- 01
Discover
Understand your business, users and goals. We map the process as it runs today and agree what success looks like.
- Requirement notes
- Process map
- Scope and estimate
- 02
Design
Define the experience, the architecture and the product direction — before a line of production code is written.
- Screen designs
- Data model
- Technical plan
- 03
Build
Develop the product in short cycles using modern engineering practice, with something reviewable at the end of each one.
- Working builds
- Code review
- Automated tests
- 04
Launch
Test, deploy and make the product available to users, with monitoring in place from the first day it is live.
- Deployment
- Monitoring
- Handover docs
- 05
Grow
Improve, automate, scale and evolve — guided by what real usage tells you rather than what we assumed.
- Usage insight
- Enhancements
- Support
Inside the build
8 steps
How a build runs.
- Problem
- Requirements
- Architecture
- Design
- Development
- Testing
- Deployment
- Scale
How we work
4 principles
Four things we hold to.
Problem before technology
The first conversations are about your business, not our stack. The technology is chosen once we understand what has to be true.
Small, reviewable increments
Work lands in short cycles. At the end of each one there is something you can open and use, not a status report.
Bad news travels fast
If an estimate slips or an assumption turns out wrong, you hear it that week. Surprises get more expensive the longer they wait.
Yours from day one
The repository, the infrastructure and the credentials belong to you throughout, not at the end.
Working together
6 answers
The practical questions.
It depends entirely on scope. A focused automation or a small tool can be a few weeks; a first product version is usually a couple of months; a substantial business system runs longer. We give a range after discovery and refine it as the specification firms up.
Someone who can answer questions about the business and make decisions, available for a short call each week. Projects slow down far more often from waiting on decisions than from engineering.
Fixed price where the scope is genuinely settled, and time and materials where we both expect to learn during the build. A common middle path is a fixed-price discovery phase that produces a scoped, fixed-price build.
They usually do. Changes are assessed for effort and impact, then you decide whether to add them now, defer them, or trade them against something already planned.
The source code, the deployment setup and documentation covering how to run and change the system. Nothing is held back as leverage.
Yes, if you want that. Support and maintenance terms are agreed before launch rather than improvised afterwards.