Your idea needs enough detail that someone else could understand who it helps, the problem, and what a user does, roughly a clear page. You do not need every screen or feature decided; over-specifying early locks you in before you have learned anything. Aim for enough clarity to start and price, and leave room to adjust as you learn.
Information current as at 5 July 2026
People stall at two opposite extremes. Some wait, refusing to start until every detail is nailed down, and never begin. Others leap with a one-line idea and no thought, and stumble immediately. The right level of detail sits between them, and knowing where it is frees you to start with confidence rather than either paralysis or recklessness.
At one extreme is the person who will not start until the idea is perfect: every feature designed, every screen drawn, every edge case answered. They research and refine for months and never build, because there is always one more thing to decide. At the other is the person who starts with a single sentence and no thought about who it is for or what it must do, then stalls the moment a real decision arises. Both fail for the same underlying reason: they misjudged how much detail the start actually needs. The goal is not maximum detail or minimum detail, but the right amount.
A small set of things really does need to be decided up front, because everything else depends on them. Who exactly it is for. The specific problem it solves, in their words. The core action, the one thing a user does that is the whole point. And a rough sense of the must-haves versus the extras. If these four are clear, you have enough to describe the idea, price a first build, and begin. They are the load-bearing decisions, and being vague about them makes everything downstream vague too. Get these right and the rest can be figured out as you go.
If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.
A great deal can, and should, stay undecided at the start, because deciding it early is often deciding it wrong. Exactly how each screen looks. Every feature you might one day add. How you will handle unusual cases you have not yet seen happen. The precise workflow before real users have shown you how they behave. Nailing these down before you have learned anything is over-specification, and it wastes effort on choices reality will overturn. Leaving them open is not sloppiness; it is keeping room to respond to what you learn, which is the whole point of starting small.
It feels responsible to plan everything in advance, but detailed plans made before any real contact with users are built on guesses, and guesses harden into commitments once written down in detail. You become attached to the specified version, reluctant to change it because you spent so long specifying it, and slower to adapt when users reveal something you did not expect. A lighter plan, clear on the load-bearing decisions and open on the rest, actually gets you to real learning faster and keeps you nimble when that learning arrives. The right detail helps you start; too much of it quietly stops you adjusting. There is also a simple cost point: time spent specifying screens you may never build is time not spent getting a real version in front of real people, which is where the useful detail actually comes from. Plan the load-bearing parts, then let the rest be answered by contact with reality rather than by more planning.
If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.
Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.