Process
Six phases, each with something you can hold.
Nothing here is unusual — it is ordinary agile delivery, written down honestly. The point of publishing it is so you know what happens in week three before you sign anything.
Discovery week
Two engineers spend five days on your problem: interviews with the people who will use the thing, a read of any existing code, and a look at the data you already hold. We come back with options rather than a single plan.
You receive
- Written technical assessment
- Two or three solution options with trade-offs
- Fixed quote and phase plan
Architecture & design
We decide the shape of the system and the shape of the interface at the same time, so neither one boxes the other in. Decisions get recorded as short architecture notes in the repository.
You receive
- Data model and service boundaries
- Clickable prototype of the main flows
- Architecture decision records
Fortnightly delivery
Two-week increments, each ending in a demo on a real environment you can click through. Priorities can change at every boundary; mid-sprint they cannot, which is what keeps estimates meaningful.
You receive
- Working software on staging every two weeks
- Demo recording and written summary
- Updated burn-up against the phase plan
Hardening
Before launch we go looking for trouble: load behaviour, permission edges, accessibility, error states, and the boring question of what happens when a third-party API is down.
You receive
- Test coverage report and known-issues list
- Accessibility review against WCAG AA
- Load-test results and tuning notes
Launch
A staged rollout with a rollback path, monitored for the first week by the people who built it. We schedule launches early in the week and never on a Friday afternoon.
You receive
- Runbook and on-call notes
- Monitoring dashboards and alerts
- Training session for your team
Support & iteration
A retainer covering patches, incidents and a steady stream of small improvements — or a clean handover to your in-house team, if that is the plan. Both are fine; we say which we think fits.
You receive
- Agreed response windows
- Quarterly health review
- Handover documentation
What we need from you
One decision-maker
Someone who can settle scope questions within a day or two. Committees are the most common cause of slipped timelines.
Access to real users
A few hours with the people who will use the software, at discovery and again before launch.
Two hours a fortnight
The demo and a short planning conversation. Beyond that we work asynchronously and write things down.
Honest constraints
Budget ceilings, immovable dates and internal politics. Knowing them early changes what we recommend.
Start with a discovery week.
Five days, a fixed fee, and a written plan you can take to any other studio if you would rather.