Context and ownership
I worked on the frontend of Meets Indonesia, a B2C mentoring platform connecting individuals with industry professionals.
My scope was the React application used by mentors, mentees, and administrators, including transaction, revenue, payroll, filtering, reporting, and live mentoring flows.
Role-specific product surfaces
The product serves users with materially different jobs:
- mentees discover and participate in mentoring;
- mentors manage schedules and sessions;
- admins operate transactions, revenue, payroll, filtering, and reporting.
The frontend therefore cannot rely on one generic dashboard with hidden controls. Routes, state, forms, and actions need to reflect the active role and the workflow that role owns.
Live mentoring with VideoSDK
I integrated VideoSDK for live mentoring sessions.
The repository includes the live-session path from pre-join device setup into participant/session UI. Session components cover microphone/camera handling, screen sharing, recording state, participant interactions, and in-session chat.
This work is more than rendering a video component: the UI has to manage device readiness, joining state, live participant state, session controls, and failure/recovery behavior without confusing those concerns with the rest of the mentoring application.
Operational frontend
The application also exposes data-heavy operational flows for transactions, revenue, payroll, filtering, and reporting.
The engineering concern is keeping these surfaces usable while many pieces of state come from APIs, filters, pagination/reporting controls, and role-specific permissions.
Result
The delivered React frontend supported a platform with 300+ mentors and 500+ mentees and provided the role-specific workflows and live-session experience required by the product.
The main lesson is: realtime product work is strongest when session-specific state stays isolated from the broader application workflow instead of leaking through the entire frontend.