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 THIS IS STAGE 1 OF A THREE-STAGE BUILD Read this section carefully. It explains why some requirements below look heavier than an MVP needs. Our buyers are universities. Selling to them eventually requires formal compliance artifacts: an Accessibility Conformance Report against WCAG 2.1 AA, a completed HECVAT security questionnaire, and in some US states a cloud security certification. We are not attempting any of that in this engagement, and you are not being asked to deliver it. What we are asking is that Stage 1 does not foreclose Stage 2. The test we have applied to every requirement is simple: can this be added later without a schema migration or a redesign? If yes, it is out of scope. If no, it is in scope now. In practice that means a handful of extra tables, columns and write paths, not extra features. It is a few days of work, not weeks. If you think we have got that judgement wrong on any specific item, say so in your application - that is a conversation worth having before we start, not after. SCOPE 1. Multi-tenant architecture. Tenant configuration covering branding, allowed email domains, term dates, local support services directory, external booking URL, crisis contacts, safeguarding escalation address, declared escalation monitoring window, and a flag for whether the tenant permits under-18 users. 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. Separate staff role model with row-level security policies keyed to it. 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. The student-facing response must be immediate, deterministic and hard-coded: tenant crisis contacts and local crisis lines surface on screen, in session, every time, and never depend on anyone reading a notification. A secondary escalation notification goes to the tenant's configured address, carrying minimal content only - student identifier, timestamp, category and an authenticated link back into the platform, never the transcript in the email body. Delivery is confirmed and logged, and delivery failure raises an alert to us. Where an escalation falls outside the tenant's declared monitoring window, crisis lines are weighted more prominently in what the student sees. All escalation events are audit logged. This is non-negotiable and is a gate on every sale we make. 7. Read-only staff dashboard, aggregate only. Active users, return rate, session volume, aggregate wellbeing trend, most-selected challenge categories. No individual student drill-down in this phase - this is a deliberate decision, not an omission. Aggregate figures must apply small-n suppression so that cohorts below a threshold are not displayed, since small cohorts re-identify individuals. 8. Built so it can be certified later. All of the following are schema-level or write-path concerns that cannot be retrofitted cheaply. None of them require UI in this phase: - Retention and deletion: soft-delete columns, defined cascade behaviour, retention period fields. Per-student deletion and per-tenant deletion on contract termination must be executable, even if only by script. - Access audit logging: a log table and a write path on every read of identified student data, not only on escalations. - Constrained theming: only a defined set of theme tokens is tenant-configurable, so that colour contrast can be validated automatically in a later phase. - Analytics configured privately: PostHog initialised with session recording and autocapture disabled, and no PII in event payloads. - Sub-processor register: a markdown file in the repo listing every third-party service the application depends on, maintained as dependencies are added. 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, behind a thin provider abstraction rather than bound directly to one SDK - we may later need to route through a different hosting path for compliance reasons and that should be a config change, not a rewrite - 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 - One deployment cell only in this phase, hosted in Australia. A cell means a complete independent copy of the stack - its own Supabase project, its own Vercel deployment - serving only the tenants whose data must reside in that region. We will add a US cell later. Build the boundary in now: no hardcoded region assumptions, no cross-cell references, no shared global tables holding student data, and migrations that run against any cell from the same repo. Accessibility is a real requirement, not a checkbox. Radix gives you accessible primitives; it does not give you an accessible application. Two areas need explicit attention: streaming chat output, which needs correct ARIA live region handling, sensible focus management and an accessible stop control; and keyboard traversal across the full session flow. The accessibility pass at handover means automated scanning plus manual keyboard testing plus screen reader testing on NVDA and VoiceOver, not a Lighthouse score. 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 - Individual student drill-down in the staff dashboard - A second regional deployment cell - Admin UI for deletion, retention or audit log review - the schema and write paths only in this phase - Automated colour contrast validation - the constrained theme token set only in this phase - Producing an Accessibility Conformance Report, completing a full HECVAT, or any cloud security certification work - 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, with Stage 2 work following on from this engagement - Management: I am the single point of contact and decision maker, available across US and Perth time zones - 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 including escalation address, monitoring window and under-18 flag. Row-level security policies with tests proving isolation. Staff role model with policies keyed to it. Retention, soft-delete and cascade behaviour defined in the schema. Access audit log table and write path. 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 behind a provider abstraction 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 3,000 Risk detection. Deterministic in-session escalation surfacing tenant crisis contacts, with monitoring-window-aware weighting. Escalation notification to the tenant address with minimal content and authenticated link, delivery confirmation and failure alerting. 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 1,750 Support services directory from tenant config, booking deep-links, read-only aggregate dashboard covering active users, return rate, session volume, aggregate wellbeing trend and category breakdown, with small-n suppression applied. MILESTONE 5 - HARDENING AND HANDOVER - Week 7 - USD 1,250 Accessibility pass against WCAG 2.1 AA using the method described above. Sentry and PostHog live, PostHog configured with session recording and autocapture off. Sub-processor register complete. Two real tenants provisioned end to end. Data flow diagram and data dictionary. The technical sections of the HECVAT security questionnaire completed from the build - we will supply the workbook and identify which sections are yours. Handover documentation and a recorded walkthrough. Four principles behind this ordering: - Tenancy and isolation come first, because they cannot be retrofitted - Safeguarding ships before any student uses the product, not after - Compliance groundwork goes in the schema now and gets its interface later - 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.