How to Build a Feedback Board Without Code, Step by Step
To build a feedback board without code, describe what a submitted idea contains, how people vote on it, and the statuses you will move ideas through. An AI builder generates the board, you connect a database so posts and votes persist, and you publish it on your own domain.
A feedback board is a promise as much as a page. It says you will read this and respond, and a board with forty ignored posts damages trust more than having no board at all.
What is a feedback board for, exactly?
Three different jobs hide behind the same phrase, and mixing them produces a board nobody uses.
- Collecting ideas. Users write what they want. Volume is the point, quality varies.
- Ranking demand. Votes turn a pile of requests into an ordered list. This is the part that changes what you build next.
- Closing the loop. Statuses and replies tell people what happened. This is the part everyone skips and the only part that keeps users posting after the first month.
Decide which of the three you actually need. If you have twelve users, a shared document beats a board. If you have twelve hundred, ranking becomes genuinely useful, because the loudest request in your inbox and the most wanted feature are usually different things.
What data does a feedback board hold?
Four tables cover it, and naming them in the prompt is what separates a working board from a styled list.
- Posts. Title, description, author, created date, status, category or board, vote count.
- Votes. One row per user per post. This is what makes "one person, one vote" enforceable rather than decorative.
- Comments. Post, author, body, date, and a flag for official team replies so they stand out.
- Status history. Optional, but a status that changed on a date is far more useful than a status that just is.
Vote count should be derived from the votes table rather than stored as a number on the post. A stored counter drifts the first time two people vote at the same moment, and drift on your prioritisation data is quietly expensive.
What prompt gets a usable first build?
Name the statuses, the sort order, and who is allowed to do what. Those three decisions shape the whole interface.
A public feedback board for a product called Nimbus. Users sign in with email to post and vote. Each post has a title, a description, an author, a category from a fixed list of bug, feature, integration, docs, and a status from a fixed list of open, planned, in progress, shipped, declined. The main screen lists posts with a vote button showing the count, sortable by most votes, newest, and recently updated, with a filter by status and by category. Clicking a post opens a detail view with comments, where team replies are visually distinct. Admins can change status and pin a post. Include an empty state that explains what makes a good request.
The empty state is not decoration. The first ten posts set the tone for every post after them, and a line explaining that "one request per post, describe the problem rather than the solution" measurably improves what you get. The general structure of build prompts is covered in how to build an app with AI.
Should voting require a login?
This is the decision that determines whether your board produces signal or noise, and both answers are defensible.
| Approach | What you get | What you lose |
|---|---|---|
| Anonymous voting | Maximum participation, no barrier at all | Votes are unreliable, one person can vote fifty times |
| Email login to vote | Trustworthy counts, you can reply to voters | Some users leave rather than sign up |
| Login only to post, anyone can read | Good default for public boards | Still needs auth, so still needs a database |
| Internal board behind login | Honest team prioritisation | Not usable as a public trust signal |
For most products, requiring a login to vote and post while letting anyone read is the right balance. It needs real accounts, which means connecting Supabase for database and authentication rather than keeping data in the browser.
Test permissions properly once auth is in place. Sign in as a normal user and confirm the admin actions are actually blocked rather than merely hidden from the menu. Hidden and blocked are different things, and only one of them is a permission.
How do you handle duplicates and moderation?
Duplicates are the default state of any open board. Five people will request the same thing in five different words within a month, and if each sits at four votes, your ranking is wrong.
Merging is the fix, and it is worth asking for at build time: an admin action that closes one post, points it at another, and moves its votes over. Retrofitting a merge is more work than including it, because it touches the vote table rather than just the interface.
Moderation is smaller than people fear at small scale and unbounded at large scale. A public board with no login gets spam within days. A board that requires email login gets almost none. If you expect volume, ask for an admin review queue where new posts are held until approved, and accept that it slows the loop.
What does it cost, and where does it live?
A single-page board is a quick build at 6 credits on Zugo. A board with a detail page, an admin view and a roadmap view is a multi-page platform: 12 credits for the first three pages and 3 for each page after. Editing costs 3 credits, so the loop of refining copy and sort orders stays cheap.
Free gives 5 starter credits, Pro is $25 a month with 200 credits, and Business is $99 a month. Paid plans connect a custom domain, so the board can live at feedback.yourproduct.com instead of a builder subdomain, which matters for something you will link from inside your product for years.
Every build is booted in a sandbox before it reaches you, and a failure is reported as a failure rather than served as a broken page. That lowers the risk of publishing a board that will not load. It does not remove your own testing, and for a board the test that matters is voting twice from the same account and confirming the count does not move.
How do you keep the board from dying?
Boards die quietly. Posts arrive, nothing changes status, users conclude nobody reads it, and submissions stop within six weeks.
Two habits prevent it, and neither is technical. Move at least one post to a new status every week, even if the new status is "declined" with a one-line reason. And link shipped items to your changelog, so a user who voted twelve months ago sees the outcome. The mechanics of the other half of that loop are in building a product changelog page.
Email closes the loop properly. With the Resend connector the board can notify a voter when their request ships, which is the single highest-value notification a feedback tool sends.
When is a hosted feedback tool the better choice?
Honest limits, because parts of this category are genuinely specialist.
In-app widgets and unread badges. Hosted tools embed a button in your product and track who has seen what. That is their entire business and rebuilding it is not a good use of a weekend.
Single sign-on and enterprise controls. If your customers expect SAML and per-account visibility rules, you are in a different product category and should buy rather than build.
Spam at scale. A public board with real traffic attracts automated posting. Login requirements handle most of it, but a serious spam problem needs serious tooling.
Very specific business logic arrives through edits. Weighted votes by plan tier, or a private board per customer, are reachable with a sequence of refinements rather than one prompt. Zugo does not replace a development team on a complex product.
For a small team that wants a board on its own domain in an afternoon, building it yourself is the right call. If support tickets are the bigger problem, a helpdesk app is a closer fit.
Decide your statuses, decide whether voting needs a login, and build the first version at zugo.dev. Then post the first three requests yourself so nobody arrives at an empty page.