EmbedProof

EmbedProof helps founders collect customer testimonials, choose what to publish, and place them on an existing website. I focused on the whole path from a submitted quote to a widget someone can preview and embed.

Explore the example: Studio North shows an EmbedProof script widget on a fictional business website. Its studio, work, pricing, and testimonials are illustrative, not customer or adoption evidence.

My contribution

I owned the product, interface design, and full-stack implementation, with assistance from AI agents. My work connects collection forms, moderation, widget customization and embedding with account access, subscriptions, and uploaded avatars.

Decision: distinguish customer submissions from owner publishing

Customer submissions through the public collection form start as pending. The owner reviews them, and the public widget selects only approved testimonials. Owner-created quotes and CSV imports can start approved: those are deliberate publishing actions by the account owner, rather than unreviewed public submissions.

This distinction keeps the collection form approachable without giving visitors control over what appears on someone else’s website.

Decision: use one renderer for preview and publication

The dashboard preview, public script embed, and Studio North example use the same renderer. Owners can choose grid, masonry, carousel, marquee, or list layouts, with available layouts depending on their plan.

The preview runs in a sandboxed iframe. On the host website, the script inserts a widget with a Shadow DOM boundary to isolate its styling from the surrounding page. The renderer includes keyboard controls and reduced-motion handling for animated layouts. Reusing it reduces the differences between what an owner previews and what their visitors see.

The public endpoint checks widget availability and required branding against the owner’s subscription state. Tests cover avatar URL handling, hostile quote text, motion controls, and branding for free, paid, active-trial, and expired-trial accounts.

Decision: keep billing tied to account identity

Stripe checkout and the billing portal verify that the stored customer belongs to the signed-in account. They use the account’s immutable identifier rather than adopting a billing customer because an email address matches. The test suite includes ownership mismatches and provider failures.

This makes account identity part of the billing design, alongside the checkout interface and subscription webhook handling.

Decision: treat uploaded media as account data

The current implementation uses Next.js 16 and React, Neon Postgres with Drizzle, Neon Auth, and Neon Object Storage. Avatar uploads use the storage service’s S3-compatible API, with server-side branch checks and validation of uploaded files and rendered avatar URLs.

Neon has replaced the earlier Supabase and Vercel Blob setup. Upload and cleanup code tracks media references so replacing or deleting a quote can be handled separately from deleting a stored image. Storage operations still need verification against the intended deployment and provider configuration.

Outcome and current scope

The public site introduces the product, and Studio North makes the embed visible in the context of another website. That example uses the production renderer with fictional data; it does not exercise private account, payment, or customer-storage flows.

This case study describes the current implementation. Recent local changes still require release-specific verification, so a public example is not a claim that every account and billing path has been checked in production. The former answer-engine visibility monitor has been retired; the current product focus is testimonial collection and widgets.