Tiene una herramienta que funciona para un cliente y quiere vendérsela a otros diez. Es el reflejo correcto: el desarrollo ya está pagado y cada cliente adicional cuesta menos que el primero. Queda una pregunta de apariencia técnica cuya respuesta es comercial: ¿cada cliente tiene su aplicación, o todos comparten la misma?
Los dos modelos existen, tienen nombres distintos y no cuestan lo mismo.
El modelo de marca blanca: una aplicación por cliente
Una sola base de código, pero tantas aplicaciones publicadas como clientes. Cada uno tiene la suya: su nombre, su logotipo, sus colores, su ficha en las tiendas. Sus usuarios no saben —ni necesitan saber— que la misma base hace funcionar a otras diez organizaciones.
Lo que le aporta. Su cliente existe ante sus propios miembros. Para una asociación, un club o una franquicia, ese suele ser todo el argumento: la herramienta no parece una suscripción contratada a un tercero, parece algo que la organización hizo para los suyos.
Lo que le cuesta. Cada cliente es una publicación más. Una actualización de seguridad son diez envíos en dos tiendas, diez revisiones editoriales que pasar, diez juegos de capturas que mantener al día. La factura real de la marca blanca no está en el código, está en la distribución.
El modelo multi-tenant: una sola instalación para todos
Una sola aplicación, un solo servidor, una sola base de datos. Los clientes conviven, compartimentados: cada uno solo ve sus datos. Es el modelo de casi todo el software vendido por suscripción.
Lo que le aporta. Un cliente más no cuesta casi nada: ninguna publicación, ningún servidor adicional, ninguna versión que mantener aparte. Corrige un defecto una vez y todos se benefician el mismo día.
Lo que le cuesta. La compartimentación de los datos se convierte en la pregunta más importante del proyecto. Un solo error —una consulta que olvida filtrar por el cliente correcto— y una organización ve los datos de otra. Es el tipo de incidente del que no se sale comercialmente, y no se trata al final del proyecto: se decide en las primeras semanas, en la propia estructura de los datos.
La pregunta que de verdad lo decide
No es técnica:
¿Su cliente debe aparecer como editor de la herramienta ante sus propios usuarios?
Si la respuesta es sí —asociación, club, federación, franquicia, red de agencias—, la marca blanca se impone, y hay que aceptar el coste de distribución que conlleva.
Si es no —sus clientes asumen que usan un software del mercado, igual que asumen su programa de contabilidad—, el multi-tenant es casi siempre la elección correcta, y la única que permite añadir un cliente sin dedicarle una semana.
Por cierto, ambos se combinan muy bien: es habitual que un mismo servidor multi-tenant alimente varias aplicaciones en marca blanca. Es incluso la configuración más cómoda, a condición de haberlo decidido antes de escribir la primera pantalla.
La trampa que mata a los dos modelos
Es idéntica en ambos casos y siempre se comete por buenas razones.
Un cliente pide un ajuste. No es gran cosa. Se programa «solo para él», en su versión. Seis meses y tres clientes después existen cuatro variantes del mismo software, y cada corrección hay que escribirla, probarla y publicarla cuatro veces. El producto ha muerto antes de ser rentable.
La disciplina que lo evita cabe en una regla: nada específico de un cliente entra en el código de producto. Un cliente solo posee una configuración y unas imágenes. Todo lo demás es genérico —y cuando una petición no se puede formular de forma genérica, casi siempre es que se ha entendido mal.
Aplicamos esta regla en nuestros propios productos: una suite en marca blanca para asociaciones por un lado, y una plataforma multi-tenant para clubes por otro. Son dos respuestas distintas a la misma pregunta, y la elección se hizo antes de la primera línea de código.
¿Está usted en ese punto? Es exactamente el tipo de decisión que trata una fase de consultoría y arquitectura: unos días al principio del proyecto que determinan lo que costará su décimo cliente. Hablemos — la primera conversación es gratuita.
