Pathment

Pathment runs the whole mentorship loop, programs, cohorts ("clans"), AI-generated learning roadmaps, live video reviews, attendance and contribution scoring, in one system an organization can self-host or use hosted. I was the sole engineer through design, build, and launch; today I lead it as an open-source project with 20+ contributors, one funded through Dev Weekends Summer of Code.

The Problem:

Mentorship programs inside companies and communities die of admin overhead: matching mentors to mentees, scheduling cohort reviews, chasing attendance, and proving to whoever funds the program that it works. Existing tools are either calendars with labels or heavyweight enterprise HR suites.

The Architecture:

6+ independently deployable services and reusable modules spanning mentorship, real-time communication, notifications, email, background processing, AI and search. Boundaries are designed for reuse, so a module can ship as a package or run as a standalone service, and a contributor can hold one service in their head at a time. Deployed with Docker and Caddy (auto-TLS), GitHub Actions CI/CD across staging and production, and a zero-downtime expand-migrate-deploy runbook that has carried 500+ releases with repeatable migrations and safe rollbacks.

Three Hard Decisions:

1. The email queue runs on Postgres, no Redis, no Bull At 500K emails/month the default answer is a message broker. I kept it in Postgres: FOR UPDATE SKIP LOCKED for job claiming, exponential backoff with jitter, dead-letter handling, idempotency keys, a suppression list, and priority lanes so a password reset never queues behind a bulk campaign. Why: one less stateful system to operate, back up, and explain to contributors, and transactional enqueueing for free (the job commits with the row that caused it, or neither happens). The trade-off is honest: Postgres-as-queue has a throughput ceiling. At our volume we are an order of magnitude below it, and the migration path to a broker is contained in one module.

2. BYOK AI, customers bring their own model, so the model can't be trusted Roadmap generation works against a provider-agnostic AI layer (OpenAI, Anthropic, Gemini, Groq, OpenRouter). Customers choose the model and pay their own inference. Why: it kills per-seat AI pricing pressure and vendor lock-in objections in one move. The cost is engineering: since a customer may point us at a weak model, no output is trusted, every response passes JSON schema validation, multi-stage sanitization, and a repair pass before it reaches the UI. Keys are encrypted at rest and never logged.

3. Self-hosted live video instead of embedding Zoom/Meet Cohort reviews run on embedded Jitsi, prosody, jicofo, and the JVB, all self-hosted. Attendance derives from join/leave events, contribution is scored from talk time in the media pipeline, and zero media is stored. Why: per-minute video APIs invert the economics of a program with weekly cohort calls, and mentorship conversations shouldn't transit a third party. The cost was operating a media stack, TURN, load, codecs, which taught me more about production networking than anything else in the project.

Also inside:

- Scoped RBAC (org → program → clan → self) with a permission catalog, derived capabilities, role delegation, and full audit logging, resolved in one place rather than per controller. - Real-time layer: Socket.IO notifications and presence, 1:1 chat with delivery and read receipts, recurring cohort reviews with .ics invites. - Onboarding docs (ARCHITECTURE.md, DATABASE.md) designed so a new contributor ships in their first week, which is why the project has 20+ of them.