Case study 03 · Founder product · Pre-launch

FlowOS — an operating system for wellness studios

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.

Role Founder — product, design, and build

Type Multi-tenant SaaS · three user roles

Stack Next.js · Supabase · Stripe · Resend

Status In active development — early-access waitlist

Summary

The problem: 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: the entire product — definition, UX and information architecture, design system, and implementation. The state of it: the core platform runs — scheduling, memberships and billing, credit accounting, email automation, community — with a first studio onboarding as the next milestone.

Fig. 01The brand system on one sheet: warm neutrals as the foundation, sage #2D6A4F as the only primary accent, deep greens for dark surfaces, coral reserved for attention.

Four slides of the FlowOS promo swipe deck at phone size: cover, problem, one platform, early access — Fig. 02The launch swipe deck, phone-first: cover promise, the five-tools problem, the one-platform answer, and an early-access capture with a demo call as the secondary path.

FlowOS as two real surfaces: the owner's revenue dashboard beside the member's mobile app — Fig. 03One system, two lives: the owner's operator cockpit and the member's phone-first app. All screens are the working product with seeded demo-studio data.

The operator's product

A cockpit that answers "what needs my attention?"

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.

FlowOS admin dashboard: setup checklist, today's schedule, KPIs, action queue with waitlist alert — Fig. 04The owner's home answers one question — what needs my attention? Setup checklist, today's classes, and a live action queue.

Revenue analytics: MRR, churn, revenue chart, past-due queue, revenue mix, subscription health — Fig. 05Revenue designed for a studio owner, not an analyst: MRR, churn, and subscription health up top; the two lists that demand action directly below.

Membership and pricing products: memberships, class packs, drop-ins — Fig. 06Monetization building blocks: memberships, class packs, and drop-ins, each mapping to a credit pool in the ledger underneath.

Systems design

Complex operational logic behind a calm surface

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.

Weekly calendar of class instances generated from recurring templates — Fig. 07Owners define recurring templates once; the system generates eight rolling weeks of bookable class instances automatically.

Three states of the member booking flow: schedule, booking confirmation with success toast and invite-friends dialog, updated bookings list — Fig. 08The booking flow, left to right: browsing the schedule; the moment of booking — credit check, success toast, and a post-booking friend invite; the updated bookings list.

Rule-based lifecycle email automations: credit expiry, milestones, welcome, win-back — Fig. 09Automation a studio owner can read: named lifecycle rules — credit expiry, milestones, welcome, win-back — instead of a black box.

Three roles, three products

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.

Teacher dashboard: today's classes, teaching stats, class playlist — Fig. 10The teacher's product: their day, their stats, their playlist — nothing from the owner's world leaks in.

Member dashboard and seven-day schedule at phone size — Fig. 11The member product is designed phone-first: personal dashboard and seven-day schedule at 390px.

Community feed with moderation controls, streak leaders, studio pulse — Fig. 12Community lives inside the same system: member feed with owner moderation, streak leaders, and a studio pulse.

Brand & go-to-market

The marketing layer is part of the product

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.

You didn’t start your studio to manage 5 different tools. You started it to do the work you love. None of it talks to each other. All of it slows you down.
FlowOS launch campaign — problem slide

Fig. 13The public landing page leads with the whole pitch in six words — “Everything your studio needs. Beautifully simple.” — and nothing else competing with it.

Status & next

Implemented, labeled honestly

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.

Reflection

Screens are the easy part

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. Next: onboard a first studio and instrument the onboarding funnel from day one.

Competencies demonstrated

Systems design Lifecycle modeling · states · immutable ledgers

Product design Three role-specific products in one system

Interaction Booking flow · feedback states · progressive social

Implementation Next.js · Supabase RLS · Stripe — designed and built