By Niklas Wibelius, founder of featurevote
I’ve spent a year and a half building featurevote, working at least full-time to get it to where it is today. I estimate the investment so far at roughly $300,000.
That experience shapes my answer when someone asks whether they should build their own feedback tool.
Sometimes, yes. But it helps to understand what you’re taking on—and how much of it you actually need.
A form, a list of requests, a vote button and a few statuses make a reasonable first version. AI can help you build that. The work becomes more involved as you decide how it should behave in everyday use.
Take merging two requests.
Someone may have voted on both. Adding the vote counts together would overstate demand. Comments need to move with the requests, and the originals need a clear outcome. In featurevote, merging consolidates votes, preserves comments and counts each person once.
Email has involved several separate pieces of work: pacing bulk sends, retrying refused deliveries, reporting partial sends, supporting unsubscribe and handling bounced addresses.
There are product decisions inside those details too. Someone who voted without leaving an email address cannot receive a shipping notification. The interface needs to make clear who can actually be reached.
Privacy brings another set of responsibilities. A private request needs to stay out of public lists, search and the roadmap. That decision has to hold wherever the information can appear.
These are examples of where the development time goes. They are also capabilities your own tool may not need.
Today’s featurevote is a commercial product serving different businesses. A small internal board for one team can be a much smaller project.
You might reuse your existing sign-in and infrastructure, review duplicates manually, send updates yourself and keep everything inside one workspace. That can be a sensible, useful tool.
I would consider building when the workflow is important enough to justify custom software, existing tools leave a meaningful gap, and someone has the time to maintain it.
I would also define the boundaries before starting. Perhaps colleagues need to submit requests, vote and see their status. That does not automatically mean you need automated duplicate detection, a changelog editor, several integrations or sophisticated reporting.
A limited tool can be successful on its own terms. The important question is whether you can keep that scope limited while still meeting the need.
If that sounds like your situation, I’ve included a build prompt you can copy into your coding assistant. It describes a small internal board with sign-in, requests, votes, comments and basic administration. It also includes access controls and checks that permissions work.
Buying becomes easier to justify when your requirements are fairly standard and you want your engineers focused on your own product. Requests, votes, replies, a roadmap and shipping updates may already be well served by an existing tool.
That purchase still deserves scrutiny. Check the workflow you actually need, the limits you will encounter, how pricing changes as usage grows, and what you can export if you leave. Include setup and migration in the comparison.
A subscription also leaves important work with your team: reading feedback, deciding what matters, explaining decisions and answering people.
There is a third option: keep your current process.
If feedback volume is manageable, you can find the original conversations and customers consistently receive a reply, a spreadsheet and your existing tools may be enough. A new portal should solve a problem you can name.
When comparing the options, use the same requirements and the same time period. Include the initial build, maintenance and services on one side; subscription, setup, migration and administration on the other. Consider what your team would postpone to do the work.
I can justify continued investment in featurevote because feedback software is the product I sell. Another business needs its own reason to make that commitment.
After a year and a half of building, my advice is to be deliberate about what you are taking on. Build when custom control has clear value and someone will own the result. Buy when an existing tool meets the need at a better cost. Keep things simple while your current process works.
Whichever route you choose, make sure it helps you stay close to your users—and leaves you time to respond to what they tell you.