Product Design & Build · Pre-launch
An operating system for wellness studios — scheduling, memberships, payments, email, and community consolidated into one calm system with a single source of truth for every member.
Founder — product, design, and build
2026
Pre-launch
A typical yoga studio runs five disconnected tools: scheduling in one, memberships in another, payments, email, and community somewhere else. FlowOS consolidates all of it into one calm system with a single source of truth for every member. It is my own product, currently pre-launch — everything shown here is the real working software.
Studio owners don't open a studio to manage software, yet the standard stack forces them to be systems administrators — and members feel every seam. My contribution is the entire product: definition, UX and information architecture, design system, and implementation, built as a multi-tenant SaaS on Next.js, Supabase, Stripe, and Resend.
The core platform runs — scheduling, memberships and billing, credit accounting, email automation, community — with a first studio onboarding as the next milestone.
The owner's home is an opinionated brief, not a menu: today's classes, studio KPIs, and an action queue that surfaces what actually needs a decision — a waitlist to promote, a past-due subscription to chase.
Revenue is designed for a studio owner, not an analyst: MRR, churn, and subscription health up top, with the two lists that demand action directly below. Monetization is built from simple blocks — memberships, class packs, and drop-ins — each mapping to a credit pool in the ledger underneath.
The core of FlowOS is a set of carefully modeled lifecycles. A booking moves through book → waitlist → promotion → check-in → attended, with first-in-first-out waitlist promotion. Credits live in priority-ordered pools with an immutable ledger, so a member's balance is always explainable. Recurring templates generate eight rolling weeks of bookable classes automatically. Every mutation is audit-logged.
Automation stays legible too: email lifecycle rules a studio owner can read — credit expiry, milestones, welcome, win-back — instead of a black box.
Each role sees only its own world. The owner gets the cockpit. Teachers get their day — schedule, rosters, stats, playlist. Members get a consumer-grade booking and community experience designed phone-first.
Row-level isolation keeps every studio's data separate, and tenant-level theming lets each studio carry its own brand, so FlowOS disappears behind the studio's identity. Community lives inside the same system: a member feed with owner moderation, streak leaders, and a studio pulse.
FlowOS ships with its own brand system and launch funnel, designed in the same hand as the product: a warm-neutral foundation with a single sage green accent, SF Pro throughout, and a logo mark of two intertwining flow curves.
The go-to-market surface is a public landing page plus a five-slide swipe deck — cover, problem, platform, why, and an early-access capture wired to a waitlist and a demo call. The landing page leads with the whole pitch in six words — "Everything your studio needs. Beautifully simple." — and nothing else competing with it.
The core platform is implemented and running: auth and invitations, scheduling and rosters, memberships and Stripe billing, credit accounting, email campaigns and automations, and member community. Some peripheral surfaces — events, shop, extended teacher tools — exist as static previews behind feature flags and are not represented as shipped. The next milestone is onboarding a first studio, with early access open by request.
The hardest design work in FlowOS is invisible: modeling booking, credit, and waitlist lifecycles so every state a member can reach is explainable. Designing the system before the screens is what keeps the interface calm — and building it myself kept every design decision accountable to what could actually ship.