CASE STUDY · /feedback-central

Feedback Central

A multi-tenant feedback SaaS — embeddable widget on the user side, JWT-protected triage dashboard on the team side.

ROLE

Solo Lead Engineer · Dual-Auth Architecture

TIMELINE

2025

TEAM

1 (solo)

STATUS

Production

Overview

Any client app drops a single script tag → end users get a feedback widget; the team gets a triage dashboard. Two completely isolated attack surfaces share zero auth state.

The widget is a standalone ~10KB ES5 script — no build step, no framework. It exposes window.FeedbackWidget.{open, close, configure} so host apps control placement entirely.

The problem

Tools like Canny lump end-user submission and team triage behind the same auth — meaning user widgets either require login (high friction) or rely on weak anonymous tokens that leak the full API.

What I built

Dual-auth: x-feedback-app-key (public per-app key) for widget; JWT in httpOnly cookies for dashboard
Standalone ES5 widget — drops in via script tag, no build, no framework lock-in
Multi-tenancy: orgs own multiple apps, each with its own key, theme, and feedback stream
Per-app status workflow: new → open → in_progress → resolved / wont_fix
Idempotent SQL migration runner with _migrations tracking table — safe to re-run
Type filters (feedback / bug / suggestion), full-text search, per-app analytics

Tech stack

Node.jsExpressMySQL 8EJSTailwind CDNbcryptjsJWT

Outcome

Live in production for multiple tenant apps. Hard isolation of attack surfaces means a leaked widget key can't touch dashboard endpoints — and a compromised dashboard cookie can't submit fake widget data.

Want this in your stack? Let's talk.

Email Athar Back to all projects