We don't talk code in discovery

Most technical partners make the same mistake on the first call. Within ten minutes, the conversation is about architecture decisions, integration complexity, and stack preferences. The founder nods along or asks questions they immediately regret. By the end they've deferred to the partner on things they shouldn't have deferred on at all.

The problem isn't that the partner lacks competence. It's that they're solving the problem they're comfortable with, not the one that matters in that moment. A founder evaluating a partner has one question: do you understand my business? Technical fluency doesn't answer it. Business fluency does.

We run discovery differently.

Stay in the problem

Our first conversation with a founder covers three things: what they're trying to achieve, what's blocking them, and what winning looks like. That's it.

We don't pitch a stack. We don't propose an architecture. We don't bring up technical constraints unless the founder needs to understand one to make a business decision — and that almost never happens in the first call.

This isn't a sales technique. It's how you avoid the failure mode we've seen repeatedly in typical outsourcing arrangements: a team that dives into implementation before they've understood the problem, produces something technically impressive, and delivers something the founder didn't actually need.

The discipline is staying in business language until the problem is clear. What does this protocol need to do that it can't do today? Who gets unblocked when it works? What does failure cost — in time, in capital, in credibility? Those questions are harder than architecture questions. The answers matter more.

What we record

Every discovery call produces raw material. We keep it: transcripts, recordings, rough notes, follow-up exchanges. This collection lives in a document we keep attached to the project — not a formal deliverable, not something we share as a handoff, but a reference.

The raw material serves one purpose: feeding the spec.

The spec is the one artifact that matters. It describes what we're building — not how the system works internally, but what users can do and what outcomes they get. Written in the same language as the discovery conversation: business outcomes, not implementation details.

Everything the founder said in discovery — the constraints they named, the outcomes they care about, the failure modes they're afraid of — ends up in the spec. The raw collection doc is scaffolding. Once the spec is written, it becomes archival.

One artifact, not two

Most engagements produce two documents. A business requirements doc that the partner writes for the founder, and a technical spec that the engineers actually build from. The first one is readable but doesn't drive decisions. The second one drives decisions but the founder can't read it. They diverge within weeks.

We write one document.

The spec is written in business language from the start — what users can do, what changes for them, what the observable outcomes are. A founder can read it and confirm the team understood the brief. An engineer can build from it without translation. When behavior ships, the section that described it moves from spec to documentation.

The result is that the founder never loses the thread. There's no "business version" and "engineering version" of what's being built. There's one version, and it stays current.

We've written about the mechanics of how the spec shrinks as you build in The Spec That Shrinks. The discovery process is what determines whether the spec starts with the right problem.

Why it matters at the start

Getting discovery right isn't about methodology. It's about who stays in control of the business decision.

When a founder defers on technical questions they don't fully understand, they hand over decisions that have business consequences. Not because they're disengaged — because the conversation was framed in a language that made engagement difficult.

Running discovery in business language keeps the founder in the driver's seat. They confirm what we've understood. They correct what we've gotten wrong. They make decisions they should be making. We go build the thing they actually need.