La pregunta más común que recibimos de otros fundadores no es sobre precios ni sobre el lanzamiento al mercado. Es una pregunta discreta y algo recelosa: ¿cómo mantiene un equipo de vuestro tamaño 150 módulos sin que todo se venga abajo? La respuesta honesta es que no mantenemos 150 módulos. Mantenemos una sola plataforma y una capa muy fina por encima. El truco está en ser implacables sobre a qué capa pertenece cada tarea.
Las cuentas que asustan a la gente.
Si imaginas 150 módulos como 150 pequeñas aplicaciones —cada una con su propio modelo de datos, sus permisos, su facturación y sus notificaciones—, entonces 22 personas es claramente una locura. Eso son seis módulos por ingeniero, cada uno un producto por derecho propio. Ningún equipo sobrevive a eso. El miedo es acertado para esa arquitectura.
Pero esa no es la arquitectura. Un CRM, una herramienta de facturación y una mesa de ayuda parecen tres productos distintos para el usuario. Por debajo, son el mismo puñado de primitivas: registros, relaciones, una línea de tiempo de eventos, roles y permisos, dinero, documentos y un bus de notificaciones. Las diferencias son sobre todo de vocabulario y diseño, no de maquinaria.
No estamos creando 150 grandes productos. Estamos creando un puñado de primitivos bien construidos, configurados de 150 maneras.
La división núcleo / módulos.
Todo lo difícil vive en el núcleo, y se construye una sola vez: identidad, permisos, la capa de datos relacionales, pagos, almacenamiento de archivos, búsqueda, el registro de auditoría, el sistema de notificaciones, el motor de exportación. Estas son las partes que son genuinamente difíciles y genuinamente compartidas. Un error corregido aquí queda corregido para los 150 módulos a la vez. Una capacidad añadida aquí — pongamos, las firmas electrónicas — queda instantáneamente disponible para todos los módulos que la quieran.
Un módulo, entonces, es deliberadamente ligero. Es un esquema de datos, un conjunto de vistas, uno o dos flujos de trabajo y el vocabulario para un solo trabajo. "CRM" es una configuración que dice: estos tipos de registro son prospectos y negocios, esta es la vista de embudo, estas son las etapas, y esto es lo que significa una conversión. Se apoya por completo en el núcleo. Un nuevo módulo es, en su mayoría, declaración, no código.
La regla de oro: gánate tu singularidad.
La disciplina que evita que esto se pudra es una sola regla, aplicada en la revisión: un módulo no tiene permiso para ser especial a menos que se lo haya ganado de verdad. Cada vez que un módulo quiere su propio modelo de permisos a medida, su propio formato de notificación puntual, su propia manera privada de almacenar una fecha, la respuesta por defecto es no. Llévalo al núcleo como una capacidad general, o no lo hagas.
Esto resulta molesto en el momento y decisivo a lo largo de los años. La mayoría de las peticiones de "necesitamos algo a medida aquí" son en realidad "no hemos pensado lo suficiente en el caso general." Cuando fuerzas el caso general, el núcleo se enriquece, cada módulo se beneficia y la superficie que tienes que mantener se mantiene prácticamente plana aunque el número de módulos crezca.
A qué renunciamos.
Este enfoque tiene un coste real, y conviene reconocerlo. Una herramienta especializada, creada por un equipo obsesionado con una sola tarea, superará en funciones a nuestro módulo equivalente en esa tarea concreta. La plataforma de correo más potente tiene automatizaciones que nosotros no tenemos. La herramienta de proyectos más completa tiene vistas que nosotros no tenemos. No pretendemos lo contrario.
Lo que sacrificamos a cambio de esa profundidad es coherencia: módulos que comparten un modelo de datos, un inicio de sesión, una factura, una exportación y una capa de notificaciones. Para un equipo de 5 a 50 personas, esa coherencia vale más que el último 20 % de profundidad en cualquier categoría. Para un equipo cuyo negocio entero es esa única categoría, no. Sabemos exactamente para quién somos, y la arquitectura es la razón por la que podemos atenderlos con 22 personas.