Featured project
Back to workProCoach
Coaching marketplace — from session to payment
01 — Overview
Building the frontend that connects coaches, learners, and Stripe across multiple production APIs.
ProCoach is a sports and fitness coaching marketplace. Coaches need to publish sessions, manage enrollments, and handle payouts. Learners and parents need a reliable path to discover sessions, enroll, and pay. I owned the web client that ties these journeys together.
02 — Problem
The product had to hold up as a connected workflow.
The product had to support the full coaching workflow — session publishing, enrollment, payments, and payouts — while coordinating several backend services from a statically hosted Next.js frontend.
03 — My role
What I owned.
Frontend Product Engineer — Frontend Product Engineer on the ProCoach web client — product UI, UI/UX, and feature workflows. I owned frontend and UI/UX; backend was handled separately, and I contribute there when needed.
04 — Product flow
The path a user actually takes.
I treated the frontend as the product layer: not isolated screens, but connected workflows from discovery through enrollment, checkout, confirmation, and retry states.
Conceptual product flow for this domain — not a literal system diagram.
05 — Engineering
Decisions worth explaining.
Static hosting shaped routing and authentication architecture.
Payment was implemented as a stateful product workflow rather than a standalone checkout screen.
Feature-specific state was kept close to the workflow instead of introducing a large global state library.
05.1 — Architecture
How the pieces sit together.
06 — Challenges
What shaped the build.
Reliable paid enrollment
Enrollment could involve the schedules API, payments API and Stripe succeeding at different stages. The frontend therefore had to manage the transition from enrollment review to checkout and then payment confirmation/retry rather than treating payment as a single UI action.
Static hosting with dynamic product workflows
The application was designed as a static Next.js export while still supporting dynamic session and enrollment URLs. Routing and fallback behaviour therefore had to work within the static hosting model.
Multiple API services
The frontend consumes separate services for authentication/profile, schedules and payments, requiring a consistent client-side integration layer and session handling.
Timezone-sensitive session information
Session dates and times need to remain meaningful across user-facing scheduling and calendar views, requiring deliberate date parsing and formatting.
07 — Outcome
What shipped.
Production
Production-intended product UI with real API and payment integrations
Qualitative — no performance or business metrics are claimed here.
A production-shaped marketplace frontend connecting real coaching, enrollment, and payment workflows — without claiming unverified business metrics.
The repository contains production-oriented configuration, multiple API environments, Stripe integrations, CSP handling and static deployment configuration. Exact live traffic and business metrics are not established by the repository.
In the product
Next.js App Router with static export
Feature-level hooks and views
REST API integration across multiple service domains
JWT and OTP authentication flows
Stripe Embedded Checkout
Stripe Connect frontend surfaces
Client-side payment confirmation and retry handling
URL-driven deep links and filters
Responsive session and dashboard interfaces
Integrated and orchestrated existing backend services from the frontend. No backend service ownership is claimed from this repository.
08 — Learnings
I treated the frontend as the product layer: not isolated screens, but connected workflows from discovery through enrollment, checkout, confirmation, and retry states.