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.
So we biased toward the most boring integration the web already supports: a small script + a widget on the page.

This is a short build log for Saytics—what we optimized for, the tradeoffs that fall out of an embed-first model, and what I’d do differently if I started again.

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) Third-party JS inherits a trust conversation:
• 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, 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.

4. 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: saytics.com

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.