Architecture guide

Architecting an in-app feature-request board in React

When founders say "we need a Canny clone," they usually mean: "users should be able to suggest things and vote, somewhere in the product." That is not Canny. Canny is a public marketing surface with a roadmap and changelog suite. What most SaaS teams need is a private feedback board embedded behind their auth gate: no separate login, no public /b/... URL, no anonymous visitors.

This guide covers the architectural questions. For code and props, see the React implementation guide.

Where does the board belong in your IA?

The board is a product surface, not a marketing surface. Common placements:

Settings → Feedback tab. Users find it naturally when configuring their account. Low friction for power users.
Help menu or command palette. Pairs well with support links. Surfaced on demand rather than always visible.
Dedicated /feedback or /ideas route. Works for products where feedback is a first-class workflow. Requires navigation entry.
Contextual modal. Triggered from a specific feature area to capture in-context requests. Useful when you want scoped boards per product area.

The widget has no opinion on placement. It mounts wherever you render it behind your auth check. Start with one placement; add more later if you need scoped boards.

Host identity: from your session to user.id

Bootstrapware does not run an end-user login. Your app passes identity to the widget:

<Feedback
  user={{ id: session.userId, name: session.name }}
  ...
/>

user.id is opaque and stable. It is your primary user key, not a display name. If it changes between sessions the same person appears as two different voters. Common mistake: using email as the id when emails can change.

For a private feedback board inside authenticated SaaS, host-asserted identity is usually enough. If you need stronger forgery resistance (preventing a bad actor with a leaked publishable key from voting under any user.id they invent), enable requireAuthorToken on the board and mint a short-lived signed token server-side per session. See identity and authorToken.

Storage: local → BYO → Hosted

The component resolves storage mode from props. Pick the tier that matches where you are:

Tier	When to use	Posts live on
Local adapter	Evaluating placement, design, and user flow. No multi-user truth yet.	Your browser (localStorage)
BYO adapter ($9.99)	You already have the Postgres and prefer to own the data. Config published via dashboard.	Your API / database
Hosted ($19.99)	You want a moderation inbox, webhooks, and status management without building them.	Bootstrapware

You can start local and migrate upward. BYO requires implementing four adapter callbacks (listPosts, createPost, vote, unvote). Hosted requires no adapter. See BYO vs Hosted.

Private board vs public roadmap: the real decision

An embedded private feedback board and a public idea portal are different products for different goals. A private feedback board inside your app reaches the people who already use it, uses your existing session, and keeps requests scoped to real customers. Public boards attract everyone, including people who have never opened your product, competitors, and spam.

Bootstrapware Feedback is deliberately embed-only. There is no hosted public board URL to share. If your product strategy calls for a public roadmap as a marketing or community surface, use a public-board vendor alongside it, or build static pages yourself. See embed-only boards and in-app vs public portal.

Minimal working example

// Behind your auth gate. Hosted example
import { Feedback } from "@bootstrapware/feedback";
import "@bootstrapware/feedback/styles.css";

export function FeedbackTab({ session }: { session: Session }) {
  return (
    <Feedback
      boardId="brd_..."
      publishableKey={process.env.NEXT_PUBLIC_FEEDBACK_KEY}
      user={{ id: session.userId, name: session.displayName }}
    />
  );
}

Full implementation details (every prop, adapter contract, authorToken minting, pitfalls) are in the React implementation guide.