Most agency engagements get into trouble in the first two weeks, before a single line of code has been written. The team is excited, the founder is excited, the contract is signed, and the kickoff turns into a series of “oh wait, what about…” meetings that erode trust before the work has started.
We’ve been on both sides of this enough times to take scoping seriously. What follows is the structure we use for early-stage Web3, AI, and mobile engagements — five working days that turn a vague brief into a buildable spec with a real estimate.
Day one — what is true, in writing
The first day is about converting tribal knowledge to a written artifact. Most founders we work with have been carrying their product in their head for months. They can describe it brilliantly out loud. They’ve never written it down end-to-end.
We block four hours, one engineer and one founder, and produce a single document with five sections:
- What this is. One paragraph, no jargon.
- Who uses it. The actual humans, with the actual jobs they’re doing today.
- What changes for them when this exists. Concrete, observable changes.
- What we’re explicitly not doing. This is the most important section. It’s where you find out the founder thinks the MVP includes something the team thought was post-launch.
- How we’ll know it worked. Three numbers we’d be willing to be measured on.
This document is not for the engineering team. It’s for the founder. Most of the value lands when the founder reads it back the next morning and says “actually, this isn’t quite right.” Better to find that out before the architecture diagram is drawn.
Day two — adversarial questions
By day two we have a written description. Now we attack it.
We bring in someone who hasn’t been part of the conversation — usually another senior engineer from our team — and we run an adversarial session. Their only job is to ask uncomfortable questions:
- “What happens when this user tries to do this thing the obvious way and it doesn’t work?”
- “If this number is off by 1%, does anyone notice? If it’s off by 50%?”
- “What’s the worst thing a user could do, by accident, that you’d have to roll back manually?”
- “Is there any part of this that’s only true if [external party] doesn’t change their pricing / API / chain config in the next six months?”
The output is a list of risks and unknowns. Not solved, just surfaced. By the end of day two we know what we don’t know. That’s the foundation of everything else.
Day three — architecture and the scary diagram
Day three is the technical pass. We produce two artifacts.
The first is a system diagram showing every component, every data flow, and every external dependency. We are deliberately exhaustive — every queue, every cache, every third-party API. This is not the marketing diagram. This is the diagram the on-call engineer will be staring at in eighteen months when something is broken.
The second is what we internally call the scary diagram: the same system, but only the parts that can fail. Every external API is a yellow box. Every storage system is a yellow box. Every place the system depends on a contract not changing under us is a yellow box. Looking at this diagram tends to focus the conversation: “okay, we should probably plan for what we do when [yellow box] is degraded.”
For Web3 work specifically, we do this same exercise for every smart contract dependency: which protocols are we composing with, what’s the upgrade path, what happens if they pause.
Day four — the spec and the estimate
By day four, we know enough to write a real spec. We avoid two failure modes that kill specs:
Too vague. “User can list an asset” is not a spec. It’s a placeholder. A real spec describes the screens, the data shape, the validation rules, the error states, and the edge cases. If two engineers can read it and walk away with different mental models, it’s not a spec yet.
Too detailed. A spec that prescribes a specific component library or class structure is a spec that’s already going to be wrong. Specs describe behavior, not implementation.
The estimate is paired with the spec. We estimate at the spec section level, using a three-point estimate (best case / expected / worst case) for each section. We sum the expected cases and add a buffer that scales with the variance — high-variance areas get bigger buffers because they’re the parts we don’t know yet.
We are honest about confidence. If we’re 50% confident in a section, we say so. The estimate that comes out the other end is closer to “what we’d be willing to commit to” than “what we hope this will take.”
Day five — the kickoff document
Day five is documentation and alignment. The artifacts that come out of the week are:
- The product description (Day 1).
- The risk register (Day 2).
- The architecture and dependency diagrams (Day 3).
- The spec and estimate (Day 4).
- A kickoff document that ties them together: scope, milestones, success criteria, who’s responsible for what, where decisions get logged.
We walk the founder through all of this on day five. Anything that doesn’t sit right gets resolved before the engagement begins. By the end of the day, both sides have signed off on the same document. Nobody is going to discover, in week three, that they were imagining a different product.
Why five days
The honest reason this takes five days and not two is that the second day’s adversarial pass needs the first day’s artifact to attack, and the third day’s architecture needs the second day’s risk list, and the fourth day’s spec needs the third day’s diagrams. You can compress this — we sometimes do — but every day you compress out, you reintroduce the problem of finding things out late.
We’ve also tried longer. Past five days, you stop discovering meaningfully new information; you start optimizing artifacts that the first week of the build will rewrite anyway. Five days is where the curve flattens.
What this lets you do
The most important thing it lets you do is say no. After a structured scope, you can look at a feature and confidently say, “this isn’t in scope, here’s what it would cost to add, here’s what it would push out.” Without that, every conversation about scope becomes a negotiation in which both sides are guessing.
The second thing it lets you do is start. The team that walks into Monday morning of week two with a spec, an estimate, an architecture, and an aligned founder builds different software than the team trying to figure all of that out while also writing code.
If you’re early on a product and want a week with us before committing to a full build, that’s a conversation we’d happily have.