Feedback board software

A feedback board your users read and your agent builds from

A feedback board is a shared page where users post feature requests, vote on them, and see what ships. FeatQ hosts one for you at a flat price, with an MCP server so your coding agent can build from it.

On this page

What is a feedback board?

A feedback board is a shared page where users post feature requests, vote on them, and see what ships. It is one list, visible to the people who asked and to the team deciding what to build, instead of the same idea sitting in four inboxes in four different wordings.

The board does three jobs at once. It is an intake channel, so a user with a request has an obvious place to put it. It is a measurement, because votes show whether one message represents one person or two hundred. And it is a reply, because a status on each request tells the people who voted what happened next.

Feedback boards are also called feature request boards, idea boards, or public suggestion boards. The names differ, the shape does not: submit, vote, status, changelog. Teams sometimes run one board for the whole product and sometimes one per major area. Either works as long as users can find the right one without guessing.

What a feedback board is not: a support queue, a survey, or an automatic roadmap. Support tickets are meant to close. Surveys ask fixed questions during a fixed window. And a vote count is evidence, not a decision. The team still weighs strategy, effort, and risk before anything moves.

What a feedback board needs to be useful

Most boards fail the same way. Requests arrive, nothing visibly happens, users stop posting, and the board becomes a list of four-year-old items nobody reads. Four things keep that from happening.

A low bar to participate

If voting needs an account, most users will not vote. The signal you collect is then a measure of who tolerated the signup, not of what people want.

Statuses that mean something

A short, honest set of stages. Users can accept "not planned" far more easily than silence, and a status is cheaper to publish than a promise.

A visible ending

When something ships, the people who voted for it should hear about it. That single email is what turns a board into a loop rather than a suggestion box.

Pricing that does not punish growth

A board gets better as more users join it. If each participant adds cost, the rational move is to invite fewer of them, which defeats the purpose.

We measured the failure case rather than guessing at it: our audit of 29 public feedback boards found the median top-voted open request had been sitting there for 4.4 years.

How the FeatQ feedback board works

Create the board, share its address, and it is collecting. There is no sales call and no implementation project before a user can post something.

Voting by email. Users submit and vote with an email address. No account, no password, no profile to complete. Owners who want stronger identity can switch on a 6-digit email verification code, and a private board can be limited to approved emails and domains.

Statuses and roadmap. Each request carries one of five statuses: New, Considering, Planned, In Progress, or Done. Planned and active work appears on the board roadmap automatically, so there is no second artifact to keep in sync. The public roadmap tool guide covers how teams present that view.

Changelog on ship. Marking a request Done publishes it to the board changelog and queues notifications to the people who voted for it. That is the step most boards skip, and it is the reason users come back to the next request.

Widget. The embeddable widget puts the same submission and voting path inside your product, so users do not have to leave to file something. Both routes write to the same records. A widget that creates a second inbox has only moved the problem.

API and MCP. Every plan includes the v1 REST API and a first-party MCP server. More on that below.

The part that is different: your agent reads the board

Every FeatQ board is also an MCP server, on every plan. It speaks standard streamable HTTP at /api/mcp and authenticates with a board-scoped bearer key, so Claude Code, Codex CLI, Cursor, and any other MCP client can connect to the same board your users vote on.

Six tools cover the loop: list_requests, get_ranked_requests, get_request, generate_spec, update_request_status, and get_board_stats. In practice the agent asks what is most wanted, reads the original context behind it, drafts an implementation spec, and writes the status back when the work lands. When it sets a request to Done, the changelog publishes and the voters get their email.

This is not the agent deciding your roadmap. Ranking is evidence, and a human still picks the work. What it removes is the copy-and-paste step between the board and the editor. Full setup is in the MCP documentation, and which feedback tools have MCP servers covers how other vendors handle it. FeatQ is not the only feedback tool with an MCP server. It is one of the few that includes it on the entry plan.

Public versus private feedback boards

A public feedback board is open to anyone with the link. Requests, vote counts, and statuses are all visible. That openness is doing real work: a user can check whether their idea already exists before writing it again, quiet users can add a vote instead of composing a message, and prospects can see that the product is actively maintained.

A private board restricts participation to approved emails and domains. The usual reasons are commercial rather than technical. Requests can name customers, describe contract commitments, or reveal work you have not announced. Some teams also run a private board for a beta cohort while keeping a public one for everyone else.

The honest tradeoff: public boards collect more input and give you a page search engines and AI assistants can read, but you are publishing your backlog and your response times. Private boards keep control and lose reach. FeatQ supports both, and the setting can be changed later, so this is not a decision you have to get right before you start.

Pricing, limits, and what FeatQ does not do

FeatQ is $29 per month or $228 per year. The first 25 customers can lock in $19 per month or $144 per year, and a one-time $199 Lifetime option is open while its 50 seats last. Every option includes the board, voting, roadmap, changelog, widget, API, and MCP. Nothing in the core loop sits behind a higher tier.

Each board supports up to 10,000 voters, and there are no per-user, per-seat, or per-tracked-user fees. The bill is the same at 10 voters or 10,000, which is the point: inviting more users should improve the signal, not the invoice.

What FeatQ does not have, stated plainly: no free tier, no SSO or SAML, no one-click importer from another tool, and no custom domain for boards. If a permanent $0 plan or enterprise identity controls are hard requirements, other tools on our compare pages fit better, and we say so there. Every purchase carries a 14-day money-back guarantee.

Share this page

Frequently asked questions

Practical answers about agents, voting, embeds, and pricing.

A feedback board is a shared page where users post feature requests, vote on the ones they want, and see what the team is building. It replaces scattered feedback in email, chat, and support tickets with one public record that both sides can read. A useful board covers the whole loop: submission, voting, a visible status on each request, and a changelog of what shipped.

A feedback board is the input. It holds every request users have asked for, ranked by how many people want it. A roadmap is the output: the subset the team has decided to build, arranged by stage. On FeatQ they are two views of the same records, so moving a request to Planned or In Progress puts it on the roadmap without any separate update.

On FeatQ, no. Voting and submitting work with an email address only, so there is no signup step between a user and their vote. Board owners can require a 6-digit email verification code if they want stronger identity, and a private board can restrict participation to approved emails and domains. None of those options creates a user account.

Public boards work when you want the request list itself to be a signal: users can see they are not the only ones asking, and the board is indexable and linkable. Private boards work when the requests reveal customer names, contract details, or unannounced plans. FeatQ supports both, and the setting can be changed later without recreating the board.

FeatQ is $29 per month, or $228 per year. The first 25 customers can lock in $19 per month or $144 per year, and a one-time $199 Lifetime option is open while its 50 seats last. Every option includes the board, voting, roadmap statuses, changelog, embeddable widget, API, and MCP. There is no free tier, and every purchase carries a 14-day money-back guarantee.

Each FeatQ board supports up to 10,000 voters. The price is the same at 10 voters or 10,000, because there are no per-user, per-seat, or per-tracked-user fees. That means inviting more of your users to the board strengthens the signal without moving the account into a higher price band.

Still have questions? Contact us

Put your feedback board in one place

One flat price, up to 10,000 voters, and MCP on every plan. 14-day money-back guarantee.

View pricing