Caso de estudio
Eclipse
Una plataforma white-label donde estudios boutique y coaches independientes manejan su negocio bajo su propia marca — software que se ve y se siente como el estudio, no como el proveedor. Construido para cómo Latinoamérica realmente paga y se comunica.
Fundador, Diseño y Desarrollo — 2025–Presente
El reto
Los estudios boutique compiten por la experiencia — y luego su software rompe el encanto.
Compiten por la luz, la playlist, la manera en que se siente una clase. Sin embargo, las plataformas de gestión de estudios están construidas como ERPs empresariales: páginas de reservas genéricas con la marca de alguien más, interfaces en inglés primero, flujos de pago que no aceptan cómo realmente paga México. Para un estudio boutique, el flujo de reservas es el lobby digital — y las opciones existentes eran caras, rígidas y, lo peor de todo, todas se ven iguales.
Los estudios elegían entre hojas de cálculo y software que borraba su identidad.
Mi rol
Fui dueño del producto de principio a fin — y eso moldeó cada decisión.
Lideré el descubrimiento, el UX, la UI, el sistema de diseño y escribí el código de producción. Como fundador-diseñador-ingeniero en solitario, el diseño y la ingeniería no eran conversaciones separadas: no podía lanzar una pantalla que no pudiera también construir y mantener, así que la factibilidad estaba integrada en el diseño desde el primer boceto.
Esa restricción se volvió una ventaja. Las decisiones avanzaban rápido, nada se perdía en el handoff, y el sistema de diseño y el código se mantenían sincronizados porque la misma persona era dueña de ambos. Eclipse está diseñado, construido y operado por una sola persona, trabajando AI-native en producción.
Proceso
Del descubrimiento a un producto en producción.
-
Descubrimiento
Me senté con dueños de estudios para mapear cómo manejaban hoy las reservas, membresías y pagos — y exactamente en dónde se rompía.
-
Flujos y arquitectura
Diseñé los flujos centrales — reservas, membresías, pagos — sobre una arquitectura multi-tenant donde cada estudio es su propia instancia aislada y con su marca.
-
Sistema de diseño
Diseñé un sistema de diseño basado en tokens — convenciones de shadcn adaptadas a Rails y Tailwind — donde cada estudio es un tema, no un fork. El sistema vive en el código como la fuente de verdad; Figma es la capa de exploración.
-
Construir y lanzar
Escribí el código de producción (Rails, Hotwire, Stripe Connect) y lancé con los primeros estudios, iterando contra el uso real.
-
Integrar y escalar
Agregué integraciones a nivel de plataforma con redes de bienestar corporativo (Wellhub/Gympass) y reduje el onboarding de un nuevo estudio a menos de cinco días.
Decisiones clave y su razonamiento
Tres elecciones que definieron el producto.
El software desaparece
Eclipse es invisible por diseño. Cada estudio corre en su propio dominio, con su propio color, tipografía y tono — a lo largo de reservas, correos de confirmación, recibos y pases de clase. Los dueños no configuran un constructor de páginas; obtienen una experiencia de marca diseñada, entregada como parte del producto.
Por debajo, es un solo sistema basado en tokens donde cada estudio es un tema, no un fork. Así es como un equipo de una sola persona diseña, lanza y mantiene ocho productos con marca propia en producción.
Cada estudio opera bajo sus propias reglas
No hay dos estudios que operen igual — ventanas de cancelación, cortes de reserva, cupos de clase, cómo funcionan los créditos y las membresías. Las opciones existentes imponen un solo modelo rígido y obligan a los estudios a adaptarse a él. Eclipse invierte eso: las políticas de cada estudio son configuración, no un desarrollo a medida, así que la plataforma se adapta a cómo realmente opera una yoga shala, un estudio de Pilates o un coach independiente — sin nunca forkear el producto.
Construido para cómo paga México
Los precios y flujos de pago se diseñaron en torno a los pesos y al comportamiento de pago local sobre Stripe Connect, en lugar de forzar el modelo centrado en EE. UU. y solo con tarjeta que asumían las opciones existentes.
El otro lado del mostrador
Un miembro ve Eclipse tres minutos a la semana. El dueño vive en él horas al día.
Agendas, membresías, dinero, asistencia. Por eso la administración corre bajo valores de diseño distintos a los del lado del miembro: densidad sobre drama, velocidad sobre deleite, tolerancia sobre fricción. El mismo sistema de tokens, distinta temperatura.
Agendas que sobreviven a la vida real
Los estudios no corren sobre eventos aislados — corren sobre ritmos. En Eclipse, un dueño crea una clase una vez y la serie se encarga sola. Los instructores suplentes, los días festivos y los cambios de cupo se manejan como excepciones que nunca rompen la recurrencia — ni las reservas que los miembros ya hicieron contra ella.
Los calendarios recurrentes están entre los problemas de UX de agendamiento más difíciles que existen. La meta de diseño era simple: el dueño nunca debería tener que saberlo.
Reportes que responden preguntas, no exportan tablas
Los dueños no quieren dashboards — quieren respuestas a las preguntas del lunes por la mañana. ¿Qué clases realmente se llenan? ¿Cómo cerró el mes? ¿La membresía está creciendo o perdiéndose en silencio?
Los reportes de Eclipse están diseñados en torno a esas preguntas: ingresos, asistencia y salud de la membresía legibles de un vistazo, con el detalle siempre a un tap de profundidad. El trabajo de diseño aquí no eran gráficas — era decidir qué preguntas merecen la portada.
Una sola lista, todas las fuentes
Una clase se llena con reservas directas y reservas de Wellhub al mismo tiempo. Eclipse combina ambas en una sola lista en vivo — la recepción registra a todos desde una misma lista, y el dueño nunca reconcilia dos sistemas.
Las integraciones son invisibles cuando funcionan. Ese es el diseño.
Puntos de contacto
La marca no se rompe en el checkout.
Los correos de confirmación, los recibos de pago, las renovaciones de membresía y los pases de clase salen tematizados por defecto — la experiencia que un miembro recibe en su bandeja de entrada coincide con la que siente en el estudio. La mayoría de las plataformas tratan esto como algo secundario: un recibo genérico de un proveedor que el miembro nunca eligió. Pero el momento en que un cargo se procesa o un lugar se confirma es exactamente cuando se gana o se pierde la confianza — así que en Eclipse cada uno de esos momentos lleva la marca del estudio, no la del proveedor. Los detalles que otras herramientas ignoran son los que los miembros realmente recuerdan.
Impacto
Un producto sobre el que estudios reales manejan su negocio.
"No se siente como software que compramos. Se siente como algo que construimos."— Ana Rovira, Mun Yoga Studio
Lo que me llevé de esto
Diseñar como alguien que también lanza.
Eclipse me enseñó a tratar cada pantalla como un conjunto de tradeoffs reales de producto, negocio e ingeniería — no solo como un layout. Ser dueño de todo el arco me hizo un diseñador más agudo: aprendí a defender decisiones con razonamiento, a recortar alcance sin perder la experiencia, y a diseñar sistemas que sobreviven al contacto con la producción.