PRD for Supabase project: Structure & fully filled example
This page breaks down how to structure a PRD for a Supabase project. You'll get a concrete checklist, tradeoff comparison, and a real-world PRD example—focused on Supabase-specifics like tables, RLS, storage buckets, and Edge Functions. Use it to brief your team, align with engineers, and avoid costly rewrites.
What this is
A PRD for Supabase project specifies every product requirement with the platform's architecture in mind—tables, Row-Level Security (RLS), storage, and custom server logic via Edge Functions. Unlike generic PRDs, it calls out which tables need strict RLS, which buckets have public vs. private policies, and where Edge Functions should be orchestrated. PMs often leverage Supabase’s schema editor, GitHub for versioning, and integration setups with tools like Next.js or Vercel to match requirements to reality. Handling these up front can save weeks of backtracking.
Compared to alternatives
| Option | Best for | Trade-off |
|---|---|---|
| Supabase PRD (Checklist-first) | Engineering-driven teams building on Supabase from day 1. | Harder to reuse for non-Supabase architectures. |
| Lovable's Modular PRD (Component-based) | Teams iterating quickly with frequent feature pivots. | Less specific on infra details; risk of missing Supabase quirks. |
| Notion Document PRDs | Early idea validation and async stakeholder alignment. | Easy to get vague; lacks technical enforceability. |
| Cursor-embedded PRD with diagrams | Visual thinkers working through relationships and flows. | Doesn't force you to specify RLS or storage buckets precisely. |
| Traditional Agile User Stories | CI/CD teams focused on velocity over strict requirements. | Can create ambiguity for Supabase-specific implementation. |
A real example
Product: CourseBoard – Community-driven microlearning platform.
Objective: Enable creators to publish bite-sized video courses, while letting users comment, bookmark, and access content via web/mobile.
Tables & RLS:
- users: id (uuid/PK), email, role ('creator'|'learner'), onboarding_complete (bool). RLS: Users can only see/edit their own profile.
- courses: id (uuid/PK), creator_id (FK: users), title, summary, published (bool), created_at. RLS: Only creator can write; published=true for learner read.
- videos: id, course_id (FK), s3_url, duration_sec, ordered_index. RLS: Only course owner uploads; anyone enrolled can read after publish.
- comments: id, user_id (FK), video_id (FK), body, created_at. RLS: Only users can write/read their own; public view on published content.
Storage & Buckets:
- videos-bucket: For .mp4 uploads. Policy: Creator write/modify, learners read-only after course published. Max size: 500MB/video.
- avatars-bucket: Publicly readable, max 1MB per image.
Edge Functions:
- generate-transcript: Triggered on video upload, generates captions. Timeout: 60s. Calls Claude Code API. Only trigger on new videos in videos-bucket.
- notify-creator: On new comment, sends real-time notification (Supabase functions hooks, integrates with external email using Vercel Edge).
KPIs:
- Onboarding should take <3 minutes/user.
- Video upload > success rate: 99% over 30 days.
- Edge function median response under 800ms.
Out of Scope:
- No live streaming, no paid subscriptions for v1.
Dependencies:
- Supabase, Vercel, Next.js, Stripe (future for payments), Claude Code (for transcription). All source tracked in GitHub.
Milestones:
- Schema + RLS complete by week 1 (hand-off to eng).
- Buckets/policies working with integration tests by week 2.
- Edge Functions live in staging by week 3.
- Alpha complete: 50 real course uploads, 200+ registered users by week 4.
How to use this
- Define core user flows and Supabase objects early: List every top-level action (sign up, upload, comment, etc.) and map directly to tables, considering RLS policies up front. Specify which user roles can access what.
- Detail storage buckets and access rules: Name each bucket (e.g., user-avatars, videos), define file types, limits, and write down the intended bucket policies (who reads/writes, any public URLs, quotas).
- Outline all Edge Function triggers and contracts: For every backend customization, specify: trigger condition, function timeout, input/output data shapes, and any dependencies (like Claude, Stripe, or Vercel integration).
- Write measurable KPIs for each feature: Tie requirements to concrete metrics: upload speed targets, auth friction, max cold start times. Document them in the PRD to keep build discussions honest.
- Draft hand-off checklist and milestone plan: Create hand-off requirements for engineering, QA, and design—include a step-by-step milestone roadmap for first ship. Track schema and policies in GitHub or Replit.
- Link to internal/external templates for completeness: Reference other See templates and past examples like 'TimeLogger app PRD' or e-commerce store PRDs so newer engineers don’t miss context-specific gotchas.
FAQ
How do I document RLS for a Supabase PRD?
Include a section under each table listing every ROW-level policy. For each, specify who can 'select', 'insert', 'update', and 'delete'—write these in terms engineers can translate to actual SQL policies. Example: 'Only course owner can insert into videos.'
Should storage buckets be in the PRD or in tech spec?
For a Supabase-focused stack, always summarize critical storage buckets and policies in your PRD. It sets alignment before coding. Use the tech spec for specific policy SQL or complex triggers, but the PRD covers intent and business rules up front.
When do I need Edge Functions versus straight SQL?
If logic can't be handled with SQL triggers and you need to call external APIs or process data (like video transcoding), use Edge Functions. Note these triggers and their high-level contracts in your PRD so engineering doesn't miss them in the architecture phase.
Can I use a generic PRD template for a Supabase project?
You can start with a generic template, but expect extra work documenting tables, RLS, buckets, and functions. Fastest path: use a Supabase-specific checklist, or a time-tested example from the PRD template hub so you don't overlook platform nuances.