Zabira Studio
Plataforma de gestión y experiencia digital para estudio de pilates premium
"Sustitución de una plataforma externa de gestión fitness por un sistema propio que combina branding premium con un motor de reservas atómico y concurrencia optimizada."
El punto de partida del desafío
Hurgando bajo la superficie: ¿Qué investigué?
Las plataformas existentes resolvían la gestión operativa, pero generaban varios problemas: - Interfaces lentas y poco intuitivas - Experiencia genérica sin identidad de marca - Poca flexibilidad - Dashboards sobrecargados - Dependencia de terceros - Fricción para reservar clases El estudio buscaba una plataforma propia donde la experiencia se sintiera alineada al espacio físico, los clientes pudieran autogestionarse fácilmente, los instructores tuvieran herramientas simples y toda la operación estuviera centralizada. Analicé sistemas de booking fitness, dashboards administrativos y flujos de onboarding de clientes. También entendí que Zabira no competía por precio, sino por experiencia, percepción y exclusividad.
"La decisión más importante fue separar completamente dos experiencias: la landing pública (enfocada en branding, confianza y percepción premium) y el dashboard interno (enfocado en claridad, velocidad y funcionalidad pura). Esto evitó un error muy común: hacer dashboards "demasiado visuales" pero incómodos para operar diariamente. La landing sí podía ser emocional, elegante y narrativa, mientras que el sistema interno debía ser rápido, entendible y sumamente operativo. También entendí que la reserva de clases no era solamente una transacción sino que tambien era un momento de ansiedad para el cliente que quería asegurar su lugar. Si el sistema fallaba en ese instante, toda la percepción premium se venía abajo."
Comprender este pilar transformó por completo la dirección táctica del proyecto, permitiendo depurar el ruido innecesario y enfocarse en valor estricto.
Análisis de compromisos: opciones sobre la mesa
Construir software a medida requiere evaluar escenarios honestamente. Ninguna arquitectura es perfecta, cada decisión tiene un precio:
Seguir con la plataforma externa
Sin costo de desarrollo, pero seguía limitando la identidad de marca y la experiencia del cliente.
Sistema de reservas simple + landing separada
Más rápido de desarrollar, pero la desconexión entre ambas experiencias iba a generar fricción y pérdida de contexto.
Plataforma integral propia
Mayor inversión inicial, pero control absoluto de la experiencia, la marca, la operación y los datos del negocio.
La Decisión: El camino elegido
LO QUE FUNCIONÓ DE VERDAD
La landing pública terminó siendo uno de los puntos más fuertes, transmitiendo exclusividad y calma sin caer en la estética fitness genérica. La arquitectura de roles y separación de permisos fue sumamente sólida y escalable, permitiendo que cada usuario viera solo lo relevante y accionable. También funcionó de manera excelente la experiencia responsive, ya que toda la plataforma fue pensada desde cero para mobile y no simplemente adaptada.
LIMITACIONES Y COMPROMISOS
Los dashboards fueron diseñados priorizando estrictamente la claridad, rapidez y usabilidad por encima de animaciones, complejidad visual o estética experimental. Fue una decisión de producto consciente. A nivel técnico, la principal deuda del proyecto fue la ausencia de TypeScript en el backend y la falta de testing automatizado, especialmente de integración para la lógica de auth, pagos y booking concurrente. Aunque funcionaba correctamente, requería testing manual exhaustivo en entornos de prueba. También sacrificamos funcionalidades como notificaciones push nativas o recordatorios automáticos, que hubieran mejorado la experiencia del cliente pero quedaron fuera del alcance inicial. Y el resultado de negocio no fue el esperado: la plataforma se entregó funcionando, pero el estudio no llegó a ponerla en manos de sus clientes y el sistema quedó sin usuarios reales. La decisão más honesta que puedo escribir acá es esa: el trabajo técnico está, la adopción no.
DE LA BITÁCORA PERSONAL DE GONZALO: ¿QUÉ HARÍA DIFERENTE HOY?
"Migraría el backend completamente a TypeScript. Agregaría tests automatizados de integración desde el inicio. Modularizaría más la lógica de pagos de Mercado Pago para independizarla de la lógica de membresías. Mejoraría sustancialmente la observabilidad y el logging para monitorizar errores en producción con mayor facilidad. Y probablemente exploraría una arquitectura de notificaciones y recordatorios automatizados para reducir aún más la fricción del cliente."
Anotación retrospectiva posterior al lanzamiento