Zabira Studio
Management platform and digital experience for a premium pilates studio
"Replacing an external fitness management platform with a custom system that combines premium branding with an atomic booking engine and optimized concurrency."
The starting point of the challenge
Digging beneath the surface: What did I investigate?
Existing platforms solved operational management, but created several problems:
- Slow and unintuitive interfaces
- Generic experience with no brand identity
- Low flexibility
- Overloaded dashboards
- Third-party dependency
- Friction when booking classes
The studio was looking for its own platform where the experience felt aligned with the physical space, clients could easily self-manage, instructors had simple tools, and the entire operation was centralized. I analyzed fitness booking systems, admin dashboards, and client onboarding flows. I also understood that Zabira didn't compete on price — it competed on experience, perception, and exclusivity.
"The most important decision was to completely separate two experiences: the public landing page (focused on branding, trust, and premium perception) and the internal dashboard (focused on clarity, speed, and pure functionality). This avoided a very common mistake: making dashboards "too visual" but uncomfortable for daily operation. The landing page could be emotional, elegant, and narrative, while the internal system had to be fast, understandable, and highly operational. I also understood that booking a class wasn't just a transaction — it was also a moment of anxiety for the client who wanted to secure their spot. If the system failed at that instant, the entire premium perception would collapse."
Understanding this pillar completely transformed the tactical direction of the project, allowing unnecessary noise to be filtered out and focusing on strict value.
Tradeoff Analysis: options on the table
Building custom software requires honestly evaluating scenarios. No architecture is perfect — every decision has a price:
Stick with the external platform
No development cost, but it kept limiting brand identity and the client experience.
Simple booking system + separate landing page
Faster to develop, but the disconnect between both experiences would create friction and loss of context.
Custom integrated platform
Higher initial investment, but absolute control over the experience, the brand, the operation, and the business's data.
The Decision: The path chosen
WHAT ACTUALLY WORKED
The public landing page ended up being one of the strongest points — conveying exclusivity and calm without falling into generic fitness aesthetics. The role architecture and permission separation was extremely solid and scalable, allowing each user to see only what was relevant and actionable. The responsive experience also worked exceptionally well, since the entire platform was designed mobile-first from scratch rather than simply adapted.
LIMITATIONS & TRADE-OFFS
The dashboards were designed strictly prioritizing clarity, speed, and usability over animations, visual complexity, or experimental aesthetics. It was a conscious product decision. On the technical side, the project's main debt was the absence of TypeScript in the backend and the lack of automated testing — especially integration tests for auth, payment, and concurrent booking logic. While it worked correctly, it required exhaustive manual testing in staging environments. We also sacrificed features like native push notifications or automatic reminders, which would have improved the client experience but fell outside the initial scope. And the business outcome was not what we were aiming for: the platform was delivered working, but the studio never put it in its clients' hands, so the system ended up with no real users. The most honest line I can write here is that one: the engineering is there, the adoption is not.
FROM GONZALO'S PERSONAL LOGBOOK: WHAT WOULD I DO DIFFERENTLY TODAY?
"I would migrate the backend entirely to TypeScript. I would add automated integration tests from the start. I would modularize the MercadoPago payment logic further to decouple it from membership logic. I would substantially improve observability and logging to more easily monitor production errors. And I would probably explore a notification and automated reminder architecture to further reduce client friction."
Retrospective note after launch