A public roadmap strategy for indie developers
Why exposing a public roadmap helps indie apps, the trap of over-promising, and a low-effort workflow you can sustain solo.
Big companies hide their roadmaps. Indie developers should probably do the opposite. A public roadmap turns your tiny team into something users can trust: they see what you're working on, what you've chosen not to do, and roughly when to expect things.
But a public roadmap can also become a trap — if you over-promise, every missed date erodes trust faster than no roadmap would. This guide is the middle path: visible enough to build trust, vague enough to survive reality.
Why expose a roadmap at all
For indie apps, the roadmap is mostly a marketing artifact. Power users want to know whether the niche feature they need is coming. Prospective customers want to know whether the app is actively maintained. Existing users want to know their feedback was received. A public roadmap answers all three in one place, and costs you almost nothing to maintain if structured well.
The four-status workflow that actually works
Three statuses is too few (no nuance), six is too many (you'll forget which is which). The sweet spot:
- open — submitted, not yet evaluated
- planned — you've committed to building this, but no date
- in_progress — actively being worked on
- done — shipped (link to App Store update or changelog entry)
What not to do: dates and commitments
Never put a date on a public roadmap item unless it's literally next week. Software ships late. Every public delay erodes credibility more than the original commitment built it.
Instead, batch communication. Once a month, push 2-5 items from 'planned' to 'in_progress', and ship 1-3 from 'in_progress' to 'done'. The visible activity creates trust without exposing your scheduling estimates.
Handling private features and competitive surprises
Not everything belongs on the public roadmap. Big competitive launches, paid-tier features still being scoped, anything where leaking the work harms the launch — keep those internal. The public roadmap is for community-requested items and obvious incremental improvements.
A practical heuristic: if a feature has at least 3 votes on your feedback board, it's safe to expose publicly. If you're building it yourself with no demand signal, it's probably the kind of thing better left as a surprise.
Communicating delays without losing trust
Sometimes a 'planned' item sits for 6 months. That's fine, as long as you don't pretend it doesn't. When it's clear something won't ship soon:
- Add a short comment on the feedback item explaining the blocker (no commitment to a new date)
- Move it back to 'open' if priorities have shifted — better than leaving it as fake 'planned'
- If you've decided not to build it, mark as 'closed' and explain why
How Verbr supports this workflow
Each Verbr project comes with the four-status workflow built in, a public feedback page that shows each item's status, and automatic email notifications when items move between statuses. The vote count on each item gives you (and your users) a clear signal of which items are worth committing to.
FAQ
How often should I update the public roadmap?
Once a month is plenty for an indie app. Batch the status moves into a single 'monthly update' that you can also share on social channels — it doubles as a small marketing moment.
Should I commit to delivery dates publicly?
No. Dates are for internal planning. Public roadmap should show direction, not timelines. The only exception is the very next release ('shipping next week').
What if a competitor copies what's on my roadmap?
For most indie apps, competitor risk from a public roadmap is theoretical. The features that win are rarely the ones easy to copy from a list — they're the ones executed well. If a specific item is genuinely sensitive, keep it private until launch.
How do I handle features I'll never build?
Mark them 'closed' (not 'open'), and add a one-line comment explaining why ('out of scope', 'tried, didn't work', 'conflicts with privacy'). Honest closure is better than leaving things forever 'open'.