I Built a Canny Alternative — Then Realized the Feedback Board Was the Easy Part

Hareesh Vemasani — Fri, 24 Jul 2026 11:44:49 +0000

Almost every customer-feedback product starts with the same three features:

A feedback board
An upvote button
A public roadmap

Technically, none of these is particularly difficult to build.

Create a table for posts. Add a vote count. Display the posts in columns based on their status.

You now have the first version of a Canny alternative.

But after running SaaS products and speaking with other founders, we realized that collecting feedback was not the real problem.

The real problem was everything that happened before and after someone clicked Submit.

Feedback was arriving through:

Support conversations
Slack messages
Customer calls
Emails
App reviews
Sales conversations
Public feedback boards
Random screenshots shared internally

The same request could appear in five different places, written five different ways.

Then someone had to manually copy it into a spreadsheet, check whether it already existed, decide how important it was, update the roadmap, publish a release note, and remember to tell the original customer that it had shipped.

Most teams did only the first step.

So we built ProductBridge around the entire feedback loop—not just the voting board.

What ProductBridge Does

ProductBridge gives SaaS teams one place to:

Collect feedback

Customers can submit feedback through public or private boards, in-app widgets, integrations, APIs, and connected support channels.

Feedback can also be pulled automatically from tools where customer conversations are already happening.

Organize it with AI

Incoming feedback is analyzed, categorized, summarized, and checked for duplicates.

Instead of showing product managers 37 slightly different posts asking for the same thing, the system can connect them to one underlying request.

Find patterns

Teams can use Ask AI to explore their customer feedback in natural language.

For example:

What are the biggest problems reported by enterprise customers this month?

Or:

Which requests are mentioned by customers at risk of churning?

The goal is not to let AI make the roadmap.

The goal is to remove the hours of manual work required before a product manager can make a good decision.

Build a roadmap

Accepted ideas can move directly into public, private, or customer-segmented roadmaps.

Teams can show customers what is:

Under review
Planned
In progress
Completed

Publish changelogs

When a feature ships, the team can turn it into a changelog entry and distribute it through a public page, email, or an in-app widget.

Close the loop

The people who submitted or voted for the request can be notified automatically when its status changes.

This sounds like a small feature.

In practice, it is one of the most important parts of the product.

Customers do not stop submitting feedback because a company rejected their idea.

They stop submitting feedback because they believe nobody is listening.

The Simplified Architecture

At a high level, ProductBridge has six layers:

Feedback sources
      ↓
Ingestion and normalization
      ↓
AI analysis and deduplication
      ↓
Feedback repository
      ↓
Roadmap and delivery workflow
      ↓
Changelog and customer notifications

Each layer solves a different problem.

1. Normalize Everything Into One Feedback Model

A message imported from Slack looks nothing like an App Store review.

A support ticket contains conversation metadata.

A public-board post contains votes.

An API submission might contain custom fields from the customer’s CRM.

Before we can analyze any of this, it needs to be converted into a common internal structure.

A simplified version looks like this:

type FeedbackItem = {
  id: string;
  organizationId: string;

  title: string;
  description: string;

  source:
    | "portal"
    | "widget"
    | "slack"
    | "support"
    | "review"
    | "api";

  sourceReference?: string;

  customerId?: string;
  companyId?: string;

  status: "new" | "reviewing" | "planned" | "in_progress" | "completed";

  categoryIds: string[];
  tagIds: string[];

  sentiment?: "positive" | "neutral" | "negative";

  createdAt: Date;
};

Every ingestion source converts its input into this structure.

That lets the rest of the system work without needing to understand where the feedback originally came from.

2. Make Every Integration Idempotent

Integrations retry.

Webhooks can be delivered twice.

Users reconnect accounts.

Background jobs fail halfway through processing.

Without idempotency, the same support conversation can become three separate feedback posts.

Every imported item therefore needs a stable external reference:

existing_item = find_by_source_reference(
    organization_id=organization_id,
    source="slack",
    source_reference=message_id,
)

if existing_item:
    update_existing_item(existing_item, payload)
else:
    create_feedback_item(payload)

This looks simple, but it becomes more complicated when a single conversation contains several distinct requests.

One Slack thread might include:

A bug report
A missing integration
A pricing complaint
A workaround suggested by support

Treating that entire conversation as one feedback item makes later analysis much less useful.

The ingestion layer has to preserve the source while still breaking the conversation into meaningful observations.

3. Detect Intent, Not Just Matching Words

Keyword-based duplicate detection works when two users write nearly identical requests.

It fails when one customer says:

The dashboard takes forever to load.

And another says:

Analytics keeps timing out when I select 90 days.

Different words. Potentially the same underlying problem.

Our duplicate-detection flow combines semantic similarity with structured information such as:

Product area
Customer segment
Existing categories
Previously confirmed duplicates
Request type
Context from the original conversation

A simplified flow looks like this:

New feedback received
        ↓
Extract the underlying problem or request
        ↓
Retrieve semantically similar existing items
        ↓
Compare intent and product context
        ↓
Attach to an existing request or create a new one

We still keep the original customer message.

AI-generated summaries should never erase what the customer actually said.

The summary helps the team process feedback faster. The source remains available when deeper context is needed.

4. Keep Multi-Tenancy Boring

ProductBridge is a multi-tenant SaaS application.

Almost every relevant record belongs to an organization:

SELECT *
FROM feedback_items
WHERE organization_id = :current_organization_id;

That organization boundary must be enforced consistently across:

Feedback
Votes
Customers
Roadmaps
Changelogs
Help-center articles
Integrations
API keys
Webhooks
Uploaded files
AI queries

A missing tenant filter is not a minor bug. It is a data-isolation problem.

We therefore treat organization scoping as part of the data model and service layer rather than relying on individual UI pages to filter records correctly.

5. Treat Status Changes as Events

Moving a roadmap item from In Progress to Completed is not just a database update.

It can trigger several actions:

Feature marked as completed
        ↓
Update the public roadmap
        ↓
Find related feedback posts
        ↓
Find submitters, voters, and subscribers
        ↓
Generate or request a changelog entry
        ↓
Send customer notifications
        ↓
Emit webhooks to connected systems

We model important changes as events so that each downstream action can be retried independently.

Conceptually:

publish_event(
    "roadmap_item.completed",
    {
        "organization_id": organization_id,
        "roadmap_item_id": roadmap_item_id,
    },
)

Consumers can then handle:

Customer notifications
Changelog preparation
Integration sync
Analytics updates
Webhook delivery

This prevents one failed email from blocking the underlying roadmap update.

6. Let AI Assist Without Owning the Decision

Product teams do not need AI to blindly decide what they should build.

A request with 500 votes is not automatically more important than a request from three high-value customers.

Votes are only one signal.

Other signals can include:

Number of affected customers
Account value
Customer segment
Churn risk
Request frequency
Sentiment
Strategic alignment
Implementation effort
Recent growth in mentions

AI is useful for extracting and connecting these signals.

Humans still decide what enters the roadmap.

That distinction shaped how we built features such as Ask AI.

The assistant can summarize the evidence:

This request was mentioned by 23 customers, including four enterprise accounts. Mentions increased by 38% this month, and six customers described it as a blocker.

That is far more useful than:

AI says you should build this.

Building an MCP Server

We also wanted teams to access their product feedback from the AI tools they already use.

So we added an MCP server.

This allows compatible AI assistants to retrieve ProductBridge data and perform supported actions through a structured interface.

The flow looks roughly like this:

Claude, Cursor, or another MCP client
                ↓
        ProductBridge MCP server
                ↓
 Authentication and organization permissions
                ↓
      ProductBridge application APIs
                ↓
 Feedback, roadmaps, and changelogs

A product manager can ask:

Show me the fastest-growing requests from enterprise customers.

A developer can ask:

Find feedback related to the feature I am currently implementing.

A founder can ask:

Draft a changelog entry for the items completed this week.

The important part is that the AI operates through authenticated tools rather than receiving an unrestricted database connection.

Why We Added a Help Center

On July 24, 2026, we launched a Help Center / Knowledge Base inside ProductBridge.

At first, a knowledge base might sound separate from feedback management.

We see it as part of the same customer communication loop.

Before the Help Center, ProductBridge covered:

Customer submits feedback
        ↓
Team analyzes it
        ↓
Team plans the feature
        ↓
Team ships it
        ↓
Customer receives the update

The Help Center adds another layer:

Customer has a question
        ↓
Customer finds an answer
        ↓
Customer still submits feedback when needed
        ↓
Recurring questions reveal documentation or product gaps

This creates useful connections between support content and product feedback.

For example:

Repeated support questions can become help articles.
Feedback can reveal articles that are missing or unclear.
Changelog entries can link to detailed setup guides.
Newly released features can immediately have supporting documentation.
Customers can find answers without opening another support ticket.

A feedback portal tells customers what you might build.

A roadmap tells them what you are building.

A changelog tells them what you shipped.

A Help Center tells them how to use it.

Together, they form a complete product communication system.

The Tech Stack

The simplified ProductBridge stack includes:

A modern React-based frontend for the application and customer-facing portals
Python API services for business logic and integrations
PostgreSQL for relational product and customer data
Background workers for ingestion, analysis, notifications, and synchronization
OpenAI and Anthropic models for AI-assisted feedback workflows
AWS infrastructure in Europe
Nginx for routing and application delivery
Resend for transactional email
REST APIs, OAuth, and webhooks for integrations
MCP for connecting external AI assistants
Custom-domain infrastructure for branded portals

The exact technology behind each layer matters less than maintaining clear boundaries between them.

Integrations should not write directly into roadmap tables.

AI jobs should not own customer permissions.

Notification failures should not roll back product-status changes.

Public portals should never be able to bypass organization-level access controls.

The stack helps us ship.

The architecture prevents shipping quickly from turning into a permanent mess.

What Was Actually Difficult?

The voting interface was not difficult.

The hardest parts were:

Resolving customer identity

The same person might appear through Slack, Intercom, email, and a public portal using different identifiers.

Connecting those interactions without merging the wrong users requires careful identity mapping.

Preserving context

A clean AI summary is useful, but the original conversation, source, customer, and surrounding messages must remain accessible.

Preventing duplicate imports

Every integration behaves differently. Reliable ingestion requires retries, idempotency, rate-limit handling, and monitoring.

Supporting public and private experiences

The same organization may need:

A public feedback board
An internal board
A private board for selected customers
A roadmap visible only to one segment
Anonymous submissions
Authenticated SSO access

Permissions become part of the product architecture very quickly.

Closing the loop reliably

Notifications need to reach the right people without sending duplicates or exposing information from private roadmap items.

Keeping pricing predictable

Feedback tools become more valuable as more customers participate.

Charging dramatically more because more users submitted feedback creates the wrong incentive.

ProductBridge therefore uses flat paid plans with unlimited tracked users rather than making teams worry about every new person entering their feedback portal.

The free plan includes the core workflow for teams getting started, while paid plans begin at $29 per month when billed annually.

What I Would Do Differently

If I were starting again, I would define the normalized feedback model before building the first integration.

It is tempting to make every integration work quickly by storing the original provider payload and handling it later.

“Later” arrives after six integrations, when every feature requires source-specific conditions.

I would also model major product changes as events from the beginning.

Notifications, webhooks, integration syncs, analytics, and audit trails all become easier when they subscribe to explicit events instead of being embedded inside one large request handler.

Finally, I would build customer identity resolution earlier.

Feedback becomes significantly more valuable once you can answer:

Which accounts are asking for this?
How much revenue do they represent?
Is this affecting free users or enterprise users?
Did the same customer mention it through another channel?
Has anyone asking for it recently churned?

A vote count alone cannot answer any of those questions.

The Business Case

ProductBridge is designed for SaaS teams that have outgrown spreadsheets but do not want feedback software costs to scale unpredictably with seats or tracked users.

The free plan is intended for teams validating their feedback workflow.

Paid plans add capabilities such as:

Unlimited tracked users
Unlimited feedback boards
Automatic feedback ingestion
Ask AI
Integrations and APIs
Custom domains
Advanced access controls
SSO
MCP access
Help Center and Knowledge Base functionality

Our bet is simple:

Teams do not need another place where feedback can sit.

They need a system that moves feedback from scattered conversations to a product decision—and then tells the customer what happened.

Try It

ProductBridge is live with a free plan to get started.

Create a feedback board, connect one of your existing customer channels, or publish your first roadmap.

And since we launched the Help Center today, you can now manage customer feedback, roadmaps, changelogs, and product documentation from the same platform.

I would genuinely love feedback from other developers and SaaS founders:

Which part of the customer-feedback workflow is still the most manual inside your company?

DEV Community: Hareesh Vemasani