AI Freelancer Ops: Backend-First SaaS on Supabase + Stripe
Lachezar Atanasov
Backend-First SaaS With Supabase, Stripe, Edge Functions, and Realtime
Snapshot
Project type: self-initiated product engineering case study
Goal: prove a production-ready backend pattern for multi-role SaaS products that need shared auth, billing, secure server-side workflows, and realtime state
My role: product architecture, schema design, frontend implementation, Supabase integration, Stripe billing flow, Edge Functions, and deployment
Stack: Next.js 16, TypeScript, Supabase, Postgres RLS, Stripe, Vercel
Live app: https://ai-freelancer-ops.vercel.app
GitHub repo: https://github.com/lachezarat/ai-freelancer-ops
Project Context
This was built as a portfolio-ready SaaS case study for the kind of product work that becomes difficult after the UI is finished:
multiple user roles sharing one backend
row-level access boundaries across related data
Stripe subscriptions and plan-aware entitlements
secure server-side handling of sensitive integrations
realtime state shared across different product surfaces
Instead of treating those concerns as placeholders, the goal was to ship a working system that demonstrates the full backend spine.
Visual Snapshot
Homepage
Sign-in Flow
Architecture
Billing + Entitlement Flow
The Problem
Many SaaS products need the same foundation:
one auth system across multiple product surfaces
clear access rules between different user types
subscription state that comes from backend truth, not redirect assumptions
secure handling of Stripe and AI provider secrets
a data model that can support realtime updates without introducing a second system
The challenge in this project was to build all of that on one shared backend without turning the schema, permissions, or billing logic into something fragile.
What I Built
1. Shared auth across multiple product surfaces
The app supports a freelancer workspace, client portal, and admin surface on a single Supabase project. Rather than splitting those into separate products, the app resolves viewer identity and workspace context from one shared auth model.
That pattern is useful for any product that needs multiple user experiences without duplicating the backend.
2. RLS on a relational, multi-role schema
The data model covers workspaces, profiles, clients, projects, milestones, deliverables, comments, subscriptions, and AI tool runs. Access is scoped through relational rules and server-side loading paths, not frontend assumptions.
What that demonstrates:
access control is designed into the schema
different user types can safely share the same backend
role overlap is handled at the data layer, not with cosmetic UI checks
3. Stripe checkout, portal, and webhook sync
The billing system includes:
checkout session creation
customer portal access
webhook-driven subscription updates
plan-aware entitlement checks
The key design decision is that billing truth comes from webhook synchronization, not from optimistic client redirects.
4. Edge Functions as the trust boundary
Sensitive actions run through Supabase Edge Functions, including:
Stripe orchestration
webhook handling
AI provider requests
That keeps Stripe secrets, service-role access, and provider API keys out of the browser.
5. Realtime activity on the same data model
The workspace and portal both receive live activity updates through Supabase Realtime. This sits on top of the same relational model used for the rest of the product, which keeps the system consistent and easier to reason about.
Key Backend Decisions
Webhooks are the source of billing truth
Subscription state is written from Stripe webhook events into Supabase, and feature access is derived from that synced state.
RLS follows the relationship graph
Permissions are shaped around who owns a workspace, which client is assigned, and what records belong to that graph. That keeps access rules close to the data model.
Secrets stay server-side
Stripe and AI calls are proxied through trusted server-side boundaries rather than exposed directly to the browser.
Shared auth is more valuable than duplicated apps
A single auth and data model supports multiple product surfaces while keeping identity, billing state, and entitlements consistent.
Outcome
This project is live, deployed, and useful as proof of:
backend architecture for multi-surface SaaS products
Supabase schema design and row-level security
Stripe subscription lifecycle handling
secure server-side integration patterns
deployment-aware product engineering
It is strongest as a portfolio piece for backend-heavy full-stack roles, Supabase or PostgreSQL work, Stripe integration projects, and early-stage SaaS product engineering.
Short Summary
I built and deployed a backend-first SaaS on Supabase, Stripe, and Vercel that combines shared auth, multi-role RLS, webhook-driven billing, Edge Functions, protected AI workflows, and realtime activity on one backend. The point of the project was to show the parts of product engineering that usually create risk in real SaaS systems: access control, entitlements, secrets, billing truth, and deployment boundaries.
Like this project
Posted Mar 19, 2026
Built a live multi-role SaaS with shared auth, RLS, Stripe billing, Edge Functions, protected AI workflows, and realtime updates.
Likes
1
Views
18
