Note · 16 October 2026
Why every project starts with a one-page brief
Not a spec, not a contract. One page that says what we're building, for whom, and how we'll know it worked.
Most product projects don't fail at the end. They fail in the first week, quietly, when three people leave a kickoff call with three different products in their heads. Nobody notices until the designs come back and someone says "that's not what I meant".
So the first thing we make is not a wireframe. It's a page.
What's on it
- The problem, in the user's words. Not "users need better onboarding" but "I signed up and didn't know what to tap first".
- Who it's for, narrowly. One primary user. If we're building for everyone we're building for no one.
- What success looks like, as a number we can measure in the first week after launch. Activation, retention, time to value, whatever fits.
- The first scope: what's in version one and, more importantly, what's explicitly out.
- Open questions. The things we don't know yet, and how we'll find out.
What's not on it
Timelines, prices, tech stacks. Those come after, and they come easier, because by then they're answers to a question instead of guesses.
Why one page
Because a one-page document gets read. A forty-page spec gets signed. We want the brief to be the thing a founder forwards to a co-founder on their phone and gets a reply to in ten minutes. If it needs a meeting to explain, it's too long.
The brief changes. We expect it to. Every Discovery Sprint ends with a version two of the page, and most projects have a version five by launch. That's not scope creep. That's the product getting clearer. What we won't do is change it silently: every edit is visible, and the current version is always the one we're building against.
Who writes it
We do, together with you, in the first week. We draft, you correct, we argue about the success metric. You win if you have data; we win if you don't. By Friday it's on one page and everyone can quote it.
If you can't fit the product on a page, you don't have a product yet. You have a direction. That's fine. The brief is how we find out which one you have.
It's also the one artefact you keep even if we never work together again. We'd rather you leave with a clear page and go elsewhere than stay with a vague contract.
Fingersnap Labs
Written by the studio, from what we do every week. If something here doesn't match your experience, write to us. We'd rather update the note than defend it.
Your next product could be one snap away.
Tell us what you're building. We'll reply with how we'd approach it.