Upvote Template: A Public Roadmap and Voting Board

Upvote template: a feature voting board you can put in front of users

Upvote is a ready-made public roadmap from the Zugo gallery. Visitors read the request list, vote on what they want, and submit ideas of their own, while a member area shows what someone has posted and backed. Ideas and votes are kept in the browser, so they survive a reload. Cloning it costs no credits.

Below is what the template contains, which parts hold up under real use, and the honest boundary you have to cross before a board like this can collect feedback from more than one person.

What is inside the Upvote template?

The template is built around a single list and three ways to interact with it: vote, filter, add. That restraint is the point. Feedback boards die from feature creep faster than from neglect, and this one refuses most of the extras.

Four statuses carry the whole workflow: Under review, Planned, In progress, Shipped. That is enough for a small team and short enough that a visitor understands the pipeline without a legend.

The submission form does one thing that matters more than any feature: it asks for the problem rather than the solution, in the helper text under the field. Boards fill with solutions by default, and solutions are much harder to prioritise than the complaints behind them.

The member dashboard is a small piece of retention design. Showing someone that their idea collected votes this week is what brings them back, and it costs nothing to display.

What works for real, and what is a demonstration?

The board is genuinely functional. Voting toggles and the count moves, the list re-sorts, filters narrow it, and a new idea appears at the top with your vote on it. All of that runs on real state, not on painted cards, and you can prove it in a minute in the preview.

State is kept in your browser, so a submitted idea survives a page reload on that device. That is more than most demo boards manage, and it makes the template genuinely useful for a solo exercise: draft a roadmap, reorder it, show it to a colleague over a screen share.

But the browser is the operative word. The data lives in the browser it was entered in, and someone opening the same link on their laptop sees the original list. The sign-in screen shows a sign-in screen; no password is checked and no accounts are separated.

For a public board that limit is fundamental and no interface edit gets around it. The whole value of collecting feedback is that different people vote, and without shared storage their votes never add up. Real storage and real identity come from the Supabase connector, added on top of the template.

Check this before you send the link out. Open your published project in another browser and confirm it is empty there. Five minutes of testing avoids the awkward moment when the whole team voted and nothing was recorded. The collaboration side of that question is covered in can I collaborate.

Who needs a public roadmap like this?

It fits a small software product with users who care: a SaaS tool, a plugin, an app with a community. Once you have more requests than memory can hold, a public list is cheaper than a triage meeting, and it answers the question users keep asking, which is whether anyone read their message.

It also works internally. An IT team, an ops team or a school can use exactly this frame for internal requests, where the audience is a hundred colleagues rather than the open internet. In that setting the browser-only limit still bites, but the fix is the same.

It is the wrong tool for support tickets. A board is for the things many people want, and a ticket is for one person's broken thing. Mixing them produces a board where a single urgent complaint outvotes a genuinely popular request.

It is also the wrong tool when you have no intention of shipping any of it. A public roadmap that has not changed in six months does more damage than no roadmap, because it is visible proof that nobody is listening.

Should voting require a sign-in?

Open voting collects more votes and worse data. Anyone can vote, nobody has to commit anything, and any anti-fraud check can be bypassed by clearing browser data. That is not a template flaw, it is what open voting means.

Requiring sign-in collects fewer votes and better data. You know who wants what, you can come back to them when it ships, and duplicate voting becomes hard rather than trivial. The cost is friction at the exact moment someone is willing to help you.

The usual answer for a small product is to let people read and vote freely, and to require an email only when they submit a new idea. That keeps the barrier at the point where you actually need to reply to someone.

Whichever you pick, it is a database decision, not a design one. Both versions need real accounts behind them to mean anything, which brings you back to the connector rather than to a chat edit.

How do you turn it into your product's board?

Content first, mechanics second. Each edit costs 3 credits, so the order below runs from the changes that make it yours to the ones that make it operational.

1. Replace the product name and the framing. Header, page title, footer contact address.
2. Rewrite the categories. The six demo ones are generic. Yours should match how your team already talks about the product.
3. Load the real requests. Ten to fifteen genuine items beat an empty board, which nobody adds to.
4. Adjust the statuses. Add one for Declined if you intend to say no in public, which is worth doing.
5. Connect storage and sign-in. This is the step that turns a demonstration into a board.
6. Publish and link it. The project lives at an address like roadmap.zugo.run, with your own domain on top.

The Declined status deserves a moment. Saying no in public is uncomfortable and it is the single strongest signal that the board is real. A list where nothing is ever rejected reads as decoration within a month.

What does it cost to reach a working board?

The clone is free and calls no AI, so the count starts with the first edit. Reaching a board you would show to customers usually takes five to eight edits, plus connector work that costs no credits.

Free gives you 5 credits, which covers the clone and one edit but not a build from scratch at 6. Pro is $25 a month for 200 credits, about 66 edits, and Business is $99 a month for 800 credits. Each build is opened in a sandbox first, so a version that fails to load is never handed over.

If the roadmap needs to live alongside a changelog page and a submission guide at their own addresses, that is a multi-page platform: 12 credits for the first three pages and 3 for each after. A simple build takes about a minute, and a multi-page one takes a few.

Which edits do people ask for most?

"Add a Declined status with a required reason field shown on the card." "Let people comment on an idea, and show the comment count on the card." "Group the board by category with collapsible sections instead of one long list."

Anti-gaming requests are frequent, and the honest answer matters: without accounts and shared storage, any check can be defeated by clearing browser data. Serious protection starts with real identity, not with an interface tweak.

Presentation requests are cheap and worth it: "show the top three requests as a highlighted row above the board" or "on mobile, put the vote button on the right of the card so it stays reachable with a thumb."

Where does the template stop?

One browser is not a public board. Without shared storage every visitor sees their own list, and votes never accumulate. Supabase removes the limit, and that is a stage of work rather than one message in chat.

Moderation is a human job. Duplicate ideas, off-topic posts and the occasional angry paragraph all need a person. The template can hide, merge or reorder items once you build those controls, but it cannot decide what deserves to stay.

Deep workflow logic arrives through edits. Linking a board item to an issue tracker, notifying everyone who voted when something ships, weighting votes by customer size: all reachable, none of them in a single prompt. On a genuinely complex product Zugo does not replace a development team, and the source is exportable to GitHub whenever you want it. The general version of this project is walked through in how to build a feedback board with AI.

The quickest way to judge the frame is to load your own backlog into it. Open the gallery at zugo.dev, clone Upvote, and paste in the ten requests you already know about. Seeing them sorted by votes tends to change which one you plan next.