How ShiftBeacon is structured

ShiftBeacon ships on Next.js App Router with Supabase for auth, data, and storage. Server Actions are used for mutations so you can deploy to Vercel without managing a separate API tier.

Row-Level Security policies are enabled from the first migration. Every record ties back to an organization so the same database safely powers every tenant subdomain.

Marketing traffic stays on shiftbeacon.ca while owners work from app.shiftbeacon.ca. Provisioned tenants live on {slug}.shiftbeacon.ca with optional demo and API hosts.

The included middleware inspects the Host header, forwards known static assets untouched, and rewrites requests to the marketing, control-plane, or tenant routes. Sign-in and signup attempts on the marketing host redirect to the control plane automatically.

Organizations own schedules, shifts, time entries, paystubs, and memberships. Every table includes an org_id column with foreign-key and unique constraints that line up with the RLS policies.

Memberships capture a user’s role (owner, manager, employee) and status. Helper queries return the active membership for the current tenant so layouts and navigation render role-appropriate content.

Owners sign up on the control plane, reserve a subdomain, and upload branding before inviting teammates. Once satisfied they can activate their tenant and share the {slug}.shiftbeacon.ca URL with employees.

Demo environments use the same flow with a dedicated host so you can showcase the product without exposing production data.

Add Supabase project credentials, run the Drizzle migrations, and connect PostHog, Sentry, and Resend. From there you can start fleshing out schedule editing, final hours, and paystub delivery inside the tenant app.

When you are ready to monetize, wire up Stripe subscriptions in the control plane and enforce plan limits inside your server actions.