PART 05 · CLIENT WORK · LEAD ENGINEER · 2026

Chapter3

A student admissions and relocation platform: a marketing site, a university matching engine, a student portal, a parent view and an internal admissions OS, all on one student record.

PRE-LAUNCH · HEYCHAPTER3.COM ↗

FUNCTION: Admissions platform + internal OS
STATUS: Production hosted · launch checks open
CLIENT: Chapter3 · Malaysia first
MY ROLE: Architecture · build · integration

Chapter3 homepage — FIG. 01 — MARKETING SITE · HOME

Chapter3 Find Your Fit results — FIG. 02 — FIND YOUR FIT · MATCH RESULTS

01The brief

Chapter3 helps students apply to universities abroad and get settled once they arrive. They needed the whole platform, not just a website.

Students, parents and staff all needed to see the same application from their own angle, and the team needed to add countries, programmes, fees and pipelines without a rebuild. Malaysia launches first; other countries arrive later as data.

02What I did

I wrote the architecture, the full data model and the plan, then split the build into about forty task briefs across six waves. Each brief was written so Claude Code and Codex agents could work in parallel git worktrees against frozen contracts without colliding.

I ran it as integrator: owning the schema, reviewing every branch, resolving conflicts, merging, and setting up the hosted production stack. Business decisions stayed with the client; the technical ones were mine.

03How matching works

A short conditional questionnaire collects grades, English scores, budget and priorities, with anonymous autosave.
SQL filters candidate programmes, then per-programme entry rules decide eligibility from database facts.
Weighted scoring ranks fit and groups results into strong matches, ones to explore and stretches.
AI writes the explanation only. Fees, requirements and dates always come from the database, never the model.

04Scope

Marketing site, university explorer, compare and guides
Find Your Fit questionnaire and matching engine
Student portal: applications, documents, offers, payments
Read-only parent view, invited by the student
Private document vault with staff review
Booking-fee payments, receipts and refunds
Admin OS: CRM, applications board, content and config studios
Perks, referrals, consultations and an audit trail

05Stack

LANGUAGE: TypeScript · pnpm + Turborepo monorepo
APPS: Next.js 16 · React 19 · Tailwind v4 · two apps (public + admin)
DATA / AUTH: Supabase (Postgres · Auth · Storage · Realtime) · Drizzle ORM
INTEGRATIONS: Stripe · Resend + React Email · Cal.com · AI Gateway · WhatsApp links
OBSERVABILITY: PostHog · Sentry
TESTING: Vitest · PGlite integration tests · Playwright · axe · dependency-cruiser

06Engineering notes

Authorize at the use-case, not the page. Feature code reaches the database only through server use-cases that check the actor first. Students and parents get explicit DTOs, so staff notes, commission data and other students' records can't leak through a raw row.
Configuration, not reconstruction. Countries, programmes, fees, intakes, questions, matching weights, pipelines and feature flags are admin-editable data. Code defines behaviour and gates; data defines content.
Contracts first, so agents can run in parallel. The schema, enums, permissions, events and kernel APIs were frozen before feature work began. Later schema changes went through written requests to the integrator.
Every external service has a fake. Payments, email, storage, AI and analytics sit behind interfaces with test doubles, so the whole suite runs on in-process Postgres without Docker or live keys.

07In service

CLIENT COMMISSION · PRE-LAUNCH

Built: both apps and every V1 module, merged to main. The production database, storage, email and DNS are set up, and hosted auth and dashboard checks have passed.

Now: the client's latest round of answers on payments, consultations and markets, then catalogue entry and final launch checks.