Voting, embeddable widgets, public roadmaps, and the prioritization UX that separates a real product feedback tool from a glorified suggestion box — mapped step by step for a solo founder in 2026.
Research-based methodology. This guide synthesizes Canny’s and Frill’s public docs, embeddable widget patterns from Intercom and Crisp, anonymous-user fingerprinting research, and our own builds with Claude. Where we have first-person experience we say so; otherwise we’re working from public sources. How we research.
Customer feedback boards aren’t glamorous, but they are sticky. Once a SaaS company plants “feedback.theirproduct.com” in their footer and accumulates 400 ideas with 6,000 votes, switching costs are real — that data is the institutional memory of what their customers want. Canny built a $10M+ ARR business on this. Frill, ProductBoard’s lighter cousin, sells the same shape. Featurebase, Beamer, Sleekplan all live in this market.
The wedge for a solo founder is that this category was solved for B2B SaaS five years ago, and nobody has properly solved it for (a) consumer apps where end-users are anonymous, (b) internal-only product teams who want a private board with deep Linear/Jira integration, or (c) verticals where feedback collection has compliance overhead (healthtech, fintech). If you want the broader build playbook first, our How to build a SaaS with Claude guide covers the general scaffolding workflow this one builds on top of.
Canny is the obvious incumbent. Calling them out is honest. Three real wedges in 2026:
Pick one. Talk to ten product managers in that niche before you ship.
The first thing every founder learns building a feedback tool: upvotes are a visible signal but not a great prioritization metric. The most-upvoted idea is usually the loudest user’s pet feature, not the one that drives revenue. Canny’s competitive moat is not the voting UI; it’s the segmenting and tagging that lets a PM ignore the 200-vote feature their free users want and prioritize the 12-vote feature their three biggest customers asked for.
Public boards attract bots. You will receive submissions like “Buy cheap watches at example.com” within 48 hours of going live. Anonymous voting attracts vote-stuffing. You need rate-limiting, CAPTCHA on first submission, and ideally fingerprint-based de-duplication.
Some companies want every feedback item public (open-roadmap culture). Others want all feedback private to logged-in customers (enterprise). Many want a mix: ideas are private until promoted to a public roadmap. Your data model has to support all three modes from day one or you’ll rewrite it later.
The single most-requested feature when companies switch from a competitor is “why don’t my customers know we shipped what they asked for?” Closing the loop on a status change requires email notifications that get opened, and that means batched digests, not one email per status change.
The data model is medium-complex. The trick is that you have two auth realms: workspace admins (your paying customers) and end-users (their customers). End-users may be anonymous, identified by SSO, or identified by an embed token.
I'm building a feedback-collection SaaS like Canny. The model needs to support: - Workspaces (my paying customers) with multiple admins - Each workspace has multiple boards (e.g., "Feature Requests", "Bug Reports", "Mobile App") - Each board has a visibility: public (anyone with link), private (logged-in end-users only), internal (workspace admins only) - Ideas (also called "posts") belong to a board, with: title, body (markdown), author (admin OR end-user OR anonymous), status - Custom statuses per workspace with order: e.g. "Open", "Under Review", "Planned", "In Progress", "Shipped", "Closed" - Votes belong to (idea, voter) where voter is admin_id, end_user_id, or anonymous_fingerprint - Comments on ideas, with optional admin badge - End-user authentication is a SEPARATE auth realm from admin auth (an end-user is identified per-workspace, not globally) Design the complete Postgres schema. For every table give me: - Columns with types and constraints - A `voter` polymorphic pattern: voter_type + voter_id, with a unique partial index per type so the same person can't double-vote - Indexes for: list ideas in a board sorted by votes desc, list ideas by status, list comments on an idea - A check constraint that an idea's status_id must belong to the same workspace as the board Then write Supabase RLS policies for the three visibility modes. The public board case is the trickiest — anonymous users need to read ideas and write votes/comments via security-definer functions, never direct table access. Output as one SQL file I can run in the Supabase SQL editor.
The polymorphic voter pattern is where Claude will likely give you a junky first draft. Insist on a clean unique index strategy: a partial unique index on (idea_id, end_user_id) WHERE end_user_id IS NOT NULL, another on (idea_id, anonymous_fingerprint) WHERE anonymous_fingerprint IS NOT NULL. This guarantees no double-voting at the database level even if your application code has a bug.
The embeddable widget is the feature that determines whether your customer’s customers actually leave feedback. A “visit our feedback portal” link in the footer gets 100x less submission than a widget that pops in-app at the right moment. Build the widget right and your churn drops by half.
The architecture: a tiny JavaScript snippet that customers paste into their app, which loads an iframe pointing at your service with the workspace identifier and (optionally) a signed user token. The iframe handles auth, posts back to your service, and bubbles up “new submission” events to the host page.
Build the embeddable widget for my feedback SaaS.
DELIVERABLE 1 — the snippet customers paste into their app:
<script>
window.__feedback = {
workspaceId: 'wks_abc123',
user: { id: 'usr_456', email: 'jane@example.com', name: 'Jane' },
// optional: a signed JWT my server issued for this user
userToken: 'eyJ...'
};
(function(){
var s = document.createElement('script');
s.src = 'https://cdn.feedbackapp.com/widget.js';
s.async = true;
document.head.appendChild(s);
})();
</script>
DELIVERABLE 2 — widget.js (vanilla JS, no React in this file):
- Reads window.__feedback config
- Injects a floating button (configurable position) into the host page
- On click, opens an iframe pointed at
https://app.feedbackapp.com/embed?ws=wks_abc123
- Sends the user identity to the iframe via postMessage AFTER the iframe
signals "ready" (so we don't leak data before auth)
- Listens for resize messages from the iframe (so the widget can grow
with content)
- Exposes window.feedback.open() and window.feedback.close() globally
- Total snippet size under 6KB gzipped
DELIVERABLE 3 — the embed page (Next.js App Router) at /embed:
- Reads workspace from query string
- If a signed userToken is present, verifies it server-side and creates
an end_user row (upsert on workspace_id + external_id)
- Renders a tiny UI: list of ideas, vote buttons, "Submit new idea"
form, comment threads
- All form posts go through security-definer RPCs that respect the
signed user token
Cover security: same-origin postMessage source check, CSRF on the
submit form, rate-limiting per workspace per IP.
One detail: ship the snippet as a tag manager-friendly version too. Many of your B2B customers will install via Google Tag Manager or Segment, and a snippet that tries to read document.head at the wrong moment fails silently. Document both install paths.
For public boards you have to support anonymous voting. The naive approach (track by IP) breaks immediately — one office NAT’d behind a single IP looks like one voter. The right approach is browser fingerprinting via FingerprintJS or a homegrown signal mix, scoped to the board.
Build the voting endpoint and anonymous-user identification for my
feedback SaaS public boards.
Architecture:
- An end-user on a public board may or may not be logged in
- If logged in (via SSO/embed token), votes are scoped to end_user_id
- If anonymous, votes are scoped to a fingerprint hash that combines:
user-agent, accepted-language, screen resolution, canvas fingerprint,
and a long-lived first-party cookie
- A vote can be added or removed (toggle)
Implement:
1. A client-side fingerprint module (use FingerprintJS open-source
tier OR build a homegrown one with the listed signals). Output a
stable string fingerprint and a secure first-party cookie that
survives across visits
2. A Supabase RPC `toggle_vote(idea_id, fingerprint, user_token)` that:
- If user_token is present and valid, scopes the vote to that user
- Otherwise scopes to the fingerprint
- Inserts or deletes the vote row based on current state
- Increments/decrements a denormalized vote_count on the idea
- Returns the new vote count and the user's vote state
3. Spam protection:
- Per-fingerprint rate limit: max 50 vote toggles per board per hour
- On submit-new-idea (not vote), require a hCaptcha challenge for
anonymous users
- A trigger that flags ideas/comments containing more than N URLs
OR matching a profanity/spam regex, queued for admin review
Output: the fingerprint module, the RPC SQL, the rate-limit table
schema, and the Next.js client hook that calls the RPC and updates
optimistic state.
An honest note on fingerprinting: it’s not perfect, and Apple Safari now actively defeats most signals. The realistic stance is “good enough to deter casual vote stuffing.” A determined attacker can still vote-stuff. Pair fingerprinting with rate limiting and admin moderation tools so motivated bad actors hit a wall fast. PostHog ships a similar fingerprint module that may be worth using rather than building.
The single most-asked-for feature when companies switch from a competitor is “why don’t my customers know we shipped what they asked for?” Status updates that drive re-engagement are the difference between feedback boards that feel alive and feedback boards where ideas die quietly.
The right pattern: when an admin changes an idea’s status, queue notifications for everyone who voted or commented. Don’t send one email per status change — batch a daily or weekly digest, with the change highlighted. Link directly back to the idea page.
Build the email-digest system for status changes.
Mechanics:
- When an admin updates an idea's status, write a row to a
`status_change_events` table with: idea_id, previous_status, new_status,
changed_at, changed_by_admin_id
- A daily cron (Vercel Cron or Supabase scheduled function at 9am in
the workspace's timezone) does the following per workspace:
1. Finds all status changes in the last 24h
2. For each change, identifies all end-users who voted on or commented
on that idea AND have not opted out of notifications
3. Groups by recipient: each recipient gets ONE email summarizing all
status changes on ideas they care about
4. Renders the email via Resend with a list like:
"[Feature: dark mode] moved from Planned to In Progress"
"[Feature: bulk export] moved from In Progress to Shipped"
5. Each item links to the idea page with a one-click unsubscribe
token (signed JWT)
Schema additions:
- end_user_notification_prefs: end_user_id, board_id, frequency
(immediate | daily | weekly | off)
- An unsubscribe page that flips frequency to off based on the JWT
Edge cases:
- An end-user whose email bounces should auto-unsubscribe
- Skip the digest entirely if a recipient has nothing to receive
- Respect a per-workspace "from" name (so emails come from
"TheirProduct" not "Feedbackapp")
Output: the cron handler, the schema, the React Email template, and
the unsubscribe route.
One opinionated take: include the admin’s comment with the status change in the digest body. “Moved to Shipped” alone reads like a robot. “Moved to Shipped — rolling out tonight, thanks for the patience” reads like a product team. Tools that let admins write a single status-change comment and have it broadcast to all voters get higher reply rates and lower churn.
The public roadmap is half the value of the product. It’s the page that gets pinned in the customer’s help docs, the page that gets shared in onboarding emails, the page that signals “this team listens.” Render it well.
Build the public roadmap page at /roadmap/[workspace-slug]. Server component: - Loads all ideas across all PUBLIC boards in the workspace where the status is in (Planned, In Progress, Shipped) — configurable by admin - Groups by status, then by board within status - Sorts within each group by vote count desc Layout: - Three columns: Planned | In Progress | Shipped (status order configurable by admin) - Each column shows idea cards: title, board badge, vote count, brief body excerpt - Each card is a link to the full idea page with comments/votes - "Shipped" cards optionally show a date and a "what we shipped" note - A subtle filter bar at top: filter by board, sort by votes/recent Visual: - Use the workspace's brand color as the accent (read from workspace.brand_color) - Render the workspace logo in the header - Mobile: collapse to a single-column accordion grouped by status SEO: - Server-rendered with metadata: og:title = "[Workspace] Public Roadmap" - Each idea page generates its own canonical URL and og:image - Include JSON-LD ItemList for the roadmap entries The roadmap should be inviting to scroll, not a wall of text. Limit each card to ~80 chars of body excerpt. Pagination after 30 cards per column with a "show more" button.
One feature differentiator worth shipping: a “custom branding” tier that lets the workspace use their own font, accent color, and (on the highest tier) custom domain at roadmap.theirproduct.com. Branded roadmaps justify the $99–$299 tiers because the customer’s customers can’t tell they’re using a third-party tool.
Per-workspace tiered pricing is the dominant model in this category, anchored by Canny:
Free tier is optional. Canny doesn’t have one; Featurebase does. As a solo founder, a free tier is a customer-acquisition channel and a support tax. We’d ship a 14-day trial without a credit card and skip the free tier entirely — the per-workspace AOV is high enough that you don’t need top-of-funnel volume.
The strongest distribution lever in this category is the “Powered by” link in the public roadmap footer of free or starter customers. One micro SaaS founder we know got 40% of inbound leads from that single backlink. If you want to go a layer deeper on the AI-summarization angle, our AI SaaS ideas for 2026 piece covers AI-native variants of established categories.
Voting UIs are commodity; Canny owns generic. The win is AI-summarization that turns 500 ideas into 20 themes, integration depth that closes the loop with Linear/Jira, or vertical specificity (game studios, healthtech, open-source projects). Per-workspace pricing tiers up to $299/month make this one of the better $5–$15K MRR opportunities for a solo founder. Pick a wedge, talk to ten product managers in it, and ship the embeddable widget first.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.