The practical idea
Start from buyer value, not tool excitement.
Supabase can provide accounts and private data, Vercel can host the Next.js app, and a domain can point to the finished deployment. You do not need to perform each low-level step by memory.
Your job is to tell Codex who may see each screen, what data is private, what happens when a service is unavailable, and what proof must pass before a client receives access.
Worked example
One narrow service, made inspectable.
- Buyer
- A small video-production agency
- Repeated pain
- Clients ask for status updates across email threads.
- Offer
- A tiny authenticated project-status portal with fictional sample projects for the pilot.
- Proof
- One client sees only their fake project, an admin sees the fake portfolio, and unauthenticated access is denied.
- Human approval
- The agency approves roles, fields, retention, domain, and production data migration separately.
Do this in order
A four-step operating path.
- 1
Brief the screen and roles
Name the user, the one job they perform, and exactly which records each role may view or change.
- 2
Ask the agent for data and access rules
Require Supabase tables, row-level security, private storage, and server-side access checks in plain English.
- 3
Use preview deployment
Deploy fictional data to a Vercel preview first. Keep production keys and customer data out of previews.
- 4
Connect domain after QA
Only after auth, access, mobile layout, backups, and error handling pass should the approved domain point to production.
Prompt for your agent
Replace the brackets, then ask Codex to help.
Act as a senior Codex delivery agent. Build the smallest secure client app for this workflow: [WORKFLOW]. Users and roles: [ROLES] Private records: [DATA] One required screen: [SCREEN] Human approval or admin action: [APPROVAL] Use the existing project's Next.js patterns. Propose Supabase tables and row-level security before applying them. Use fake seed data only. Add server-side authorization, private storage where needed, clear empty/error states, and mobile layout. Prepare a Vercel preview QA checklist and domain handoff plan. Never touch another Supabase project, Vercel project, domain, or live customer record. Stop for exact approval before external account mutations.
Ready check
Keep these five facts visible.
- Each role has an explicit access rule.
- Paid or private data is checked server-side.
- Fake data is used in preview.
- Secrets stay server-only.
- Domain connection waits for QA.
Avoid
Common ways this goes wrong.
- Treating login as complete authorization
- Putting a service key in browser code
- Using production data in preview
- Connecting the final domain before access tests
Primary references
Review the source, not just our summary.
Products and platform rules change. These links are the starting point for the next source refresh.
Published by Agentic Systems Academy Team. Educational information only. No client, income, ranking, or platform outcome is guaranteed.