A feature request tracker should help you decide what to build next. It should not become a voting board where every request automatically turns into scope. Indie apps need feedback, but they also need protection from chasing every comment.
The useful middle ground keeps the original request, the app context, the user source, and the product decision together. That way requests become evidence, not noise.
Save the original wording
Start with what the user actually said. The original wording often reveals the real problem better than your summary. A request for an export button might really be a trust issue, a reporting need, or a sign that the app is not fitting an existing workflow.
Attach the request to one app
If you build multiple apps, feature requests need an app home. A generic feedback inbox gets confusing quickly. Attach the request to the exact app, prototype, launch, or public page it affects so you can review it with the rest of that product's evidence.
Track source and frequency
A feature request from one friend is useful, but it is different from the same request showing up in support emails, App Store reviews, beta calls, and launch replies. Track where requests come from and how often they repeat. Frequency helps you separate patterns from one-off preferences.
Tag the product job
Use simple tags such as onboarding, pricing, sharing, export, collaboration, bug, confusion, and nice-to-have. The tag is not the decision. It just makes review faster when several requests point at the same part of the product.
Make a decision state
Every request should eventually move into a decision state: considering, planned, shipped, declined, or needs more evidence. Declined is important. Without it, old requests stay mentally open and make the product feel more obligated than it is.
Connect requests to goals
The best requests support the goal of the app. If the current goal is activation, onboarding requests may matter more than advanced customization. If the goal is paid conversion, pricing and value clarity may matter more than polish. Goals keep feature triage aligned with the product stage.
A simple feature request template
- Original request
- App or feature affected
- Source
- Frequency
- Product job tag
- Decision state
- Related goal
- Follow-up notes
NextApp keeps feedback and goals attached to each app workspace, which makes feature-request triage easier for solo builders. You can keep the raw request, see repeated patterns, decide what matters, and share public progress only when a request turns into something shipped.