Senior Next.js + Supabase Dev — Multi-Tenant AI Coaching Platform

Read the whole brief before applying. Applications that ignore the instructions at the bottom are rejected without reply. WHO WE ARE Semester Student Planner Limited is a UK-registered company selling student success products into universities and colleges in the UK, US and Australia. We have paying institutional customers, coaches delivering in person on campuses, and warm distribution into higher education. We are currently in the Plus Eight accelerator in Perth, Western Australia. We are now building the software layer that sits on top of that delivery. This engagement is that build. For market context: Mainstay, EdSights and Gravyty all sell student engagement software into US higher education at five and six figures per institution per year. We are entering that market with an existing coaching methodology, existing campus relationships and existing revenue, rather than a chatbot with a university logo on it. I am the CEO. I will personally manage this build. I am technically literate. I am not the developer. WHAT WE ARE BUILDING A multi-tenant AI coaching platform for universities. Each institution gets its own branded subdomain, for example unimelb.semestercoach.com, running the same codebase with institution-specific configuration. A student opens their institution's subdomain, signs in with their university email via a magic link, selects from a set of challenge categories, and enters a conversational coaching session powered by the Claude API using our coaching methodology and prompt architecture. The coach helps with study planning, goal setting, habit building and general academic challenges. It captures a simple wellbeing rating during sessions so a student's trend can be tracked across a term. It routes students to that institution's own support services and deep-links out to their existing booking system. It has a defined safeguarding escalation path. Staff get a read-only dashboard showing usage and aggregate wellbeing trends. This is a greenfield build. We have a working proof of concept that validated the coaching interaction, but it is a no-code page with an automation tool behind it and none of it is being carried forward. Our coaching prompt architecture, conversation design and challenge taxonomy already exist and will be supplied to you. Proof of concept, for interaction reference only. Not the thing you are building, and not being migrated: https://www.semesterstudentplanner.com/student-coach-demo-clv-melbourne-resident-coach SCOPE 1. Multi-tenant architecture. Tenant configuration covering branding, allowed email domains, term dates, local support services directory, external booking URL and crisis contacts. Postgres row-level security for tenant isolation. Wildcard subdomain routing resolving to the correct tenant. Onboarding a new institution must become a configuration task, not a development task. This is the single most important outcome of the engagement. 2. Magic-link authentication with per-tenant email domain allowlisting. No SSO in this phase. 3. Identified longitudinal data capture. Unique users per tenant, session history, wellbeing ratings stored over time, event tracking on challenge category selection. 4. Structured challenge selection flowing into a streaming chat interface, with the selected context carried into the conversation. 5. Support service routing from tenant configuration, with deep-links out to the institution's existing booking system. 6. Safeguarding and escalation. Risk detection on messages, deterministic hard-coded escalation surfacing tenant crisis contacts and local crisis lines, clear handoff rules, audit logging of escalation events. This is non-negotiable and is a gate on every sale we make. 7. Read-only staff dashboard. Active users, return rate, session volume, aggregate wellbeing trend, most-selected challenge categories, keyword summarisation. THE STACK, ALREADY DECIDED - TypeScript throughout - Next.js, App Router, hosted on Vercel with wildcard subdomain support - Supabase for Postgres, Auth and row-level security - Claude API called server-side only, using the Vercel AI SDK for streaming - Model routing: Haiku for classification, triage and tagging; Sonnet for the coaching conversation - Prompt caching structured so the shared coaching system prompt sits first and is cacheable across all tenants, tenant config second, conversation history last - Transactional email via Postmark or Resend on a dedicated sending domain, with SPF, DKIM and DMARC configured - Background jobs via Vercel Cron or Supabase pg_cron - shadcn/ui on Radix primitives, for WCAG 2.1 AA accessibility from the start - Sentry for error monitoring, PostHog for product analytics - Database migrations via Supabase CLI, versioned in the repo - Architecture must support deploying identical regional cells, one US and one Australian, for data residency. Build the boundary in even if only one cell deploys initially. We are open to a developer proposing an alternative architecture, but only where you have directly built comparable systems for enterprise education clients, and only where you set out the reasoning in your application rather than after work begins. Informed challenge from someone who has shipped this before is welcome. Substituting your preferred tooling after kickoff is not. Two things we will check specifically, because they are where multi-tenant builds fail: - The Supabase service_role key must never be used for user-data operations. Server-side code acts with the user's JWT so row-level security applies. service_role is for provisioning only, with explicit tenant filters. - Per-user and per-tenant token usage logging, rate limiting and spend caps, built in from day one. Not added later. EXPLICITLY OUT OF SCOPE - SSO, SAML or Shibboleth - Native mobile apps. Responsive web only. - Building a booking or scheduling engine - Calendar integrations - Anything requiring a central IT security review to deploy - Any migration of the existing proof of concept Applicants who quote for these have not read the brief. COMMERCIALS AND CONSTRAINTS - Timeline: 6 to 8 weeks from kickoff, staged milestones, immediate start - Budget: USD 12,000 total, fixed price, paid against the milestones below - Hard date: first institution live with a few hundred students by mid-September - Trajectory: 10 institutional pilots with a few thousand students each within 12 months - Management: I am the single point of contact and decision maker, available across AU, UK and US time zones. Meetings within AU or UK timezone will be preferable. - IP: all code, accounts and IP belong to the company, in our repo and our Supabase project from day one. NDA before repo access. Handover documentation is a paid milestone deliverable. MILESTONES Each milestone is paid on a demonstrable working outcome on a staging environment, not on a progress report. MILESTONE 0 - TECHNICAL PLAN AND SETUP - Days 1 to 3 - USD 750 Written architecture plan, repo initialised, Supabase project and Vercel deployment pipeline live, staging environment reachable. MILESTONE 1 - TENANCY AND AUTH FOUNDATION - Weeks 1 to 2 - USD 2,750 Tenant data model, row-level security policies with tests proving isolation, wildcard subdomain routing, magic-link login with per-tenant domain allowlisting, working on two test subdomains. MILESTONE 2 - COACHING CORE - Week 3 - USD 2,500 Challenge category selection flowing into streaming chat, Claude API called server-side with model routing and prompt caching, full session and message persistence tied to identified users. MILESTONE 3 - SAFEGUARDING AND MEASUREMENT - Weeks 4 to 5 - USD 2,750 Risk detection, deterministic escalation surfacing tenant crisis contacts, escalation audit logging, wellbeing rating capture and storage, challenge category event tracking, per-user rate limiting and token spend logging. MILESTONE 4 - ROUTING AND STAFF DASHBOARD - Week 6 - USD 2,000 Support services directory from tenant config, booking deep-links, read-only dashboard covering active users, return rate, session volume, aggregate wellbeing trend and category breakdown. MILESTONE 5 - HARDENING AND HANDOVER - Week 7 - USD 1,250 Accessibility pass against WCAG 2.1 AA, Sentry and PostHog live, two real tenants provisioned end to end, handover documentation and a recorded walkthrough. Three principles behind this ordering: - Tenancy and isolation come first, because they cannot be retrofitted - Safeguarding ships before any student uses the product, not after - Handover documentation is the final paid milestone THIS IS A GOOD FIT IF You have personally built and shipped a multi-tenant B2B SaaS product on Postgres with row-level security, you are comfortable owning architecture decisions and defending them, and you can commit real hours to a 7-week sprint rather than fitting it around four other contracts. THIS IS NOT A FIT IF You are an agency bidding on behalf of a team, you are looking for open-ended hourly work, or your portfolio is mostly landing pages, WordPress and Shopify builds with one LLM wrapper on top. HOW TO APPLY Four things. All four, or I will not read the application. 1. Start your reply with the word TENANT-FIRST. This is how I know you read to the bottom. 2. Open the proof of concept link above. Tell me one thing you would change and why. Product reasoning, not "I would rebuild it in Next.js" - I already know that. 3. Name one multi-tenant system you have personally built. Tell me how tenant isolation was enforced at the database layer and how you proved it held. 4. Tell me your realistic weekly hours for the next 8 weeks and what else you have running. Keep it under 400 words. A two-minute Loom is welcome in place of prose. Templated proposals, agency boilerplate and anything that opens with "I am excited about your project" are rejected on sight.