What a Good Technical Discovery Engagement Actually Looks Like

Every enterprise platform rebuild starts with a decision that gets made too fast: what the discovery phase is actually for. Most agencies treat it as a sales formality — a few workshops, a requirements doc, a slide deck with boxes and arrows. Then the real engineering starts, and the estimate from the slide deck turns out to have been fiction.

We run discovery differently, because we've been burned by the slide-deck version enough times as clients ourselves before we started building this studio. A discovery engagement should produce three concrete artifacts, not one narrative.

A working prototype, not a mockup. By the end of week one, we want a thin vertical slice of the actual system running against real (or realistically shaped) data — one critical user flow, wired through the real auth model, the real data layer, the real integration points you're worried about. This is not a Figma flow with fake interactivity. If the risky part of your rebuild is a legacy SOAP integration or a multi-tenant data model, that's what we build first, because that's where estimates go wrong. A prototype that avoids the hard part isn't discovery, it's marketing.

An architecture decision record, not a diagram. Diagrams are compression — they hide the decisions that made them possible. What you need instead is a written record of the choices that matter: why this data model and not that one, why this queueing approach handles your peak load and the obvious alternative doesn't, what the migration path off the legacy system looks like phase by phase. Every decision gets a stated tradeoff, because six months into the build someone is going to ask "why did we do it this way" and the answer needs to exist somewhere other than a Slack thread.

A number, with its assumptions attached. Enterprise buyers don't need false precision — they need to know what the estimate depends on. We give a range, and we give the specific unknowns that widen or narrow it: "if the payments provider's sandbox behaves like production, this is a 14-week build; if their webhook delivery is as unreliable as their docs suggest, add three weeks for a reconciliation layer." That sentence is worth more than a single number with two decimal places of false confidence.

The reason this matters is that discovery is where the actual risk of an enterprise rebuild lives. Once you're mid-build, most of your risk is execution risk — can this team ship what they said they'd ship. But at the start, the risk is architectural: did we pick a data model that survives your five-year roadmap, did we understand the integration constraints correctly, did we scope the migration in a way that lets the business keep running during the cutover. Bad discovery doesn't show up as a missed deadline in month one. It shows up as a rewrite in month seven, after the team has built two layers on top of a foundation that couldn't hold the weight.

We staff discovery with the same senior engineers who'll build the system, not a separate "solutions architecture" team that hands off a document and disappears. That continuity is the actual point — the person who decided how the migration should sequence is the person who'll be debugging the sequencing at 11pm during cutover, and they'll remember why they made the call.

If your last discovery engagement produced a deck you could not have used to actually start building the following Monday, it wasn't discovery. It was a proposal with better formatting.