Here's a pattern I've watched repeat itself in conversations with solo developers: a person has a clear idea, gets excited, opens their editor, and starts building. Six months later, they've shipped nothing. The codebase has grown. The scope has doubled. The original idea (the thing that was actually worth building) sits buried under seventeen features nobody asked for.
The vision was real. A roadmap never existed.
A product roadmap isn't a PM artifact for weekly standups. For a solo developer, it's simpler and more necessary. It's your written answer to three questions before you write a line of code. What am I building? In what order? And what am I not building in v1?
What a product roadmap actually is (and what it isn't)
Ask any product management tool and you'll get the same definition. ProductPlan, which holds the featured snippet for this query, calls it "a high-level visual summary that maps out the vision and direction of your product offering over time." Atlassian frames it as a way to "communicate and align your product strategy with stakeholders."
That framing is correct. For a team. It assumes you have a PM, stakeholders to align, and meetings to run. None of that applies to a developer building alone.
When there's nobody to communicate to, a roadmap's job shifts. It holds you accountable to decisions you made when you were sober, so you don't override them at 11pm when you're tired and convinced that "just adding this one feature" is a good idea.
A solo dev roadmap is not a Gantt chart (you don't have resources to schedule), a feature wishlist (wishlists have no scope boundary), a presentation for investors, or a sprint board (that's for execution, not planning).
What it is. A one-page written commitment to what you're building, in what order, and, this is the part nobody talks about, what you are not building until v1 ships.
Why "I'll figure it out as I go" is the most expensive development decision
Scope creep doesn't start after you write code. It starts the moment you sit down without a locked plan.
Without a written roadmap, every feature decision happens in real time, usually mid-build, when you're excited and not thinking clearly about tradeoffs. "This will only take 20 minutes" is a lie developers tell themselves roughly eight times per project. Those 20-minute additions stack. Three months in, you're maintaining a product nobody has seen that does twelve things passably instead of three things well.
A roadmap moves those decisions earlier. You think through scope once, before any code exists. Then you lock it. The roadmap isn't a constraint. It's a forcing function that converts vague ambition into a specific, shippable thing.
This matters even more if you're using agentic coding tools. Cursor, Claude Code, and Windsurf can build features in minutes that used to take hours, which means scope creep runs at machine speed if you haven't decided what you're building before you open a terminal.
The 4-layer solo dev product roadmap
A solo developer's roadmap has four layers. Fill them in this order. Each layer depends on the previous one.
Layer 1: The Problem
Who has this problem? How painful is it? Would they pay to have it solved?
Write down a specific person you know (or have talked to) who has this problem. If you can't name one, your roadmap doesn't have a foundation yet. The FoundStep idea validation checklist runs through this in about 20 minutes.
Layer 2: The Solution
What are you building to solve it? One sentence. Not a paragraph, not a feature list. One sentence that a stranger could understand. "A habit tracker for runners that sends daily SMS reminders" is a solution. "A comprehensive wellness platform" is not.
If you can't summarize your solution in one sentence, your scope isn't defined yet.
Layer 3: The MVP Features
Three to five features, named and bounded, in priority order. Not "user authentication" (too vague) but "email/password signup with JWT, no OAuth in v1." Not "analytics dashboard" but "total completions per day, no charts, just numbers."
If it's not on the list, it doesn't exist in this sprint. Three features that ship beat twelve features that sit in a half-finished branch.
Layer 4: The Not-List
Every feature you thought of and decided to cut goes here. This is the most important layer, and the one nobody talks about.
The not-list (the layer everyone skips)
The not-list is a written inventory of features you thought about and decided to cut before v1.
Most roadmap advice focuses on what to build. The not-list handles the harder problem. What to ban yourself from building until you've shipped. Without it, "I'll add that in v2" is a good intention that never survives contact with a half-finished codebase.
It moves scope decisions earlier. You fight the "just one more feature" urge during planning, when you're thinking clearly, not at midnight mid-sprint. And it hands you a v2 backlog automatically. Every feature on the not-list is already written down, already considered. You don't reconstruct your post-launch ideas from memory.
It also protects your scope when you're building fast. If "no analytics dashboard" is on the not-list, the answer to "should we add analytics?" is already decided. You don't revisit it under pressure.
How to prioritize your roadmap features
Three questions rank any feature candidate quickly.
What breaks if you skip it? Features that break the core loop go first. For an SMS habit tracker, you can't skip the reminder. It's the product. You can skip the streak counter and still have something shippable. Cut anything you can cut and still have a working MVP.
What's the honest effort vs. impact tradeoff? Low effort, high impact goes early. High effort, low impact goes on the not-list. Don't let technically satisfying builds jump the queue just because they're fun to write.
Does this depend on something else? Build in dependency order. If feature C requires feature A's data model, A goes first regardless of priority. Ignoring dependencies creates rework.
Rank your 5 to 8 candidates by these questions and you'll land on a solid Layer 3 in under an hour.
What a filled-in roadmap actually looks like
Here's a complete 4-layer roadmap for a simple app.
The scenario. A developer wants to help beginner runners stay consistent.
Layer 1 (Problem): Beginner runners quit within the first six weeks because they forget to train and lose their streak. It's a real pain. They start, get inconsistent, feel guilty, and stop entirely.
Layer 2 (Solution): A daily SMS reminder that a runner replies to with a single word ("done") to log their run. No app required.
Layer 3 (MVP Features, in order):
- SMS reminder at a fixed time (7am)
- Reply "done" to log completion, no login required
- Streak counter tracked by phone number
Layer 4 (Not-List):
- Native app (build web-first, port later if users ask)
- Customizable reminder times (fixed 7am is enough to test if people engage)
- Social features or friend challenges (v2 if engagement data justifies it)
- Progress charts and graphs (a number proves the concept without the build)
- Third-party integrations (Apple Health, Strava) (scope risk with no usage data)
The entire roadmap fits in a text file. It took about 30 minutes to write. Every decision in it is written down, reasoned, and locked before any code gets written. That's the point.
Frequently asked questions
What is a product roadmap?
A product roadmap is a plan that defines what you're building, in what order, and, for solo developers especially, what you're not building yet. Most definitions frame it as a "stakeholder communication tool," but for a person building alone, the stakeholder is you. The roadmap's job is to hold you to scope decisions you made when you were thinking clearly.
How do I create a product roadmap?
Fill in four layers in this order: the problem you're solving and who has it; your solution in one sentence; 3 to 5 MVP features by name with scope boundaries; and the not-list, the features you've cut from v1. The whole thing should fit on one page.
What comes first, strategy or roadmap?
Strategy comes first. The problem (Layer 1) and solution (Layer 2) are your strategy. The features (Layer 3) and not-list (Layer 4) are your roadmap. A roadmap without a strategy is just a feature wishlist. The FoundStep validation checklist covers the strategy layer before you plan features.
What is the best tool to create a product roadmap for solo developers?
Most roadmap tools (Jira, ProductPlan, Productboard) are designed for teams. They assume multiple users, sprint ceremonies, and stakeholder views. For a solo developer, you need something that handles validation, feature planning, and scope locking in one place. FoundStep's planning workflow was built for this. Validate the idea, plan the MVP features, lock the scope, and build from a specific plan rather than a vague vision.
Can ChatGPT create a roadmap?
It can draft one in under a minute, which is useful for getting ideas out of your head and into a document. What it can't do is hold you accountable to the roadmap once you close the chat. Scope discipline isn't a drafting problem. It's a commitment problem. A roadmap that lives in a chat conversation doesn't lock your scope. It gives you something to ignore when the next exciting feature idea shows up.
Build your roadmap before you build your product
The most common mistake in solo development isn't bad code. It's starting to write code before knowing what you're building, and more importantly, what you're not building.
A roadmap doesn't need Jira or a presentation template. It needs to answer four questions honestly, in writing, before you open your editor. What's the problem? What's the solution? What are the 3 to 5 things that ship in v1? And what's off the table until v1 ships?
That last question is worth sitting with longest.
Start your MVP plan in FoundStep →
Or start with the free idea validation checklist, which covers Layer 1 and 2 of your roadmap in about 20 minutes.
