Yoga Studio Management Platform

A booking, membership, payment, attendance, and operations platform deployed for the daily work of an operating yoga studio.

My role: Flutter application owner and full-stack integration contributor
Context: Team project, March 2024 to July 2025, used in production by one studio
Reading time: 8 min read

Production full-stack platform

The product had to fit a real studio

This was not a portfolio mock-up. One operating yoga studio used the platform in its daily work, so the system had to support the routine details behind a class: schedules, capacity, member eligibility, attendance, payment records, staff permissions, and last-minute changes.

The product split those workflows across a Flutter mobile app, a React administration client, and an ASP.NET Core backend. Members could handle bookings and subscriptions themselves, while coaches and studio staff worked through interfaces shaped around their own responsibilities.

My ownership grew around the mobile product

I owned most of the Flutter application and its API integration. That included authentication and registration, member and coach interfaces, wallet recharges, memberships and packages, class booking, attendance, profiles, notifications, and the Android release configuration.

I also contributed to the React administration client and coordinated changes with the backend. I did not hold a formal team-lead title, but the mobile app became a broad ownership area because almost every member workflow crossed an API, role, or payment boundary.

Roles and payments belonged in the backend

ASP.NET Core Identity and JWT role claims protected the API by default. Five roles shaped the workflows: administrator, sales or front desk, finance, coach, and member. The clients used those claims to present the correct navigation, but the server remained responsible for access control.

Payments were studio workflows, not an external checkout integration. The platform recorded cash, CliQ, debit-card, and internal wallet transactions across bookings, memberships, wallet recharges, point-of-sale sales, and invoices. There was no Stripe or PayPal integration.

Administrators managed settings, staff, schedules, and studio operations.
Front-desk staff handled clients, reservations, and point-of-sale work.
Finance users worked with invoices, cash management, and income reporting.
Coaches managed assigned classes and confirmed attendance.
Members booked classes, managed subscriptions, recharged wallets, and maintained profiles.

Three clients had to agree while requirements changed

The hardest engineering work was keeping Flutter, React, and the .NET API aligned while studio requirements and endpoint contracts evolved. A field rename, role rule, or booking-state change could break two clients at once. I handled cross-layer integration bugs and kept authentication, bookings, payments, and attendance behavior consistent across the system.

The wider platform grew to include coach attendance, point of sale, invoices, cash management, memberships and packages, wallet recharges, promo codes, analytics, and an English and Arabic administration interface. Stable request and response contracts mattered more as that surface expanded.

What production use proved

The deployment showed that the platform could support one studio's real operating workflow rather than only a prepared demonstration. Member self-service reduced manual coordination, while reservations, payments, attendance, invoices, and schedules lived in one system.

We did not retain product analytics or a satisfaction survey, so I do not attach an active-user count, booking total, revenue figure, staff-hours saving, or satisfaction score to that impact.

Outcomes

01A Flutter member and coach application used with a React administration client in a live studio workflow.
02An ASP.NET Core and MySQL backend with REST APIs, ASP.NET Core Identity, JWT, and five-role access control.
03Integrated booking, subscriptions, attendance, wallet, payment records, point of sale, invoices, schedules, and notifications.
04A deployed product used by one operating studio, with impact kept qualitative because product analytics were not retained.

What I learned

01Shared backend rules prevent mobile and web clients from drifting into different versions of the product.
02The API must enforce role-based access because hidden interface controls do not protect data.
03Production integration work is largely about changing contracts, recoverable failures, and consistent state after a mutation.
04Operational impact should stay qualitative when the team did not measure usage, time, revenue, or satisfaction.