NXTLVL. — Developer Reference

01 — Platform Overview

Three Apps. One Platform.

NXTLVL OS is a suite of three standalone applications sharing unified auth.

Each app is independently deployable but shares a common design system, auth layer, and database infrastructure. The model is Google Workspace — one login, one feel, purpose-built apps. All three apps live in a Turborepo monorepo with shared packages for UI, auth, database schemas, and config.

Build First

Intelligence

Revenue Intelligence — healthcare-native financial analytics. The NXTLVL layer, available to all workspace types. This is what the NXTLVL Membership delivers.

Next.js App Router + Supabase

Build Second

Sales

Practice Sales System — POS, patient memberships, optical retail. Workspace-aware: surfaces optical features for VZN, dental features for DNTL, or both for DNTL.VZN.

Next.js App Router + Medusa + Stripe

Build Last

EHR

Patient record aggregation from external PMS sources. Initially read-only compilation of patient data across systems. FHIR-native from day one.

Next.js App Router + Aidbox (FHIR)

02 — Tech Stack

Every technology choice maps to a specific responsibility. No overlap, no gaps.

Layer

Technology

Purpose

Framework

Next.js App Router

All three apps — SSR, Server Actions, file-based routing

Monorepo

Turborepo

Build orchestration, shared packages, caching

Auth

Clerk

Multi-tenant workspace-aware identity — native org/membership support

App Database

Supabase + Drizzle ORM

Non-PHI data — orgs, users, workspace config, analytics metadata

Clinical Database

Aidbox (FHIR)

PHI and patient records — EHR app only. HIPAA boundary by design.

Commerce

Medusa

Headless POS, patient memberships, optical retail — Sales app

Payments

Stripe

Billing and payment processing via Medusa

UI Base

shadcn/ui + Tailwind

Shared component foundation in packages/ui

03 — Monorepo Structure

Turborepo manages the monorepo. Apps are standalone. Packages are shared.

 nxtlvl-os/  
   apps/  
     intelligence/ # Revenue Intelligence — all workspaces 
     sales/ # POS + memberships — workspace-aware 
     ehr/ # Patient data aggregation — built last 
   packages/  
     ui/ # Shared design system + workspace theming 
     auth/ # Clerk wrapper — workspace-aware sessions 
     db/ # Drizzle ORM + Supabase Postgres schemas 
     config/ # Shared ESLint, TSConfig, Tailwind base 

04 — Workspace Model

Configuration, Not Identity

Workspace is a feature flag array on an org — not a separate tenant.

A practice logs in and sees the features their workspace config unlocks. Upgrading from DNTL to DNTL.VZN requires adding 'vzn' to the workspace array. No migration, no new tenant, no data loss. The Sales app reads the workspace array and unlocks the appropriate feature set automatically.

{ workspaces: ["dntl"] }  →  { workspaces: ["dntl", "vzn"] }

["vzn"]

VZN

Intelligence + Sales (optical)

["dntl"]

DNTL

Intelligence + Sales (dental)

["dntl", "vzn"]

DNTL.VZN

Intelligence + Sales (optical + dental)

[]

NXTLVL

Intelligence only — membership billing via third-party

05 — PHI Boundary

HIPAA by Architecture

PHI cannot leak into Supabase by design.

Supabase holds all non-PHI data: orgs, users, settings, workspace config, analytics metadata. Aidbox is isolated to the EHR app — the only store that ever touches clinical patient data. The HIPAA boundary is enforced by where data is stored, not by policy or access control alone.

Supabase

Non-PHI

Org records
User accounts
Workspace config
Analytics metadata
Settings

Aidbox (FHIR)

PHI only

Patient records
Clinical data
PMS aggregations
FHIR resources

06 — What We Are Not Building (Yet)

– Outbound integrations to third-party PMS — external software connects to us
– NXTLVL Membership billing infrastructure — handled by third-party software
– Real-time clinical workflows — EHR is aggregation-first, not a live EMR
– A separate product for Revenue Intelligence — it is a shared platform capability, not a standalone app