Next.js + Supabase Portal & CRM

What we do We run multi-day residential retreats. Our guests go through a long, high-touch intake — an enquiry, a discovery call, a medical screening, signed agreements, a deposit, a room and date assignment, prep work, a final payment, then a post-retreat integration program. Right now that process lives across a website form, a scheduler, Jotform, email, bank transfer receipts, and spreadsheets. It works because our team is careful. It won't keep working as we grow, and the failure modes are bad ones: a guest skipping a required step, a room double-booked, a payment we can't verify. What we need built A single system of record with two faces: A client portal that reveals only what's relevant to where the guest is in the process. Someone who hasn't completed their discovery call shouldn't see the deposit screen. Someone who hasn't paid a deposit shouldn't see a confirmed date. An internal staff dashboard — pipeline views by status, a profile per guest (intake data, documents, medical uploads, payment ledger, notes), a room-and-date capacity board, verification queues, and a full audit log. Stack Next.js (App Router), TypeScript, Tailwind Supabase — Postgres, Auth (magic link), Storage, Row Level Security Deployed on Netlify or Vercel Transactional email via Resend or Postmark Integrations: Jotform webhooks, a scheduling tool (Cal.com or similar), and a community platform via SSO We're open to being argued out of any of this, but you'd need a real reason. What already exists A complete Postgres schema is written and reviewed. 17 tables, a status state machine enforced in the database via a transition_client() function, an audit trigger on every sensitive table, and 25 row-level security policies. We'll share it with shortlisted candidates. This matters for two reasons. It means the hardest design decisions are already made, so you're building against a spec rather than inventing one. And it means we'll be able to tell quickly whether you actually understand RLS and Postgres functions, or whether you've only ever used Supabase as a JSON store. You're welcome to push back on the schema. We'd rather hear "this constraint will cause you problems in month six" now than discover it later. Scope, in order We want this built in stages, and we want to run real guests through each stage before the next one starts. Identity, status machine, audit log, staff pipeline view. Auth, roles, the transition function wired to a UI, and a working pipeline board. Nothing else. Onboarding artifacts. Jotform webhook ingestion, document upload with a staff review queue, medical upload with restricted access and its own review flow. Payments. Bank transfer instructions, receipt upload, staff verification, a two-entry ledger, and time-based reminders. Inventory. Retreat dates, rooms, soft holds, conflict prevention, and a staff capacity calendar. Content gating and post-retreat integration. Prep materials unlocked by status, integration call booking, group call calendar, community SSO. Milestone 1 is the whole job interview. If it goes well we'd like to keep going through 5 and then keep you on retainer for maintenance. Handling sensitive data Guests upload medical documents as part of screening. This is not a build where security is a nice-to-have. We need private storage buckets, signed URLs, role-separated access, and an audit trail — and a developer who treats all of that as normal rather than as an imposition. You'll sign an NDA. If you have experience with HIPAA-adjacent or otherwise regulated builds, say so. Who we're looking for Shipped and maintained at least one production app on Supabase with meaningful RLS — not a tutorial project Comfortable writing Postgres functions, triggers, and policies, not just querying from the client Can read a schema and tell us what's wrong with it Communicates in writing, clearly, without needing to be chased Available for a 3–4 month engagement with real overlap with US Eastern hours Nice to have: experience with booking, inventory, or CRM systems; work with a small business where you were the only engineer. To apply Please skip the template proposal — we won't read past the first paragraph of one. Answer these instead: Describe a Supabase project you built where row-level security did real work. What were the policies protecting, and what got hard? We enforce our status transitions in a Postgres function rather than in the application layer, and we've revoked direct writes to the status column. What do you think of that approach, and where would it bite us? How would you handle a bank transfer payment flow where a staff member uploads and verifies a receipt manually, and the record must be immutable afterward? What's your availability over the next four months, and what else are you carrying? Include one link to code we can actually read. A repo, a PR, a Gist — anything real beats a portfolio site. Budget and terms to be discussed We pay for a small paid test task before any larger commitment, and we're happy to pay a fair rate for someone who's clearly good. We're not looking for the cheapest bid.