App Factory: una app por cliente sin escribir código por cliente

El problema: 1.200 gimnasios, una sola app y cero escalabilidad

Cada gimnasio cliente de trainingym — el SaaS B2B donde soy cofundador y CTO — quería su propia app. Con su logo, sus colores, su nombre en la App Store. No una app genérica donde el gimnasio fuera “una opción del menú” — su app, la que el socio descarga y abre con el branding del gimnasio.

Hacerlo a mano era inviable: 1.200+ gimnasios × 2 plataformas (iOS + Android) × cada actualización de la app = nunca terminarías. Pero dar una app única “blanca” era perder la propuesta de valor: los gimnasios querían ser la marca en el móvil de sus socios, no sub-inquilinos de la nuestra.

El coste de no resolverlo: cada comercial que cerraba un gimnasio entraba en el embudo de “app en desarrollo, disponible en 4-6 meses”. Muchos desistían antes de llegar a producción.

La decisión: arquitectura multi-tenant para apps móviles en App Store y Google Play

Construir una fábrica de apps: un único código fuente que se compila y publica automáticamente como N apps distintas, una por cliente. Cada app hereda branding, credenciales y configuración de su gimnasio, pero el código es el mismo en todas.

Decisión controvertida en su día: los equipos mobile tradicionales asumen que “una app = un proyecto”. Decidimos romper ese supuesto: las variables (logo, colores, nombres, credenciales push) son datos, no código. El código es igual para todos; solo cambia la configuración en el momento de compilar.

Qué construí: una App Factory multi-tenant para 21 países

Un pipeline automatizado que:

• Lee la configuración de cada cliente (branding, API keys, credenciales de notificaciones push).
• Genera los assets visuales personalizados al vuelo (iconos, splash screens, estilos).
• Compila las dos versiones (iOS + Android) con el mismo código base.
• Publica automáticamente en App Store Connect y Google Play con credenciales específicas del cliente.
• Gestiona actualizaciones: cuando hay una nueva versión del producto, se despliega a los 1.200+ gimnasios sin tocar cada app manualmente.

Detrás: infraestructura cloud para build paralelos, gestión de certificados y claves por cliente, y un sistema de notificaciones push que enruta cada notificación al Firebase correcto según el gimnasio.

Resultado: 1.200+ apps personalizadas publicadas desde un único sistema

• 1.200+ apps en producción, cada una con su branding, en 21 países.
• Onboarding de cliente nuevo reducido a días: firmar contrato, rellenar branding, disparar build. Ya no hay “fase mobile” en el proyecto — viene incluida.
• Escalabilidad real: el siguiente cliente es igual de rentable que el último. Nada de “a partir de X clientes perdemos margen por mantenimiento”.
• Ciclo de release unificado: una única versión del producto mobile en toda la red de clientes.

Lección: cuándo dejar de parchear y reescribir la arquitectura

La decisión clave fue tratar las diferencias entre clientes como datos, no como código. En el momento que lo asumes, el problema de “cómo escalo 1.200 apps” deja de ser un problema de equipo y se convierte en un problema de pipeline — que sí se puede resolver.

Mensaje para el CEO: cuando un producto requiere personalización por cliente, la pregunta no es “¿cuánta gente necesito contratar?” sino “¿cómo convierto la personalización en configuración?”.