How we work
Clear decisions, visible progress, no surprises
Four stages and three ways to engage, so scope, cost and progress stay in plain view from the first call to long after launch.
Four stages, the same every time
Every project follows the same rhythm, whether it is a two-week discovery or a year-long product build.
Understand the problem
We talk to the people who will use and run the product, review what exists and agree the one result that matters most.
- Goals and success measures
- User and stakeholder notes
- Risks and unknowns list
Agree the plan
Scope, architecture, milestones and cost are written down and signed off before build work starts, with trade-offs made in the open.
- Prioritised scope
- Architecture note
- Fixed-phase estimate
Build in the open
Two-week cycles, a working demo at the end of each one, and a shared board where you can see exactly what is done, in progress and next.
- Fortnightly demos
- Shared project board
- Weekly written update
Launch and keep improving
We release carefully, watch real usage, fix what surfaces and hand over documentation, or stay on as your product team.
- Launch checklist
- Monitoring and alerts
- Handover pack
Three ways to engage
Pick the model that matches how defined the work is. You can move between them as the product matures.
Discovery sprint
Fixed priceBest whenYou have an idea or a problem, but not yet a defined scope.
What happensTwo to four weeks of workshops, research and prototyping that end in a prioritised scope, an architecture note and a reliable estimate.
Defined build
Milestone basedBest whenYou know what the first release must do and need it designed, built and launched.
What happensA dedicated team delivers in two-week cycles against agreed milestones, with demos, a shared board and change control in writing.
Ongoing product team
Monthly retainerBest whenThe product is live and needs steady improvement, support and new features.
What happensA stable team with monthly capacity, a shared roadmap and agreed response times for support and maintenance.
Project scoper
Find your starting point in three questions
We will suggest an engagement and carry your answers into the enquiry form.
Working with us
How do projects usually start?
Most projects start with a short call, followed by a fixed-price discovery sprint of two to four weeks. Discovery produces a prioritised scope, architecture note and estimate. If the scope is already clear, we can go straight to a defined build.
How will we know how the project is going?
You get a working demo every two weeks, a shared project board showing what is done and what is next, and a short written update every week covering progress, risks and decisions needed from you.
What happens if the scope changes?
Change is normal. We log every change request, explain its effect on cost and timeline, and only proceed once you approve it in writing. Often a new idea can replace something lower priority so the budget holds.
Which engagement model should we choose?
Choose a discovery sprint if the idea is not yet scoped, a defined build if you know what the first release must do, and an ongoing product team if the product is live and needs steady improvement. The scoping tool on this page suggests a starting point.
Ready to start with a discovery sprint?
Tell us what you need. We reply within one business day with next steps, questions or a time to talk.