Turning a Rough Idea Into a Working Product Roadmap
How an idea gets scoped into something buildable, in stages — the process behind every Mogana.dev project.
Article illustration — 1600×700px
Every project that reaches this site started the same way: a sentence, not a plan. “I want a website for my business.” “Can we automate this with AI?” The gap between that sentence and a working product is where most ideas quietly die — not because they were bad, but because nobody turned them into something buildable.
The idea is not the plan
An idea is a direction. A roadmap is a sequence of decisions small enough to actually make. Confusing the two is the most common reason projects stall before a single line of code gets written — the idea feels too big to start, so it doesn’t start.
The fix isn’t motivation. It’s decomposition. Every roadmap on this site follows the same four questions, asked in order, before any design or code happens.
The four questions that turn an idea into a roadmap
- Who is this for, specifically? Not “businesses” — a named type of business, doing a named task, right now, badly or manually.
- What is the smallest version that would actually be useful to that person, on its own, with nothing else built yet?
- What has to be true for that smallest version to work — technically, legally, operationally?
- What order do those things need to happen in, given what depends on what?
The scoping test
If you can’t describe the first working version in one sentence that includes a specific user and a specific action, the idea hasn’t been scoped yet — it’s still a direction.
Why this matters more than the tech stack
Founders and teams often ask about frameworks first — Next.js or something else, Supabase or a custom backend. Those are real decisions, but they’re downstream. A well-scoped idea can survive a mediocre tech choice. A poorly-scoped idea fails regardless of how good the stack is, because nobody agreed on what “done” means for version one.
What a Mogana.dev roadmap actually looks like
| Stage | Output | Typical length |
|---|---|---|
| Scoping | One-sentence version-one definition | 1–2 days |
| Structure | Page/feature map, no visuals yet | 2–3 days |
| Design | Core screens, brand direction | 1–2 weeks |
| Build | Working version one, deployed | 2–6 weeks |
| Launch | Live, monitored, ready for real users | Ongoing |
The takeaway
A roadmap isn’t a document that predicts the future. It’s a small, honest agreement about what gets built first — and why that thing, before anything else. Everything on the case studies section of this site started as exactly that: a rough idea, run through these four questions, before anything got designed or coded.
Have a topic you’d like covered?