The challenge
Many yoga studios still manage classes, payments, and bookings across WhatsApp, spreadsheets, and disconnected tools. On the student side, finding the right class often means checking multiple websites, calling the studio, or relying on platforms that are poorly adapted to the local market.
The goal of Ayogis was to turn that fragmentation into one platform that could connect discovery, booking, payment, and daily operations without splitting the experience between students and studios.
What was built
- Mobile marketplace for students to discover, book, and pay for classes
- B2B mobile app for studios to publish classes, manage bookings, and get paid
- Landing page and web dashboard for acquisition, operations, and growth
- Serverless backend handling business logic, capacity, payments, and automation
- Full store launch, brand identity, and marketing-ready visual system
My role
The problem to solve
How the product works
Ayogis was not one app. It was a coordinated system where the student journey and studio operations met inside the same product logic: discover, book, pay, attend, manage, and measure.
Ayogis App
For students
The discovery and booking layer. Students find nearby studios, compare classes, book, pay, and receive confirmations without leaving the same experience.
iOS • Android
Ayogis Connect
For studio owners
The operational layer for studios. From here they create classes, control capacity, manage cancellations, receive payments, and organize the daily running of the business.
iOS • Android
Landing ayogis.es
Marketing & conversion
The positioning layer. It explains the product, captures early studios and students, and connects the brand story to acquisition and download.
Responsive Web
Web Control Panel
Professional dashboard
The governance layer. A dashboard for administration, operations, and growth that extends the system beyond the mobile experience.
Web App
Technical decisions that made the product viable
The real complexity was not using many tools. It was solving the kind of problems that rarely appear in a UX portfolio: third-party payouts, financial security, booking concurrency, and operations that could not depend on manual support.
"Zero Trust" Security
Firestore Rules & Backend Authority
The problem: In financial and booking applications, trusting client-side logic (Flutter) fatally exposes the system to price manipulation, data injection, or cross-user privacy breaches.
The solution: "Zero Trust" architecture. Strict Firestore Rules unconditionally block client write access. Complex transactions (payments, capacity deduction, or refunds) are exclusively delegated to robust Node.js middlemen (Cloud Functions). The backend cryptographically validates every attempt, ensuring fintech-grade security and strict GDPR privacy adherence while completely completely concealing API secrets from the frontend.
B2B Financial Marketplace
Stripe Connect & Stripe Billing
The problem: Centralizing student payments to manually schedule payouts to studios generates severe fiscal, legal, and accounting bottlenecks. Furthermore, B2B adoption barriers in management software are steep if immediate payment is strictly demanded.
The solution: Decentralized financial orchestration. Stripe Connect was integrated so B2C revenue flows directly to each studio (delegating fiscal liability to them). Simultaneously, Stripe Billing was layered to manage B2B studio subscriptions (SaaS) and inject aggressive adoption pipelines—like 60-day automated trials and dynamic entry-level pricing for the first clients ("City Pioneers"). This enables scaling to hundreds of studios without congesting Ayogis's core corporate accounting.
NoSQL Consistency & Dual-Write
Capacity Control and Race Conditions
The problem: Firebase NoSQL lacks strict data relationships, meaning that concurrent bookings or rapid mass cancellations easily corrupt dynamic class capacity properties. Furthermore, crossing permissions in nested security rules scales cloud read costs exponentially and inevitably leaks private data.
The solution: Synchronized "Dual-Write" architecture mechanism. The backend acts as the sole guardian, atomically isolating and duplicating views: one strictly for the client, one strictly for the studio. This shields maxAttendees numbers against data race conditions, clears bloated Security Rule complexities, and radically cuts monthly cloud database billing.
Decoupled Ecosystem and Compliance
Automated Refunds & Store Tax Evades
The problem: Apple and Google strictly enforce a hostile 30% toll over entirely all global mobile in-app payments. Operationally, if an entire class is cancelled by a studio, customer service teams manually reversing dozens of stripe charges creates instantaneous workflow chaos.
The solution: Cleanly decoupling the product stack into exclusively separated apps (B2C booking flows vs B2B analytics metrics CRMs). Following precise documentation, successful negotiation with Apple/Google App Store review boards effectively legally shielded Ayogis as a marketplace selling exclusively 'Local In-Person Physical Services', completely evading the 30% fees completely securely. Operationally: when B2B managers tap cancel class, background workers instantly differentiate internal Class Pack funds from bank card purchases—firing 100% automated and unattended Stripe refunds.
From problem to product
Problem and opportunity
The first decision was framing the right problem: not designing a class app, but designing a platform that could connect discovery, booking, payment, and daily operations.
- User interviews with 12 yoga studios in Barcelona
- Analysis of 8 competitor apps (Mindbody, ClassPass, etc.)
- Identification of friction in booking, payment, and manual coordination
- Definition of the true product scope from day one
Users and journeys
There were two very different systems of needs. Students needed confidence and speed. Studios needed publishing, payments, capacity control, and operational clarity.
- User personas for students and studio owners
- User journey mapping for both profiles
- Prioritization of key moments: search, booking, payment, and management
- MVP definition based on value and feasibility
Ecosystem architecture
The solution could not live in one interface. I defined a blueprint with two mobile apps, a landing page, and a dashboard, each with a clear role inside the same service model.
- Information architecture for 2 apps and 2 web surfaces
- Clear separation between B2C experience and B2B operations
- Definition of flows between marketplace, management, and payments
- Planning of dependencies across product and backend
UX decisions
The design had to explain a complex system without feeling heavy. That meant one shared visual language, highly guided journeys, and different hierarchies depending on whether the user was a student or a studio.
- Complete design system in Figma with reusable components
- More than 50 screens with interactive prototypes
- Brand system, photography, and store assets
- Different interaction priorities for students and studios
Technical decisions
The experience only becomes credible if the architecture can sustain concurrent bookings, third-party payouts, refunds, and privacy controls without trusting the client app.
- Serverless backend with Node.js, Firebase, and 15 Cloud Functions
- Stripe Connect and Stripe Billing for payouts and subscriptions
- Zero Trust security rules and backend authority
- Automated cancellations, capacity handling, and refunds
UX and architecture decisions
Geolocation-first
discovery
The experience starts with proximity and local context: find studios, filter classes, and decide without leaving the product.
Payments for a
real marketplace
Stripe Connect turns Ayogis into a real platform where money can move between student, platform, and studio without manual coordination.
Booking with
follow-through
Confirmations, reminders, and status changes support the booking so the experience does not end at checkout.
Authoritative
security
Critical logic does not depend on the client: bookings, payments, and privacy are enforced through backend authority and strict rules.
Operations and
analytics
The platform does not only sell classes. It also gives studios visibility into bookings, revenue, and business activity.
Brand system and
trust
Identity, motion, and launch assets help a complex ecosystem feel coherent, premium, and product-ready.
What was delivered
Ayogis stopped being a mobile app idea and became a platform capable of connecting students, studios, and operations inside one scalable ecosystem.
The real story is not only that the stack was large. It is that each layer answered a real product problem and the architecture could support it with business, UX, and operational rigor.