01 / Brief
The founder needed a working product, not a frontend department.
The new psychology-education platform started without a frontend codebase. It needed a public course marketplace, learner profiles and progress, practice booking, instructor operations, secure educational media, and a reliable path to production.
I owned the frontend end to end: system shape, product implementation, API orchestration, validation, delivery infrastructure, deployment, and the migration of existing content.
- Operating constraint
- Move from zero to real learners quickly without producing a disposable prototype.
- My ownership
- All frontend product surfaces, Next.js BFF, CI/CD, Docker deployment, and legacy migration.
- Primary users
- Prospective learners, enrolled students, instructors, and product administrators.
- Launch target
- A maintainable production MVP with real content and operational workflows.
02 / Constraints
Product scope, delivery infrastructure, and migration arrived together.
The product could not launch as a set of disconnected screens. Booking had to create the right call links, permissions had to protect paid media, instructor tooling had to support daily operations, and existing content had to arrive from a service with no API.
- Starting point
- An empty frontend repository and a backend/CMS surface that needed product-facing orchestration.
- Legacy data
- The previous service exposed no API suitable for content migration.
- Media
- Video, audio, PDF, and document content required secure delivery from AWS S3.
- Operations
- Instructors needed schedules, session management, and learning-progress visualization.
03 / Decisions
A small architecture with explicit boundaries around external complexity.
The frontend was organized around product workflows, with a BFF layer absorbing API orchestration and infrastructure details that did not belong in page components.
Build learner and instructor workflows as one product system.
Delivered the marketplace, profiles, progress, practice booking, schedule management, and instructor progress views on shared domain rules.
Use a Next.js BFF for orchestration and stable client contracts.
Kept backend composition, validation, and integration-specific behavior behind a server boundary instead of spreading it through UI code.
Keep access control attached to media delivery.
Implemented secure viewing for video, audio, PDFs, and documents stored in S3, with product permissions governing access.
Automate extraction when no migration API exists.
Used Playwright-based scraping to move existing courses and content without manual re-entry, then put deployment behind GitLab CI/CD and Docker.
04 / What shipped
A production MVP that covered both customer experience and daily operations.
The first release was not only a marketing shell. Learners could discover courses, manage their learning, book practice, and consume protected content; instructors could operate schedules and follow progress; the team had a repeatable route to deployment.
Scope note. The delivery window refers to the first production MVP inside a seven-month engagement. This public case focuses on the frontend scope I owned and omits private customer and operational data.
05 / Scope
One frontend owner, from product behavior to the deployment path.
Working solo meant keeping architectural ambition proportional to the team while still protecting the parts most likely to become expensive: product boundaries, API contracts, validation, access control, automated delivery, and migration repeatability.
- Learner product
- Course discovery, profiles, progress, booking, schedules, and protected educational content.
- Instructor product
- Session management, schedule workflows, and progress visualization with Recharts.
- Delivery
- GitLab CI/CD and Docker-based deployment created from scratch for the new frontend.
Technology used
- Next.js
- TypeScript
- Tailwind
- shadcn/ui
- React Query
- Zod
- Strapi
- Recharts
- Playwright
- AWS S3
- Docker
- GitLab CI/CD