OOTify — Campus Mental Health

OOTify gives each partner campus its own tenant — branded subdomain, its own curated resource catalog, and its own analytics — while students get a low-friction daily mood check-in, two validated clinical screeners (GAD-7 and PHQ-9), and personalized recommendations routed only to resources their own school has approved.

It was built to close one narrow gap: the long quiet stretch between "something feels off" and "I finally got on the counseling center waitlist." The 2024–2025 Healthy Minds Study of 84,000+ students found 37% with moderate-to-severe depressive symptoms and 32% with moderate-to-severe anxiety, while counseling-center utilization has grown roughly 5× faster than enrollment and average caseloads sit near 120 students per full-time counselor.

OOTify deliberately does not attempt teletherapy, therapist matching, or peer chat. It solves four problems instead: self-assessment, resource discovery, continuity of a student's own 90-day trend, and aggregate visibility for the counseling center director defending a staffing budget. The platform is in live beta with a University of California campus as the pilot — a production tenant seeded with 325 real campus resources across 15 schools, driven by a structured tester-feedback cycle where stakeholders file issues, each is root-caused against the actual code, and fixes ship in tracked phases with dev-update notes back to the client.

Clinically consequential logic is pure and testable. The backend separates routers → services → repos over Motor/MongoDB, and the decisions that actually matter — triage banding, TIPI scoring, small-cohort suppression, recommendation ranking — are deliberately factored into pure functions in the service layer so they can be unit-tested without a database. The triage module carries an explicit note in code that the band→tier mapping is a starting point requiring clinical review before it drives patient-facing routing, which is exactly the boundary a mental-health product should make visible rather than bury.

Multi-tenancy as a single code path. Rather than branching on environment, one ASGI middleware handles production Host subdomains, dev headers, and query params identically, backed by a short-lived TTL cache so tenant lookups don't hit Mongo on every request. The middleware never raises; routes that need tenant context opt in through a FastAPI dependency. A reusable deep-clone script provisions a production tenant from a test one, carrying resources, students, admins, tags, and history.

Testing that matches the risk profile. 38 backend test modules — roughly 9,300 lines of tests against 12,600 lines of application code — with an 80% coverage floor enforced in CI, plus 29 Playwright specs organized by risk. A dedicated safety/ directory covers acute-tier routing, SOS, crisis config, MFA, and clinical disclosure, alongside auth, student, admin, superadmin, and tenant-scope suites that can be pointed at either deployed environment.