Case study — why there’s no login link above

Meta Tutor

A multi-subject AI learning platform I built and run solo — chess with a real Stockfish engine, adaptive comprehensible-input Latin, and an AI chat layer grounded in actual course notes, all sharing one progress-tracking architecture. It’s a real production app with real daily users (me, my co-teaching cousin, our students’ parents via the RCA section) — which is also exactly why it’s login-gated to two whitelisted Google accounts, not open to the public. This page exists so you can see it without needing an account: real screenshots of the real running app, plus the engineering story behind the two things that made it production-grade this month.

← Back to portfolio Source on GitHub ↗

The app

Meta Tutor subject hub — The hub — every subject is its own adapter plugged into one shared progress-tracking and AI-chat layer, not a copy-pasted feature per subject.

Chess module with a real Stockfish engine — Chess — a real Stockfish engine running client-side (zero server cost), live move-quality classification, puzzle mode, full board customization, wired into the same cross-subject progress system as everything else.

Latin Lab adaptive comprehensible-input course — Latin Lab — a comprehensible-input Latin course where comprehension checks are AI-generated per attempt and get harder as accuracy climbs, with FSRS spaced-repetition vocabulary review instead of a fixed schedule.

Ethics T/F exam prep AI chat — Ethics — AI chat tuned for T/F exam prep, answers grounded in real course notes (not generic LLM knowledge), plus an 85-question study quiz and a 48-term glossary. Built by my cousin Cris as the first real contribution from another engineer on this codebase.

The deploy pipeline was actually broken — root-caused and fixed

Cris couldn’t test his first real PR against production: sign-in failed, and he had no way to know why from his own machine. I treated that as a real incident, not a shrug.

Root cause: this GitHub repo was connected to three separate Vercel projects across three different accounts, left over from a prior account-migration — and the one I actually had API/CLI access to had no Git repository linked at all. Its real secrets (auth, OAuth, database) were also scoped to Production only, never Preview — so even a working preview deploy would have had broken sign-in regardless.

Fixed in one pass:

›Connected the correct GitHub repo to the one project I could actually manage, so pushes auto-deploy for real.
›Copied every Production-only secret (auth, Google OAuth, database) into the Preview environment too.
›Verified end-to-end with a real deploy, not just a green checkmark — confirmed the live URL actually resolves the right routes instead of erroring.

Still genuinely open: Google’s OAuth redirect-URI allowlist is Console-UI-only — no API path exists for a standard web client, confirmed by trying. That one needs a two-minute manual click, logged honestly as open rather than silently assumed fixed.

Built for a second engineer, not just myself

When my cousin joined to build his own section, the actual goal was narrower than “add a collaborator”: make it so he cannot break production, without blocking either of us.

›A GitHub ruleset requires a PR on main — zero required approvals, so I’m never blocked soloing, but every change gets a CI run and an isolated Vercel preview URL.
›CI runs a real typecheck + build gate on every PR, against the actual production environment variables — not a mocked config that could pass while the real deploy fails.
›Lane separation by convention: every subject is its own top-level route with its own component and content folders, so two people’s files never physically collide — documented in this repo’s own CLAUDE.md for whoever (human or AI-assisted) touches it next.

First real PR from the second contributor merged clean through that exact pipeline — CI gate, preview URL, no production incident.