Plataformas reutilizables: el motor que sirve para 5 verticales (y cómo pensarlas)

Cuando estás armando el segundo o tercer producto de una misma familia, llega el momento de la verdad. Empezaste con un CRM para salones de eventos. Después vino una inmobiliaria que necesitaba algo similar pero adaptado. Después un taller mecánico, después una clínica. Cada uno parecía "completamente distinto", pero el 70% del código se repetía.

Ese es el momento de pensar en plataforma reutilizable. Hay una forma correcta y una incorrecta. Empecemos por la incorrecta porque es la que más se ve.

El error: forzar abstracción temprana

El error típico es generalizar antes de tiempo. Después del primer producto, alguien dice "esto se puede usar para muchos negocios". Se invierte tiempo en abstraer todo, agregar configuración infinita, hacer el código "genérico". Y termina pasando una de dos cosas:

• La plataforma se vuelve tan configurable que para usarla en cada caso nuevo hay que aprender un lenguaje propio.
• Las "configuraciones" cubren el 80% de los casos pero el último 20% requiere modificar la plataforma, lo que rompe a los otros clientes.

La regla: abstraer después del tercer caso real, no antes. El primer producto resuelve un problema. El segundo te enseña qué tiene en común con el primero. El tercero confirma el patrón. Antes de eso, todo lo que abstraes es especulación.

El patrón que si funciona: motor + adaptadores

Una plataforma reutilizable bien hecha tiene dos capas:

1. Motor: lo que es común a todos los verticales. Pipeline de estados con transiciones, propuestas con versionado, gestion de contactos, calendario, pagos, notificaciones, auditoría de cambios, multi-usuario con roles, multi-tenant aislado.

2. Adaptador por vertical: lo que es específico de cada negocio. La definición de los estados (un salon de eventos tiene "visita agendada", un taller tiene "auto recibido"), las reglas de transición ("no se puede facturar sin presupuesto aprobado"), los campos custom, los reportes específicos.

El motor tiene que ser lo más opinionado posible sobre la estructura común (así no se rompe entre verticales) y lo más flexible posible en la configuración del vertical.

Cómo lo aplicamos en La Carolina y más allá

La Carolina empezó como CRM para salones de eventos. El motor que armamos ahí sirve para:

• Catering: mismo pipeline de pedido/propuesta/evento/pago.
• Inmobiliarias de alquileres: cambian los estados (visita, oferta, contrato), pero la estructura es la misma.
• Servicios profesionales con propuesta: estudios contables, agencias, consultoras.
• Eventos B2B: ferias, congresos, capacitaciones.

El motor ya hace: estados configurables, propuestas con versionado, sync con Google Calendar, pagos parciales con seña, notificaciones automaticas por transición. Adaptar a un nuevo vertical es semanas, no meses.

Multi-tenant: la decisión arquitectonica clave

Si vas a vender la plataforma a múltiples clientes (no es la misma empresa con distintos verticales internos), necesitas que cada cliente vea solo sus datos. Esto es multi-tenancy, y hay tres formas de hacerlo:

1. Database per tenant: una base de datos completa por cliente. Máximo aislamiento, máximo costo y complejidad. Tiene sentido en industrias muy reguladas (salud, financiero) con pocos clientes grandes.

2. Schema per tenant: una sola base, schemas separados por cliente. Punto intermedio: aislamiento decente, costos razonables, más complejidad operativa que un schema único.

3. Shared schema con tenant_id: una sola base, una sola estructura, una columna que identifica al cliente. Más barato y más simple, pero requiere disciplina absoluta para que el aislamiento se respete (aca es donde entra Row Level Security a nivel base de datos, no a nivel código).

Para SaaS B2B con muchos clientes medianos, shared schema + RLS es lo que mejor relación costo/beneficio tiene. Pero el aislamiento NO puede depender solo del código: tiene que estar también en la base.

El tradeoff del producto-más-plataforma

Cuando armas algo así, tenés dos tipos de cliente:

• Los que usan el producto vertical estandar (más barato, configuración limitada).
• Los que necesitan adaptaciones específicas (más caro, plataforma adaptable).

El error es tratarlos igual. Lo que funciona: producto vertical con licencia mensual estandar para los primeros, proyecto de implementación + licencia para los segundos. Distintos precios, distintos contratos, distintos equipos atendiendo cada uno.

Cuándo NO es una plataforma reutilizable

No todo se beneficia de hacerse plataforma. No tiene sentido si:

• Cada cliente es muy diferente: si las "configuraciones" en cada caso terminan siendo el 80% del trabajo, no es plataforma, son productos distintos disfrazados.
• Tu mercado es chico: si vas a tener 3 clientes en total, plataforma es overkill. Hace los 3 productos a medida y listo.
• El soporte y la implementación son la mayor parte del trabajo: si vendes consultoría con software adentro, más que plataforma B2B SaaS, es servicios profesionales.

Conclusión

Las plataformas reutilizables son hermosas cuando están bien pensadas, y un infierno cuando están mal. La diferencia está en esperar al tercer caso real antes de abstraer, separar claramente motor y adaptadores, y resolver multi-tenancy desde el día uno con seguridad a nivel base.

Si estás evaluando construir tu propio motor reutilizable, o vendes un producto vertical y querés expandirte a otros verticales similares, escribinos. Te ayudamos a pensar la arquitectura antes de escribir código que después sea difícil de revertir.

---

Por Esteban Aleart, Founder & Lead Engineer de Pair Programming.