Short answer: build it if all you need is a form that drops text into a table. Buy one if you need customers to vote, see a roadmap and hear back when something ships. The first version of a feedback board takes an afternoon. The parts that make people actually use it (identity, duplicate merging, statuses, notifications, a roadmap, a changelog, a custom domain) are where the time goes.
Most teams don't decide this up front. Someone adds a "Send feedback" button. Then customers ask if they can see what others asked for, so votes get added. Then someone wants a public roadmap, then a changelog, then a subdomain so it looks like part of the product. A year later there is a small internal product nobody planned to maintain.
This guide lists what that button turns into, so you can make the call on purpose.
What a feedback board needs once people use it
| Piece | What you would build | Why it matters |
|---|---|---|
| Submission | A form in your app, plus a hosted page and an email address for people outside it | Requests come from the product, sales and support, not one place |
| Voting with identity | Votes tied to a real user, one vote per person | Anonymous votes are easy to game, and you can't follow up |
| Duplicate handling | Suggest similar posts while someone types, merge votes and subscribers | Without it, demand is split across five copies of the same request |
| Statuses and a roadmap | Planned, in progress, shipped, shown as a board people can read | A list of requests with no status reads as "ignored" |
| Notifications | Email everyone who voted or commented when the status changes | This is the step that brings people back to vote again |
| Changelog | A page and an in-app widget announcing what shipped, linked to the request | Closes the loop for people who never visit the board |
| Branding and domain | Your logo, colors and a custom domain for the portal | Customers trust a board that looks like your product |
| Access control | Single sign-on, private boards, domain allow-lists, moderation | Enterprise customers and pre-launch products need private boards |
| Issue tracker sync | Push a request to Jira or Linear and keep status in step | Otherwise someone updates two tools by hand |
None of these is hard alone. Together they are a product with its own bugs, spam and support questions.
The real failure: a public roadmap with zero votes
A board nobody votes on is worse than no board. It tells customers you asked and nobody cared, and it gives the team nothing to prioritize with. Whether you build or buy, the board only collects demand if:
- It lives where users already are. Put the form inside your product, not only behind a link in the footer.
- Votes belong to real people. Single sign-on lets existing customers post under their own account, so you know which customer is asking.
- Duplicates get merged. One post with all the votes says more than five posts with a few each.
- Voters hear back. When a request ships and every voter gets told, they come back and vote on the next one.
If your homegrown version skips steps 3 and 4, it will usually stall at the "zero votes" stage.
How to cost the build honestly
Use your own numbers. There is no useful industry average here, because it depends on your stack and how much of the list above you need.
- Build cost = engineer days for the first version × your loaded day rate.
- Run cost per year = hours per month on fixes, spam, sign-in issues and small requests × 12 × your hourly rate.
- Opportunity cost = what those engineers would have shipped in your actual product instead.
Then compare against a hosted tool. FeatureOS, for example, starts at $60/month for 5 team seats ($600/year on annual billing) with unlimited end users, so the bill does not grow with the number of customers who vote. There is a 14 day free trial, and eligible early-stage startups can get 6 months free on Starter through the Startup Program. See pricing for the larger plans.
If the run cost alone is more than the subscription, buying is the cheaper option even before you count the first build.
When building is the right call
Building makes sense when:
- You only need private, internal intake (a form that files tickets) with no voting, roadmap or customer-facing page.
- Feedback is part of the product you sell, so the board is a feature for your own customers, not a tool for your team.
- You need custom logic a hosted tool won't support, and you have engineers with time to own it for years, not weeks.
Buying makes sense when:
- You want customers to vote, see a roadmap and get told when things ship.
- Your engineers' time is better spent on your core product.
- You need SSO, private boards or Jira sync without building them.
What buying gets you in FeatureOS
If you go the buy route, here is how FeatureOS covers the checklist above:
- Collect: a hosted board, an in-product widget, and a Letterbox email address where the subject becomes the post title. See feedback boards.
- Duplicates: similar posts are suggested as they come in, and when you merge, votes move to the surviving post and every voter and commenter stays subscribed.
- Roadmap: public or private roadmaps built from your posts.
- Close the loop: move a post to shipped and every voter and commenter hears about it. Publish the update in release notes with an in-app widget.
- Look like your product: your logo, brand colors and a custom domain on the portal.
- Access: private boards with single sign-on, domain allow-listing or invites, plus moderation that holds posts until you approve them.
- Engineering sync: two-way status sync with Jira, and a Linear integration that links posts to issues.
- Help center and forms in the same product, so you don't add a third and fourth tool later.
More than 1,500 companies use FeatureOS. If you are still deciding between hosted tools, see FeatureOS vs Canny and FeatureOS vs Featurebase.
A simple way to decide this week
- Write down which rows of the checklist you need in the next 12 months.
- Estimate build days and monthly upkeep for just those rows.
- Start a free trial of a hosted tool and put its widget in your product for two weeks.
- Compare: did the hosted board collect votes, and what would building the same thing have cost?
If you only ticked "submission", build the form. If you ticked more than three rows, a hosted feedback board is likely to cost less than the engineering time.