Building B2B feedback, NPS, and announcements as a drop-in embed (not another heavy SDK)
Source: Dev.to
The problem we kept seeing
Product, marketing, and CX teams want on‑site feedback, NPS, and lightweight announcements (changelog nudges, maintenance banners, promos) on real pages—marketing sites, docs, and product surfaces.
Engineering teams want that signal too, but they rarely want another heavy client SDK or a multi‑week integration just to ship those surfaces.
We therefore biased toward the most boring integration the web already supports: a small script + a widget on the page.
What “embed‑first” means here
The goal is minutes to first event, not sprints.
Teams create a widget in a dashboard—feedback, NPS, or announcement—copy an embed snippet, and drop it on a page. The runtime loads config and styles from a public API, renders the UI, and sends events and responses back through the same API surface.
All three widget kinds share the same integration model, which matters operationally: one security story, one performance budget, one versioning strategy.
Why a script embed is a feature (and a liability)
The good
- Works on static sites, WordPress, Next.js, and legacy stacks—anything that can output HTML.
- Lets teams iterate placement and messaging without always blocking on a full app release (within reason).
- Matches how B2B tools get adopted: prove value on one page, expand.
The hard parts (what engineers will ask about)
- CSP and nonce patterns
- Pinning / versioning expectations for script and CSS
- Data flow: what you collect, retention, export, deletion
- Performance: payload size, network chatter, and impact on Core Web Vitals
The difference between a neat demo and something that survives a review is mostly discipline here—not UI polish.
Stack choices (high level)
The dashboard side is a familiar SaaS shape:
- Next.js (App Router) for the product
- Turso (libSQL) + Drizzle for persistence
- Clerk organizations for multi‑tenant workspaces
The intentional split: authenticated product vs public widget delivery (edge‑friendly routes, caching, rate limits), because customer sites will request assets and config from all over the world.
Nothing here is “novel for novelty’s sake”—it’s chosen for iteration speed, tenant isolation, and a path toward real B2B expectations (auditability, limits, operational maturity).
What I’d tell my past self
- Treat the widget runtime like a mini product: accessibility, focus management, mobile support, and “don’t break the host page” beat flashy animations.
- Write the threat model early—even a one‑pager. Embeds mean you’re inside someone else’s security story.
- Version everything: config schema, CSS, loader behavior. Customers will cache; you will ship fixes.
- Collect the minimum viable telemetry—your customers need analytics, but “log everything” is how you lose trust.
Where we are now
Saytics is free to use today while we learn what limits and a future Pro tier should look like.
If you’re building something similar—or buying tools in this space—I’m especially curious where your bar is for production readiness (SSO, DPAs, residency, SLAs) versus “good enough for marketing.”
Site:
Discussion
- For strict CSP environments: what integration pattern is non‑negotiable—first‑party proxy, nonce’d scripts, something else?
- For announcements specifically: when is an embed acceptable vs when do you insist on first‑party UI only?
Thanks for reading—happy to go deeper in the comments.