Product · App Starter
A feature-request board with voting, a public roadmap, and a changelog — generated as an app your team owns.
Feedback scatters across support threads, sales calls, and DMs, and the loudest request wins by default. This starter generates the whole loop — boards where users vote, a roadmap that shows what you heard, a changelog that closes it — as a full-stack app in your repository, wired to your product's vocabulary.
01 · Data model
Six tables carry the entire feedback loop, from first upvote to shipped announcement. Every screen below is a view over them, and the schema is yours to bend — add a revenue-weight column to votes, a customer-tier field to requests, whatever your prioritization actually uses.
| table | what it holds |
|---|---|
boards | Named collections of requests — feature ideas, integrations, bugs — each public or private with its own posting rules. |
feature_requests | The core record: title, description, status, vote count, board, and a merged-into pointer for duplicates. |
votes | One per user per request, so counts stay honest — and extendable with weights if a $50k account should outvote a free trial. |
comments | Threaded discussion under each request, with an internal-note flag so the team can deliberate where users can't see. |
roadmap_items | Planned, in-progress, and shipped columns, each item linking the requests it resolves so status flows back to voters. |
changelog_entries | Shipped announcements tied to the requests they close — the record that tells users their vote did something. |
02 · Screens
Users browse open requests, vote once each, and post new ideas that land in a moderation queue. Sorting by votes, recency, or status is a query parameter, and private boards let you run a separate lane for enterprise customers or internal teams.
Five phrasings of the same ask fragment your signal. Merging redirects a duplicate into its canonical request, carries the votes and voters across, and leaves a pointer so old links still resolve — the count you prioritize on becomes the real count.
A three-column public roadmap — planned, in progress, shipped — driven by roadmap items rather than by hand-edited pages. Moving an item updates the status shown on every linked request, so users see progress without asking support.
Publishing a changelog entry marks its linked requests shipped and surfaces the announcement to everyone who voted. Closing the loop is the difference between a feedback portal users trust and one they abandon after the first ignored idea.
03 · Process
Tell Dual7 what you collect and from whom — public ideas, private enterprise asks, bug reports — and how you decide what ships. The starter supplies boards, voting, and the roadmap shape around your answers.
Iterate conversationally on the working app: add a customer-tier field to requests, weight votes by plan, rename statuses to match how your team already talks. Each edit is a change to code you can read.
Push it live through approval gates with an audit trail, onto your infrastructure. Your users' feedback sits in your database from the first vote.
04 · Fit
When requests live in a support tool, a sales channel, and someone's memory, prioritization becomes anecdote versus anecdote. One board with honest vote counts and merged duplicates turns the Monday planning debate into a sorted list.
Feedback tools often price on the number of people who vote — meaning your bill grows precisely when the portal works. Owning the app removes that ceiling: a thousand new voters is load, not an invoice.
Big accounts want to know their asks are heard without broadcasting their roadmap needs to your public board. Private boards per account, with the same voting and status machinery, come from the same six tables.
A visible roadmap and changelog signal that the product is alive — often before there's a team to maintain them. Generated screens that update themselves from request statuses keep that signal honest at zero ongoing effort.
05 · Yours
The prioritization logic is where feedback tools go rigid and this starter doesn't. Add a monthly-revenue column to votes and sort boards by dollars instead of raw counts. Add an effort estimate to requests and chart value against cost. Tag requests by product area and give each squad a filtered view of its own backlog — these are schema edits in Vibe mode, not plan upgrades.
Integration points are ordinary code: pipe new requests in from your support inbox, post changelog entries to your announcement channel, or sync shipped items to your issue tracker. The generated app is a standard full-stack codebase with no runtime dependency on Dual7, so your team can extend it the same way they extend anything else they own.
Hosted feedback portals hold a strange asset hostage: your users' own words about your product. Export formats lose vote attribution, merge history, and private notes — the parts that made the data useful. Generating the portal as source code means the requests, votes, and decisions accumulate in your database, queryable alongside the rest of your product data forever.
What you take on in exchange is running a small app, and the governed pipeline exists to make that boring: gated deploys, an audit trail of changes, and regeneration when you want to restructure rather than hand-patch. For most teams the portal is low-traffic and low-risk — the easiest possible first app to own.
A working feedback app in a codebase you own: six entities (boards, feature_requests, votes, comments, roadmap_items, changelog_entries), a public voting board, duplicate merging, a three-column roadmap, and a changelog that notifies voters when linked requests ship.
Yes — visibility is a property of each board. A common setup is one public ideas board, a private board per enterprise account, and an internal board for team proposals, all sharing the same voting and status machinery.
Merging points a duplicate request at its canonical twin and moves the votes and voters over, deduplicating people who voted on both. The duplicate keeps resolving as a redirect, so links in old emails and tickets don't break.
Out of the box a vote is one user, one count. Because the schema is yours, adding a weight — plan tier, contract value, segment — is a column and a sort change, done conversationally in Vibe mode. That single edit is out of reach in most hosted portals.
The starter authenticates voters so counts stay one-per-person; anonymous browsing of public boards works without signing in. If you want lighter friction — email-verified voting, or SSO against your product's existing users — both are edits to auth code you control.
A spreadsheet records feedback; it doesn't collect it. The board lets users vote and comment directly, deduplicates the signal, and reports status back automatically — the parts a spreadsheet makes you do by hand, forever.
Dual7 App Starters
A feature-request board with voting, a public roadmap, and a changelog — generated as an app your team owns. Describe your version to start — the output is a project you own.