# Canny Costs $79/mo. But This Cost $0.

> Feature voting without the SaaS tax: built-in boards with votes, statuses, and voter emails. The $79-to-$0 migration inside.

Source: https://boringpush.com/blog/canny-alternative-feedback-boards

## Paying rent on your own roadmap

Canny's pitch is seductive: beautiful boards tomorrow, zero code today. Then month six arrives with the invoice math: $79+/month (verify current) for the privilege of hearing your own customers — $948 yearly to host opinions about your product on someone else's domain.

Worse: the data lives there. Voter emails, request histories, status timelines — exportable theoretically, migrated practically never. Your roadmap's memory belongs to a vendor whose pricing moves yearly. The ballot box charges admission to your own democracy.

Canny alternative feedback isn't about hating Canny (it works, genuinely). It's about owning the highest-leverage dataset a founder has: what paying users want, in their words, votable.

## Rented vs owned feedback

![Rented versus owned ballot box comparison](/blog/canny-alternative-feedback-boards/rented-vs-owned-roadmap.svg "Two ballot boxes: one meters you monthly, one answers SQL for free.")

| Axis | Canny hosted | Built-in boards |
|---|---|---|
| Monthly cost | $79+ (verify current) | $0 (3 tables) |
| Voter context | Email only (plus integrations) | Full user row (plan, usage, history) |
| Data ownership | Their cloud (export theoretically) | Your SQLite (SQL actually) |
| Status→changelog loop | Their workflow | Your shipped states + emails |
| Branding/domain | Their chrome around you | Native, no widget seams |
| Migration risk | Stays because leaving hurts | Nothing to leave |

Three details make rented feedback rot quietly:

1. **Voter context stays shallow.** Canny knows emails; your database knows plans, usage, tenure, and payment history — "ten votes from churn-risk annuals" versus "ten votes." Prioritization quality follows context depth, and rented tools structurally lack yours. Rich context is a native-app exclusive.
2. **Widget seams scream third-party.** Embedded boards load foreign chrome, foreign fonts, foreign login states — trust friction on the exact page asking for engagement. Native boards inherit your auth, your design, your speed. Invisible seams aren't aesthetic; they're participation rate.
3. **Export rights ≠ export reality.** CSV dumps of votes lose threads, statuses, voter mapping, and history — migration means rebuilding meaning from fragments. Owned tables migrate with a file copy (format preserved, history intact). Rights you never exercise are hopes; ownership you hold is fact.

The feedback-board template built it. This one justifies deleting the subscription.

## Canny alternative feedback migration

One weekend: export, rebuild natively, redirect voters — the ballot box moves home.

**Step 1 — Export everything with history intact.**

```bash
# Canny API: posts + votes + comments + statuses + voter emails → JSON
# map: post → feedback_posts, vote → feedback_votes (userId matched by email),
#      comment → feedback_comments, status → open/planned/shipped/declined
# verify: counts match per table before switching (no silent voter loss)
```

Voter-email matching links old votes to user rows (the context upgrade that justifies the whole move). Statuses map to the four-state machine (open, planned, shipped, declined) — Canny-specific states collapse deliberately, documented per mapping. Count parity per table before flipping: migrated democracy needs verified rolls.

**Step 2 — Ship the native board in one afternoon.**

```sql -- three tables, composite-PK fraud guard, status machine (feedback template post)
-- /feedback: ranked list + vote buttons + markdown comments + voter emails on ship
-- auth-gated voting (one account, one voice), admin statuses via allowlist
```

Same shape the template post details: posts, votes (one per user by construction), comments (sanitized markdown), statuses driving voter notification emails. Afternoon build because the pattern is proven — schema, verbs, thin route, dumb UI. Native auth means voter context from day one (plan-weighted sorting available immediately).

**Step 3 — Close the loop publicly, then cancel.**

```bash
# week 1: dual-run (Canny read-only banner → "we moved, vote here")
# week 2: ship one top request → notify voters from new system (proof it works)
# week 3: cancel subscription, export final archive, delete account
```

The shipped notification from the new system is the migration's proof event — voters experience the loop working before the old box dies. Dual-run briefly (redirects, not duplicates), then cancel decisively (subscriptions kept "just in case" bill forever). $948/year back on week three, voters never noticing the move except improved context.

The ballot box is home now — roadmaps owned, voters heard.

## Rented vs owned, year one

| Year of feedback | Canny $79/mo | Built-in $0 |
|---|---|---|
| Cash cost | ~$948 | $0 |
| Voter context depth | Email | Full user rows |
| Status→changelog loop | Their workflow | Native shipped emails |
| Data portability | Theoretical export | File copy |
| Participation friction | Widget seams | Native speed |
| Migration weekend | — (staying costs) | Once, then free |

BoringPush ballots live in native tables.

One honest cost: built-in lacks Canny's polish surface (roadmap widgets, Jira sync, public-portal SEO) and demands weekly curation (merges, statuses, replies — ten minutes). Priced against $948 plus context poverty: curation is customer development disguised as maintenance, and native context outperforms integrations every prioritization meeting. Own the ballot box; rent nothing that hears customers.

## FAQ

### Is canny alternative feedback realistic for non-technical founders?

With an agent, yes: the three-table pattern plus fenced build pipeline (schema → verbs → route → UI) is a standard afternoon task — spec it, review the diff, run the gate. Non-technical founders already run agents for bigger features; boards are smaller. The migration (export mapping) is the harder half — budget the weekend, keep the subscription through it, cancel after proof.

### What happens to SEO value of public Canny boards?

Redirect post-by-post (old URLs → new board URLs, 301s) plus the new board's public reads (SEO-indexed requests, same content, better context). Brief dip during transition (weeks), recovery after (native speed + fresh content win rankings). Roadmaps rank on usefulness, not hosting — migrated content with live voting outranks frozen archives within a quarter.

### Should votes be public or private per voter?

Public counts, private ballots (who voted visible to admins only): transparency of demand without social pressure on voters. Competitors reading your board is fine (they can't read voter intent depth); voters seeing each other's identities chills honest voting. Counts public, identities admin-gated — the split that maximizes both signal and participation.

### How do I handle duplicate requests across the migration?

Merge with vote combining (duplicate's votes transfer to canonical, authors thanked both, redirect from duplicate URL): duplicates are enthusiasm, not spam — honor the energy while consolidating signal. Weekly merge ritual (ten minutes) keeps the board navigable. Merged voters get notified on ship like originals — nobody's voice lost in consolidation.

### Can the board serve non-logged-in visitors (marketing value)?

Read publicly (SEO + social proof: "see what we're building with users"), vote/comment authenticated (ballot integrity). Public reads convert lurkers ("they listen"); gated voices keep ballots honest. The two-presentation instinct once more: display widely, decide narrowly. Transparency markets, gates protect.

### When is staying on Canny actually correct?

Enterprise workflows (Jira two-way sync, SSO-enforced voter identity, portfolio-level roadmaps across products) where integrations do real daily work — plus teams without any engineering bandwidth for a weekend migration. Staying is legitimate when the subscription funds workflows, not just hosting. Audit yearly: workflows used vs hosting paid. Pay for verbs, never nouns.

## Keep reading

- [Feedback Boards: The Feature to Ship Before Your App](/blog/nextjs-feedback-board-template) — the three-table pattern this migration lands on
- [PostHog Bills $450. SQL Bills $0.](/blog/posthog-vs-selfhosted-analytics-nextjs) — the sibling $0 migration
- [Take Money 3 Ways, Write Checkout Once](/blog/three-payment-rails) — revenue context voters carry