The Messy Middle — What to Do Between 'I Have an Idea' and 'I Have an MVP'

There is a phase in the early life of every startup that nobody has named properly. It exists between "I have an idea" and "I have something real to show people" — and it is the most disorienting stretch of the entire journey. There is no shortage of advice for the idea stage. There is no shortage of advice for the build stage. The phase in between — call it the messy middle — gets almost nothing.

The messy middle is where most solo founders stall. Not because they lack motivation or intelligence, but because they don't have a clear map of what they're actually trying to do. They oscillate between refining the idea and talking to people and starting to build and going back to the idea. Time passes. Progress feels illusory. The product never quite reaches the point where it can be tested with real users.

The messy middle has a start and an end. It starts when you have an idea worth taking seriously — something specific enough to articulate, grounded enough in a real problem that you can describe who suffers from it. It ends when you have a working prototype in the hands of real users. Everything in between is the work. Here is a six-step sequence that moves you through it.

Step one: build an assumption map. Before you do anything else, write down every assumption your idea depends on. Not just the obvious ones — the market assumption, the willingness-to-pay assumption — but the subtle ones: that your target user has the problem on a regular basis, that they're not already solving it adequately with an existing tool, that they can be reached through channels you have access to, that the problem is painful enough to change their behaviour. Write them all down. Rank them by how catastrophic it would be if they turned out to be false.

Step two: have customer conversations designed to test your highest-risk assumptions. This is not generic customer discovery. Each conversation should have a specific hypothesis you are trying to test. If your highest-risk assumption is that the problem occurs frequently enough to justify a subscription, your questions should be designed to uncover how often and how intensely people experience the problem. You are looking for falsification, not confirmation.

Step three: synthesise what you heard and update your assumption map. After ten to fifteen conversations, read back through your notes. Look for patterns — the language people use to describe the problem, the workarounds they've invented, the things they said they'd pay for and the things they qualified. Update your assumption map. Some assumptions will be confirmed. Some will be weakened. Some will be replaced by better ones. This output — a refined, evidence-adjusted assumption map — is the foundation of everything that follows.

Step four: define the signal you need. Before you build anything, decide what evidence would justify building. This is a specific, falsifiable threshold: if X people pre-pay, or if Y percent of my target users sign up for a waitlist within Z weeks, I will proceed. Write it down. If you can't specify the signal in advance, you'll move the goalposts when the results are ambiguous.

Step five: build the smallest thing that lets you collect that signal. This might be a landing page with a value proposition and a signup button. It might be a manual process you operate by hand while presenting it as a product. It might be a prototype built in a no-code tool that demonstrates the experience without the full infrastructure. The goal is not to build the product — it is to test whether demand exists for the product.

Step six: ship it to a small, targeted audience and observe behaviour — not opinion, not enthusiasm, but behaviour. Did people click? Did they sign up? Did they pay? Did they come back? Did they tell other people? Behaviour is the only signal that cannot be faked by politeness or encouragement. Once you have behaviour data, you have something real to build from.

The six steps sound linear because they are — sequence matters here. The most common mistake in the messy middle is skipping ahead. Building before you've tested assumptions means optimising for the wrong thing. Collecting demand signals before you've refined the problem statement means measuring interest in the wrong idea. Each step produces inputs that make the next step more effective.

The other thing that helps is treating each step as a defined output, not a process. You are not "doing customer discovery" — you are producing an updated assumption map with evidence notes attached. You are not "building a prototype" — you are producing a specific testable signal. The shift from process to output is subtle but significant. It creates clarity about when you're done with each step and ready to move forward.

Kooio was built specifically to guide founders through the messy middle. The five stages of the platform — ideate, validate, design, build, launch — map onto this sequence. The value is not just in the steps themselves but in having a structured partner who helps you stay honest about which step you're actually in, which assumptions are still untested, and what the next concrete action is. The messy middle is not supposed to be comfortable. It is supposed to be productive. The difference is a clear map.