Almost every product we've built started the same way: a founder with a genuinely good idea, a clear sense of the problem, and very little structure around how that idea should actually work as software. That gap — between having an idea and having a usable product — is where most of the real work happens, and it's also where most ideas quietly stall.
An idea is not a specification
Founders usually know what the product should do in broad strokes. What's often missing is the layer underneath: how users move through it, what happens when something goes wrong, which parts need to feel instant and which can be a little slower, and what the system needs to remember about a user from one session to the next. None of that is exciting to think about, but all of it decides whether the finished product feels coherent or held together with tape.
The questions that matter before a single screen is built
- Who is the primary user, and what are they trying to get done in a single sitting?
- What is the one core workflow the entire product exists to support?
- What data does the system need to hold onto, and who is allowed to see or change it?
- What happens on the bad path — empty states, errors, edge cases — not just the happy path?
Why this stage can't be skipped
Skipping this thinking doesn't save time. It just moves the cost later, into rebuilds, confusing user experiences, and features that don't fit together because they were never designed against a shared structure. A product that's been thought through at this level is faster to build, easier to change later, and immediately feels more trustworthy to the people using it — because it behaves the way they expect it to, even in the moments they didn't think to ask about.
This is the part of product work we spend the most time on before writing any code: turning a good idea into a structure that a real product can be built on top of.