Case study
Eclipse
A white-label platform where boutique studios and independent coaches run their business on their own brand — software that looks and feels like the studio, not the vendor. Built for how Latin America actually pays and communicates.
Founder, Design and Development — 2025–Present
The challenge
Boutique studios compete on experience — then their software breaks the spell.
They compete on the light, the playlist, the way a class feels. Studio management platforms, though, are built like enterprise ERPs: generic booking pages in someone else's brand, English-first interfaces, checkout flows that don't accept how Mexico actually pays. For a boutique studio, the booking flow is the digital lobby — and the incumbents were expensive, rigid, and worst of all, they all look the same.
Studios were choosing between spreadsheets and software that erased their identity.
My role
I owned the product end to end — and that shaped every decision.
I led discovery, UX, UI, the design system, and wrote the production code. As a solo founder-designer-engineer, design and engineering weren't separate conversations: I couldn't ship a screen I couldn't also build and maintain, so feasibility was baked into the design from the first sketch.
That constraint became an advantage. Decisions moved fast, nothing got lost in handoff, and the design system and the codebase stayed in sync because the same person owned both. Eclipse is designed, built and operated by one person, working AI-native in production.
Process
From discovery to a product in production.
-
Discovery
Sat with studio owners to map how they ran reservations, memberships, and payments today — and exactly where it broke down.
-
Flows & architecture
Designed the core flows — booking, memberships, payments — on top of a multi-tenant architecture where each studio is its own branded, isolated instance.
-
Design system
Designed a token-driven design system — shadcn conventions adapted to Rails and Tailwind — where every studio is a theme, not a fork. The system lives in code as the source of truth; Figma is the exploration layer.
-
Build & ship
Wrote the production code (Rails, Hotwire, Stripe Connect) and launched with the first studios, iterating against real usage.
-
Integrate & scale
Added platform-level integrations with corporate-wellness networks (Wellhub/Gympass) and got new-studio onboarding down to under five days.
Key decisions & rationale
Three choices that defined the product.
The software disappears
Eclipse is invisible by design. Every studio runs on its own domain, with its own color, typography and tone — across booking, confirmation emails, receipts and class passes. Owners don't configure a page builder; they get a designed brand experience, delivered as part of the product.
Under the hood, it's one token-driven system where each studio is a theme, not a fork. That's how a team of one designs, ships and maintains eight branded products in production.
Every studio runs by its own rules
No two studios operate the same way — cancellation windows, booking cutoffs, class capacities, how credits and memberships work. The incumbents impose one rigid model and make studios adapt to it. Eclipse inverts that: each studio's policies are configuration, not a custom build, so the platform bends to how a yoga shala, a Pilates studio or an independent coach actually runs — without ever forking the product.
Built for how Mexico pays
Pricing and payment flows were designed around pesos and local payment behavior on Stripe Connect, instead of forcing the US-centric, card-only model the incumbents assumed.
The other side of the counter
A member sees Eclipse for three minutes a week. The owner lives in it for hours a day.
Schedules, memberships, money, attendance. So the admin runs on different design values than the member side: density over drama, speed over delight, forgiveness over friction. Same token system, different temperature.
Schedules that survive real life
Studios don't run on one-off events — they run on rhythms. In Eclipse, an owner creates a class once and the series takes care of itself. Substitute instructors, holidays and capacity changes are handled as exceptions that never break the recurrence — or the bookings members already made against it.
Recurring calendars are among the hardest scheduling UX problems there are. The design goal was simple: the owner should never have to know that.
Reports that answer questions, not export tables
Owners don't want dashboards — they want answers to Monday-morning questions. Which classes actually fill? How did the month close? Is membership growing or quietly churning?
Eclipse reports are designed around those questions: revenue, attendance and membership health readable at a glance, with the detail always one tap deeper. The design work here wasn't charts — it was deciding which questions deserve the front page.
One roster, every source
A class fills from direct bookings and Wellhub reservations at the same time. Eclipse merges both into a single live roster — the front desk checks everyone in from one list, and the owner never reconciles two systems.
Integrations are invisible when they work. That's the design.
Touchpoints
The brand doesn't break at checkout.
Confirmation emails, payment receipts, membership renewals and class passes all ship themed by default — the experience a member gets in their inbox matches the one they feel in the studio. Most platforms treat these as afterthoughts: a generic receipt from a vendor the member never chose. But the moment a charge goes through or a spot is confirmed is exactly when trust is won or lost — so in Eclipse every one of those moments carries the studio's brand, not the vendor's. The details other tools ignore are the ones members actually remember.
Impact
A product real studios run their business on.
"It doesn't feel like software we bought. It feels like something we built."— Ana Rovira, Mun Yoga Studio
What I took from it
Designing as someone who also ships.
Eclipse taught me to treat every screen as a set of real product, business, and engineering tradeoffs — not just a layout. Owning the whole arc made me a sharper designer: I learned to defend decisions with rationale, cut scope without losing the experience, and design systems that survive contact with production.