Study Platform is a production-minded learning platform built around three deployable surfaces: a student app, an admin app, and a Hono API worker. The repo also keeps a separate mobile sandbox and OCR microservice so the product can grow without mixing experimental tooling into the main deploy path.
Why I Built It
I wanted this project to feel closer to a real education product than a simple course-list CRUD app. That meant thinking about separate user surfaces, authentication boundaries, same-origin API routing, production domains, secret management, upload policy, deployment order, and verification.
The main engineering challenge was keeping the system understandable while still supporting multiple targets. The student app, admin app, API worker, mobile sandbox, and OCR service each have different runtime needs, so the repo structure makes those boundaries explicit.
Architecture
apps/study Student frontend
apps/admin Admin frontend
apps/study-app Mobile app sandbox
server Hono API worker
shared Shared types and utilities
services/ocr-service FastAPI OCR microserviceThe student and admin apps are React + Vite frontends. The backend is a Hono API worker with Drizzle for data access. Shared types and utilities sit in a dedicated package so frontend and backend code can agree on contracts without duplicating definitions.
Deployment Model
The production domain plan separates the product surfaces while keeping API traffic simple for the browser:
- Student app: https://study.hsuwai.space
- Admin app: https://studyadmin.hsuwai.space
- API: same-origin /api routes from both frontend domains
- Legacy API compatibility: https://studyapi.hsuwai.space
This design reduces cross-origin friction for the main apps while still leaving room for older clients or external integrations through the legacy API domain.
Operations
The repo includes production environment templates, Cloudflare deploy commands, one-shot deploy scripts, staging deploy flow, and Worker secret sync. The deployment order is documented so the API can be released first, then the student and admin apps can be verified against live routes.
The upload policy is intentionally conservative. Media and PDF import uploads can be frozen in production with feature flags, which gives the platform a safer launch mode while leaving a clear path to enable uploads later.
Verification
The runbook checks the pieces that usually fail during real deployments: health endpoints, login, protected admin routes, same-origin /api request paths, OAuth callback domains, DNS, and CORS.
What It Shows
This project shows that I can think beyond feature screens. I can organize a multi-target monorepo, define deployment boundaries, plan environment variables and secrets, document operational workflows, and design a product structure that can scale from local development to production.