Architecture document
Target architecture with component responsibilities, data stores, hosting topology, authentication model and the decisions we rejected with the reasons. Written to be read by your architect, not by a procurement panel.
How we work
Discovery and scoping
A fixed-scope, fixed-fee sprint that ends with a document set you can price, challenge or take elsewhere. It exists because a serious estimate for an integration-heavy build cannot be produced from a requirements document and a two-hour call.
It is a small commitment on purpose. You should be able to test how we work before committing a quarter of a million pounds to it.
What you receive
Five documents, all yours
Integration map
Every system in scope, the interface mechanism available for each, the field-level system of record, update direction, expected volumes and the failure behaviour we would design for.
Phased estimate
A breakdown by phase with a cost range and a stated confidence level for each. Phase one carries the tightest range because it is the phase we understand best; later phases are honestly wider.
Risk register
Technical, data, organisational and third-party risks with likelihood, impact, the mitigation we propose and who owns it. Data quality and vendor API limits usually dominate this list.
Delivery plan
Pod composition, calendar, dependencies on your team, environment requirements and the acceptance approach for each phase.
Commercials
Duration, fee and credit
- Duration
- Two to four weeks depending on the number of systems in scope. Four weeks is typical where more than five integrations are involved.
- Fee
- Quoted per engagement Fixed at the outset. No time-and-materials overrun on discovery.
- Credit
- Credited in full against the first build phase if you proceed with us within three months of the sprint completing.
- Ownership
- All outputs assign to you on payment, with no restriction on using them with another supplier.
- Your input
- Around two days per participant, read access to relevant systems, and one person who can make decisions.
Week by week
How the sprint runs
Week one is evidence gathering: process observation with the people doing the work, system walkthroughs with whoever maintains them, schema and interface review, and a first pass at data quality. We look at production data, anonymised where required, because the shape of the real data determines most of the architecture.
Week two is design and challenge. We draft the target architecture and integration map, then run a session specifically to attack them — where would this fail, what happens when that vendor changes their API, which assumption is doing the most work. Anything unresolved becomes a risk register entry with an owner.
The remaining time produces the estimate and delivery plan, and a walkthrough with your team. You get the draft before the final session so the meeting is a challenge session rather than a presentation.
Questions
Frequently asked
What does the discovery sprint cost?
The fee depends on the number of systems in scope and the length of the sprint, and it is credited in full against the first build phase if you proceed with us.
What if we do not proceed with the build?
You keep everything. The architecture document, integration map, estimate and risk register are yours, licence-free, and are written so another supplier can quote from them.
How much of our team's time does it take?
Roughly two days per participant across the sprint: workshops, system walkthroughs and a review of the draft. We also need read access to relevant systems and documentation.
Book a discovery sprint.
Tell us which systems are in scope and we will tell you the duration, the fee and who from our side would run it.
Talk to us