Discovery phases have a bad reputation and it is deserved. Too many of them produce a slide deck, a Gantt chart nobody believes and an invoice.
We run a two week architecture sprint before every build engagement, and it is a fixed fee, fixed scope piece of work with a defined set of artefacts. Clients own everything it produces whether or not they hire us for the build. Three times in the last two years it has ended with us recommending the client not build the thing at all.
This is exactly what comes out of it.
Day zero: what we ask for before we start
Before the first session we ask for read access to whatever exists. Not a specification document. The actual materials:
- The codebase, if there is one, including the parts people are embarrassed about
- The last three months of the support inbox or ticket queue
- Whatever analytics exist, even if nobody trusts them
- The current cloud bill
- Any contracts with obligations in them, such as uptime commitments or data residency
The support inbox is the highest signal item on that list and the one clients are most surprised we want. A specification tells you what someone intended. The support queue tells you what is actually happening, and the two are rarely the same document.
Week one: understanding, and pressure testing the premise
Days one and two, domain mapping. Sessions with the people who do the work, not only the people who commissioned the project. For an insurance client that meant three hours with claims handlers, which produced the single most important finding of the engagement: a step everyone described as a formality was in fact where forty percent of the exceptions were caught. The proposed automation would have removed it.
We produce a domain model: the real entities, their relationships, and the state transitions that matter. Usually one page, usually contested, and the argument it starts is the valuable part.
Day three, constraint inventory. Everything that narrows the solution space, written down in one place: regulatory obligations, systems that cannot be replaced, an ERP migration next year, a hard date tied to a trade show, a team of four who will inherit this.
Half the constraints teams tell us about turn out to be assumptions. The other half are real and one of them usually eliminates the approach everybody had assumed.
Days four and five, existing system audit. If there is code, we read it and run it. Not a static analysis report, an actual read of the parts that carry the business. We are looking for four things: where the domain logic really lives, what the test coverage protects, what breaks if the one person who understands it leaves, and whether the data model can carry where the product is going.
The output is an honest assessment with one of three verdicts: extend it, extend it after specific remediation, or replace it in stages. We put a rough cost against each.
Week two: deciding, and building enough to prove it
Days six and seven, architecture options. We develop two or three genuinely different approaches, not one plan with variations. For a document processing platform: a fully managed serverless pipeline, a queue plus worker pool on containers, or buying a third party product and integrating around it.
Each option gets the same treatment: rough build cost, running cost at projected volume, what it makes easy, what it makes expensive later, and what has to be true for it to be the right answer. The last one is what makes the comparison useful. An option that is cheapest only if volume stays under a threshold the sales team intends to blow through is not actually cheapest.
Day eight, the decision session. Three hours with the client's engineering and business leads, in the room, working through the options. We come with a recommendation and the reasoning, and we have been argued out of it more than once.
Everything decided becomes an architecture decision record: context, options considered, decision, consequences. Dated and committed to the repository. In eighteen months when a new engineer asks why the system uses an event log rather than direct writes, the answer is a file rather than an archaeological expedition.
Days nine through twelve, the walking skeleton. This is what separates our sprint from a consulting exercise. We build a thin vertical slice of the real system and deploy it.
Not a prototype and not a mockup. Real repository, real CI pipeline, real cloud infrastructure defined in Terraform, real authentication, one real endpoint that does one real thing, wired to logging and metrics, deployed to a URL the client can open.
It does almost nothing. It proves the whole chain works and that our estimates are grounded in something we ran rather than something we assumed. Twice this has surfaced a problem in week two that would have surfaced in month four: once an identity provider that could not support the tenancy model the client had described, once a third party API whose rate limits made the intended architecture impossible at their volume.
Days thirteen and fourteen, the plan and the handover. A written document, typically twenty five to forty pages. Not a slide deck.
What is actually in the document
The domain model and glossary. Agreed definitions, so that "account" means one thing across engineering, sales and finance for the life of the project.
Architecture decision records. One per significant choice, usually six to twelve.
A milestone plan with cost bands. Milestones defined by what works at the end of each, never by which phase of the process is complete. "Users can register, authenticate and complete a booking" is a milestone. "Backend complete" is not, because nobody can verify it.
Estimates are bands, not points. A milestone is quoted as eight to eleven weeks, and we say which uncertainty drives the spread. A single number is a fiction that both sides pretend to believe.
A risk register with owners and triggers. Each risk gets a mitigation, an owner and a trigger condition that says when it stops being a risk and becomes a problem. Risks without triggers get quietly forgotten until they arrive.
Running cost projection. Monthly infrastructure and third party costs at launch volume, at ten times that, and at a hundred times. This has changed the architecture on roughly a third of our projects, because the option that was cheapest to build was clearly not the one to run.
A staffing plan. Which roles, at what points, and which parts the client's own team should own. We say plainly where we think they should not use us.
The three times it ended in "do not build this"
A logistics company wanted a custom warehouse management system. Six days into the sprint it was clear their requirements were about ninety percent standard, and the ten percent that was not could be handled by an integration layer over an existing product. Estimated build was fourteen months. The alternative was a licence plus four months of integration work. We wrote it up, they took it, and we did the integration.
A healthcare startup wanted an AI triage feature. The evaluation work in the sprint showed the accuracy achievable on their data was well below what would be safe to deploy without a clinician in the loop, and with a clinician in the loop the feature saved no time. We recommended against it. They shipped a much simpler routing feature instead and it worked.
An enterprise client wanted a mobile app. Their analytics showed sixty three percent of mobile sessions were three specific tasks, all of which their web application handled badly on a phone. Fixing responsive behaviour on those three flows was six weeks. The app was eight months. They did the six weeks and revisited the app question a year later, by which point they had the data to scope it properly.
Each of those cost the client a two week fixed fee and saved them between six and fourteen months of build. That is the actual return on this phase, and it is why we do not let clients skip it to save time.
Why fourteen days
Shorter and you are guessing about the existing system, which is where the expensive surprises live. Longer and it becomes analysis with diminishing returns, because the remaining uncertainty can only be resolved by building.
Two weeks is roughly where those two curves cross for a system of ordinary complexity. We extend it for genuinely large estates, and we have run a compressed ten day version under a deal timeline for due diligence work. We have never found value in going shorter by choice.
The one thing to take from this
The deliverable that matters most is not the document. It is the walking skeleton: a real, deployed, running slice of the actual system, built by the actual team, before anyone commits to a budget.
An estimate produced by people who have not run the thing is a guess with a confident font. An estimate produced by people who have deployed a working slice of it is a forecast. The difference shows up in month five, every time.