The problem
Product feedback usually arrives through support conversations, issue trackers, spreadsheets, and internal discussions. Prioritization happens somewhere else, while the public roadmap and changelog are updated manually—if they are updated at all.
BuildVote connected those stages into one system so a team could move from an incoming request to a visible product decision and, eventually, a release update.
One platform, multiple product spaces
The platform evolved from a single feedback board into a multi-project application. Each project could have its own:
- Feedback submission and voting portal
- Kanban and timeline roadmap views
- Product changelog with reactions and subscriptions
- Searchable knowledge base
- Standalone roadmap and changelog embeds
- Members, visibility rules, categories, and status workflow
Users could track projects and filter their own submissions, while administrators managed feedback, comments, priorities, releases, content visibility, and project access.
Prioritization with and without AI
BuildVote supported RICE, ICE, MoSCoW, and impact-versus-effort methods so product decisions did not depend on an unexplained score.
Its bring-your-own-key AI layer added model-assisted prioritization, automatic categorization, and duplicate detection through OpenAI or OpenRouter. Provider keys were encrypted at rest, available models were discovered dynamically, and reasoning-model output was normalized before it entered the product workflow.
Closing the release loop
The changelog system could process repository activity from GitHub, turning development history into material for structured product updates. Public changelog pages, reactions, subscribers, status notifications, and embeds connected delivery back to the people following the roadmap.
Full application backend
The platform included PostgreSQL storage through Drizzle ORM, plan and feature enforcement, project membership, Logto OIDC authentication, PKCE, short-lived one-time code exchange, administrative configuration, user and plan management, Stripe lifecycle handling, legal pages, and feature gates.
The administration work moved branding, homepage content, pricing modes, service configuration, users, plans, and platform settings into a managed backend rather than leaving them as hard-coded deployment values.
Product evolution
BuildVote progressed through a documented sequence: core feedback and voting, roadmap and changelog expansion, multi-project architecture, AI assistance, commercial plan enforcement, stronger authentication, and a configurable administration system. That history is useful because it shows the platform as an evolving product rather than a static prototype.
Archive status
BuildVote was fully operational but was taken offline when its recurring infrastructure costs were no longer justified. The repository remains private. This page documents the implemented product and architecture without presenting the service as currently available or claiming adoption figures that have not been independently verified.