Zelo
Confidential burnout triage and peer support for doctors — built so the employer who pays for it never sees who used it.
🇺🇸 English · 🇧🇷 Português
Why Zelo
57% of Brazilian doctors report burnout symptoms; fewer than 12% ever seek help, and physician suicide rates run more than double the general population (CFM/AMB, 2022). The reason isn't a lack of care — it's the fear that admitting distress reaches an employer or the medical board and damages a career.
Zelo is a mobile-first PWA that gives doctors a validated self-assessment (PHQ-9, GAD-7, MBI-HSS) with scoring computed on-device, an AI-assisted, human-backed support chat, anonymous peer matching, and opt-in crisis escalation — while hospitals and cooperatives who fund the tool only ever see anonymized, aggregate risk trends, never an individual's identity.
Built during the 1ª Jornada Incubintech open-innovation program (27 Jun – 25 Jul 2026) for the "Saúde do Médico" (Physician Health) challenge.
How it stays confidential
- Client-side scoring — assessment results are computed on the device; raw answers are never persisted server-side in the clear.
- Employer sees aggregates only — the institutional dashboard reports anonymized metrics by shift/department, never per-individual data.
- Identity disclosure is opt-in — a doctor's identity is only exposed if they actively choose to escalate to a human.
- No AI diagnosis — the support chat is a humanized triage layer with an always-visible path to a real person, never a diagnostic tool.
See general-documentations/documentacao-produto/prd.md for full product requirements and docs/superpowers/specs/2026-07-07-pwa-architecture.md for the technical architecture.
Tech stack
| |
|---|
| Frontend | React 19 + Vite, TanStack Query, Zustand, Tailwind CSS 4, PWA (installable, offline-capable) |
| Backend | NestJS 10, Prisma 7 (pg adapter; Neon serverless adapter when the host is Neon), Groq SDK for LLM inference |
| Shared | Zod-based domain schemas (packages/domain), shared lint/tsconfig base (packages/config) |
| Tooling | Turborepo, pnpm workspaces, dependency-cruiser for architecture boundaries, Vitest |
| Infra | Fly.io (API), Vercel (Web), Prisma Postgres, Docker Compose for local parity |
Repository map
apps/
web/ React + Vite PWA frontend
api/ NestJS backend
packages/
domain/ Shared Zod schemas + TS types (no business logic)
config/ Shared tsconfig/eslint/prettier/dependency-cruiser base config
docker/ Local Docker Compose environment (production-like builds)
general-documentations/ Product docs: PRD, personas, roadmap, problem statement
docs/superpowers/ Technical specs and implementation plans
Getting started
Prerequisites: Node ≥20 (repo pins 24 via .nvmrc), pnpm ≥9.
pnpm install
Backend (apps/api)
Requires DATABASE_URL. Copy the example env and point it at a running Postgres instance:
cp apps/api/.env.example apps/api/.env
pnpm --filter @zelo/api dev
The Postgres container from the Docker environment below is the quickest way to get one.
Frontend (apps/web)
Requires VITE_API_BASE_URL:
cp apps/web/.env.example apps/web/.env
pnpm --filter @zelo/web dev
Run alongside the API to see the live health-check banner.
Common commands
| Command | Description |
|---|
pnpm build | Build all packages/apps in dependency order (Turborepo) |
pnpm dev | Run all apps in dev mode |
pnpm lint | Lint all packages/apps |
pnpm lint:boundaries | Enforce Clean Architecture layer boundaries (dependency-cruiser) |
pnpm test | Run all test suites |
Local Docker environment
Runs actual production builds of apps/api and apps/web against a containerized Postgres — use this to catch build-only issues before a demo, not for day-to-day development.
cd docker
cp .env.example .env.docker # first time only
docker compose up --build -d
Tear down with docker compose down (add -v to also wipe the Postgres volume).
Deployment
Two independent environments, each with its own Fly app, Prisma Postgres database, and
Vercel project:
| Prod | Dev |
|---|
| Deploys from | tag v* (see docs/releasing.md) | develop |
| API | zelo-api (Fly) | zelo-api-dev (Fly) |
| Web | zelohealth.app (Vercel) | dev.zelohealth.app (Vercel) |
| Migrations | manual (see below) | automatic in CI |
main and develop are both protected — all changes land via PR, and merging into main
deploys nothing: production is released by pushing a vMAJOR.MINOR.PATCH tag. apps/web also
packages as an installable Android APK via Capacitor — see
docs/android-apk.md.
Dev deploys from develop via .github/workflows/api.yml's deploy-dev job, with Vercel's
own git integration deploying the dev web app. Prod deploys through
.github/workflows/release.yml on a tag: the API first, then the production branch that the
prod Vercel project builds from. Prod migrations are not run on container boot — apply them
manually before tagging a release that includes one:
pnpm --filter @zelo/api exec prisma migrate deploy # DIRECT_DATABASE_URL must point at prod (apps/api/.env.production.local)
Local apps/api env files: .env (safe dev defaults, used by bare pnpm dev),
.env.development.local (per-developer local overrides, e.g. docker Postgres
credentials), .env.production.local (prod secrets, only loaded when
NODE_ENV=production — used for the manual migration command above), and
.env.dev-remote.local (the deployed dev environment's database, for one-off scripts
against it).
Secrets (Fly.io)
MANAGER_TOKEN_SECRET, ADMIN_TOKEN_SECRET, and PEER_PARTNER_TOKEN_SECRET sign session
tokens for each account type. env.validation.ts fails the boot in production
(NODE_ENV=production, declared both in fly.toml and docker/api.Dockerfile) if any of
these are missing or under 32 characters — this rejects the local-dev placeholder
(change-me-in-production) and any other weak value. Rotate them with three independent
values, never one shared secret:
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" # run 3x, one per secret
fly secrets set MANAGER_TOKEN_SECRET=<value> ADMIN_TOKEN_SECRET=<value> PEER_PARTNER_TOKEN_SECRET=<value> --app zelo-api
fly secrets set triggers an automatic rolling restart. Verify afterward with fly status --app zelo-api and curl https://zelo-api.fly.dev/health.
Rollback (Fly.io)
Rollback is intentionally manual — treat it as a deliberate decision, not an automated safety net:
fly releases --app zelo-api # list prior releases
fly deploy --image <previous-image-ref> --app zelo-api # redeploy a specific image
Documentation
