How we work
Five stages, and what you get at the end of each one.
Discovery is fixed price, so you know what things cost before you commit to a build. After that you see something running from the first sprint. You can stop at any milestone and keep everything you've paid for, because it's been in your accounts the whole time.
- 01
- 02
- 03
- 04
- 05
Sprint review. The client sees the staging environment, not a slide.
- 01
Discovery
2–4 weeks · fixed price
We start by learning how the work gets done today, from the people doing it, before anyone opens an editor. You leave with a scoped plan and a number you can take to the board.
What happens
- Interviews with stakeholders and front-line users
- Mapping the workflow and every system it touches
- Whether to build, buy or integrate each part
- Technical and security constraints
- A prioritised scope for the first release
You get
- Discovery report
- Scope and an estimate with ranges
- Risk register
- Recommended team and timeline
- 02
Design & architecture
2–4 weeks
The main screens become a clickable prototype that we test with the people who'll use them. In parallel we design the architecture, data model and integrations to fit what you already run.
What happens
- UX flows and wireframes
- A clickable prototype, tested with users
- Design system and UI kit
- Architecture, data model and how it connects to your other systems
- Environments, CI/CD and monitoring set up
You get
- Tested prototype
- Design system
- Architecture decision records
- Delivery pipeline, up and running
- 03
Build in releases
Two-week sprints
Every two weeks something new lands in a staging environment for you to try. You review real screens with the team, and re-order the backlog when what you've seen changes your mind.
What happens
- A vertical slice of a feature each sprint
- Automated tests and code review on every change
- Preview environments, one per pull request
- Demo and planning with your team every fortnight
- Continuous performance and security checks
You get
- A deployable increment every sprint
- Sprint demo and burn-up chart
- Updated backlog and forecast
- 04
Launch
1–3 weeks
We rehearse the release before doing it for real. Data migration, training and monitoring are planned back in discovery, so nobody is writing a migration script the week before go-live.
What happens
- Data migration, with parallel running where it's needed
- Load, security and accessibility testing
- Training, documentation and runbooks
- Feature-flagged roll-out with a rollback plan
- A hyper-care period with the build team on hand
You get
- Production release
- Runbooks and documentation
- Monitoring dashboards and alerts
- 05
Run & evolve
Ongoing retainer
Software nobody maintains rots. A monthly retainer keeps it patched and fast, and pays for the small changes that keep coming after launch.
What happens
- Monitoring, patching and dependency upgrades
- Support with an SLA behind it
- A backlog of improvements, worked through month by month
- Quarterly roadmap and cost review
- Knowledge transfer to your in-house team, if you want it
You get
- Monthly report
- Roadmap
- A healthy, up-to-date codebase
Engagement models
Three ways to pay for the work.
You get the same calibre of team and the same reporting whichever one you pick. What changes is how scope and cost get agreed.
Fixed-scope project
Best for: A first release you can define clearly, or a problem that's already well understood.
Discovery first, then a fixed estimate for the build with the scope, milestones and acceptance criteria written down. When the scope changes, and it usually does a little, we price the change and you decide whether it's worth it.
- Fixed price for discovery
- Delivery in milestones
- Scope and acceptance criteria agreed up front
Dedicated team
Best for: Ongoing product development, or a roadmap that will keep changing.
A team that stays the same for the length of the engagement, working inside yours for a monthly fee. You own the backlog and the priorities. We're responsible for the quality and pace of the work, and for who's on the team.
- A monthly cost you can plan around
- The same people month to month
- Scale up or down with 30 days' notice
Support & evolution retainer
Best for: A system in production that needs looking after and improving.
Support with an SLA, plus a monthly budget of hours for improvements. That covers security patches, upgrades and monitoring, and the steady stream of small changes that arrive once people use a system every day.
- Response-time SLAs
- A monthly budget for improvements
- Roadmap review every quarter
Working principles
Habits we keep on every project.
Senior people in small teams
Every team is led by an engineer with ten or more years of shipping behind them. Small teams mean fewer hand-offs and quicker decisions.
Something to click on within weeks
A deployable version goes into a staging environment a few weeks into the build. Clicking through real screens tells you more than a status report does.
Tied to a business number
We're paid to move a business number. If a requirement won't do that, we'll say so and suggest something that will.
Boring technology, on purpose
Tools we've run in production for years, chosen for the five years of maintenance that follow launch. That usually rules out whatever was new at last year's conferences.
Everything is yours
Source code, designs, infrastructure and documentation live in accounts you control from the first week. If you decide to leave, you take all of it with you.
Numbers, tracked from the start
Performance budgets, test coverage, uptime and the business metrics the project is meant to move go on a dashboard in the first sprint and into every monthly report after that.
Questions
Questions about working with us.
How do engagements usually start?
With a 30-minute call so we understand the problem. If it makes sense for both sides, the next step is a short fixed-price discovery, which gives you a scoped plan and an estimate with ranges before you commit to a build. The plan is yours to take to another supplier if you want to, though most clients carry on with us.
What does a typical project cost?
It depends on the scope, which is why discovery comes first. As a rough guide, discovery runs from £8k to £25k. A first release of a custom platform usually lands somewhere between £40k and £250k, and a dedicated team is priced monthly depending on who's on it.
Who will be working on my project?
A small team led by a senior engineer, with a product designer and a delivery lead where the project needs them. The people you meet in discovery are the ones who build the system, and they're the ones in the demo every fortnight.
What happens after launch?
Either we hand it over fully, with documentation and training, or you keep us on a support and evolution retainer with SLAs and a monthly budget for improvements. Most of the production systems we've built are still on a retainer.