Skip to content
Pulse
Explore Demo

Architecture

How Pulse is put together.

A Next.js application on Vercel, a Supabase Postgres database that does the heavy analytical lifting behind Row Level Security, and an AI layer that can only reach data through a small, audited set of tools.

System overview

Browser
  • React Server Components + small client islands
  • Anonymous Supabase session in HTTP-only cookies
  • No API keys, no direct AI calls
Next.js on Vercel
  • proxy.ts refreshes the session and guards app routes
  • Server components call typed RPC wrappers
  • Server actions & route handlers for mutations, AI, imports, reports
Supabase Auth
  • Anonymous sign-ins for the public demo
  • JWT carried to Postgres for RLS
Supabase Postgres
  • ~30 tables, all with RLS
  • Analytics, quality, insight & automation engines in SQL
  • SECURITY DEFINER only for narrow, checked entry points
OpenRouter
  • Called server-side only
  • Model configurable via OPENROUTER_MODEL
  • Responses cached per session

Data pipeline

  1. Step 1

    Raw layer

    Messy exports from four fictional source systems plus user CSV uploads, stored as text exactly as received.

  2. Step 2

    Quality scan

    SQL normalizers detect duplicates, invalid e-mails, mixed date formats, currencies, statuses and orphan records.

  3. Step 3

    Cleaning

    Deterministic rules write a clean_* layer and log every change. Nothing is overwritten in the raw layer.

  4. Step 4

    Business model

    Normalized customers, orders, items, payments, leads and tickets — the only tables analytics read from.

  5. Step 5

    Analytics & insights

    Parameterized SQL functions compute KPIs, breakdowns and anomaly detectors for any date range.

AI tool flow

  1. 1User asks a question in natural language.
  2. 2Route handler authenticates the session, validates input with Zod and applies a DB-backed rate limit.
  3. 3The model (OpenRouter, server-side only) chooses from 17 typed analytics tools — it never writes SQL.
  4. 4Tool arguments are validated against strict JSON schemas, then executed as RLS-scoped Postgres functions.
  5. 5Numbers shown in charts and tables come directly from tool results; the model only writes the narrative.
  6. 6If the model is unavailable, a keyword planner still runs the right tools and the data is shown.

Automations

Rules (inactive VIPs, failed payments, support SLA, refund spikes, sales decline, stalled leads) run inside Postgres. Each run is recorded, creates deduplicated actions and notifications, and is written to the activity log. No external workflow tool is involved.

Security layers

Secrets stay on the server

OPENROUTER_API_KEY is read only in route handlers. No service-role key exists in the app at all.

Row Level Security everywhere

Every table is protected by RLS policies based on organization membership and demo session.

Isolated demo sessions

Each visitor gets an anonymous user. Their writes are scoped to a session id and deleted on reset or exit.

Hardened endpoints

Same-origin checks, body-size limits, Zod validation, rate limiting and a strict Content-Security-Policy.

Explore the demo Back to overview