# We stopped asking our client to explain their own system > Reading the code instead of interviewing people cut the client's discovery time by ~80% — from ~16 hours a month to 2–4 — and still landed 88% of changes right the first time. _2026-07-29_ --- --- ## Results - **~80%** — less senior stakeholder time in discovery, ~16 hrs a month down to 2–4 - **88%** — first-time-right across ~240 changes, a rework rate inside DORA's elite band - **8/8** — scopes delivered on or ahead of the committed date - **0** — critical defects reached production --- ## The Problem **Understanding the system is the hard part — not changing it.** A 25-year-old core is a system no single person can hold in their head. The people who built it have moved on. The documentation drifted from the code years ago, and at five million lines no team can read the whole thing. The running system is the only complete, current record of what it does. So every change starts with the same problem: work out what the system already does, well enough to change it safely. Get that wrong and the gap shows up late — in UAT, or in production. On a system this old, it's easy to miss something — and the thing you miss is often the thing that matters. --- ## Why It Mattered **On a system that moves money, the danger is the code no one remembers.** Its flows move money and carry regulated messages. A missed entry point is not a cosmetic defect — it can break a payment or a payout on live client money. And the risk rarely sits in the code that looks complex. It sits in the code nobody thinks about anymore. Reading the code surfaced exactly that: a missing step in a money-movement flow that would have mis-stated a balance on a system of record — latent, invisible to anyone working from memory, caught before it ever ran. And it wasn't alone. **What memory told us** — every flow looked accounted for: payments, money movement, statements & balances, pricing, reporting. **What reading the code found** — verified against the running system: - A missing step in a money-movement flow — a balance would have been mis-stated - A pricing calculation that would have returned the wrong value at go-live - One region's assumptions hard-coded into another region's flow - An internal id where a customer reference should be - Two customer screens that could differ by millions - A shared change that would have silently broken another app Nothing on the left was wrong — just incomplete. On a system that moves money, incomplete is the risk: each item on the right is a real gap in the running code that no workshop surfaced — caught by reading it, before any reached production. --- ## How We Did It **Exo Discovery reads the system before we ask anyone about it.** Most discovery is guesswork with a project plan: weeks of workshops asking people to describe a system from memory, then filing the gaps under "assumptions." On a 25-year-old core, memory is the least reliable source there is — and the code that's actually running, the most reliable one, goes unread, because no team can read five million lines in the time a scope allows. **It reads:** meeting transcripts, documentation, the codebase, the running app. **Exo Discovery** maps current state from the code. Every claim about current behaviour verified against what the system actually does — not the org chart. **It produces:** a scope document; a task plan — what & why; where the change lands — first pass; open questions, routed. Inputs → engine → outputs. Because it maps current state from the code, it can even take a first pass at where a change lands in the running system — you can't do that until you know what's already there. The "how" is left out on purpose: a requirement that prescribes its own solution will be wrong. That inverts the stakeholder conversation. Their experts used to spend the hours below teaching us the system. Now they spend them checking a map we've already drawn — and deciding what to change. We don't arrive with questions. We arrive with answers to confirm. Senior stakeholder time, per month of scope: before, the usual way, ~16 hours. With Exo Discovery, 2–4 hours. **~5× less** of the client's scarcest people's time — spent deciding, not explaining. --- ## How It Ran **One loop, run for every scope.** A new scope stood up in about a week — it used to take several. The engine did the reading; the client's hours went to confirming and deciding, not teaching. Each answer fed straight back, and the map re-ran. One cycle, per scope: **the engine** reads the system, maps current state, drafts the scope. **The client** confirms the map & answers the open questions — 2–4 hrs, not 16. **Then** the map re-runs with their answers — the next scope begins. Answers feed straight back — the map re-runs. ~a week per scope, two working sessions a week. The engine does the reading; the human does the deciding. That's the shift — the client's scarce hours moved from explaining the system to confirming a map and choosing what changes. --- ## What We Learned **A deadline stops waiting on discovery.** Because the current-state map is built in days, not months, a client can put a date on the calendar before scoping is fully done. The part of legacy work that used to hold everything up no longer does. **The engine brings breadth; the client brings the business.** Exo Discovery maps scope across a vast system quickly and completely, but it doesn't turn up knowing the domain. The judgement calls and the hardest edge cases still come from the client's experts and ours — now over hours instead of weeks. --- ## CTA Carrying a system you can no longer safely change? Too large to hold in one head, too costly to get wrong — the first step isn't a rewrite. It's knowing, for certain, what the system does today. That's where realfast starts. Talk to us. --- Anonymised · a financial-services firm. Delivered on a fixed fee. "A month of scope" = a month's worth of scoped delivery work.