ConTodo como Plataforma: Core único + Verticales + Data unificada
ConTodo como Plataforma: un Core, muchos negocios, una sola data
1. La idea en una frase
ConTodo no es un ERP más: es la plataforma base (core) sobre la que se construyen apps verticales por rubro. Cada negocio que se vende "cae" sobre el mismo core, por lo que toda la data se consolida en un solo lugar — y eso es el activo más valioso.
Esto convierte cada venta (una distribuidora de agua, un gimnasio, una pollería, un importador de autopartes) en más datos sobre el mismo motor, no en otro sistema que mantener. El valor compuesto está en la data unificada + la IA que opera sobre ella.
2. ¿Es posible? Sí — y ya está encaminado
La demo actual demuestra el principio clave: un rubro nuevo es configuración, no un app nuevo. Agua, Gamarra (venta/producción), autopartes, pollería y gimnasio corren sobre el mismo código, cambiando solo:
- qué módulos se activan,
- los datos semilla (productos, planes, KPIs),
- las reglas del rubro (p. ej. membresías recurrentes, reparto, costeo de importación).
Eso es config-as-data: la base técnica para que un agente de IA configure negocios nuevos automáticamente (ver §6).
3. Arquitectura en capas
Tres capas, una sola base:
| Capa | Qué es | Se reescribe por rubro? |
|---|---|---|
| Core | Multi-tenant, RBAC, modelo de datos canónico, contabilidad/SUNAT, inventario, billing, API+MCP | ❌ Nunca |
| Vertical Pack | Configuración declarativa: módulos activos, datos semilla, reglas, mapeo PCGE, roles | ✅ Solo config |
| App / Marca | La UI y el branding que ve el cliente (puede ser la misma app con tema, o una marca propia) | ✅ Opcional |
4. Por qué un solo core (y no apps separadas)
| Si haces apps separadas… | Con un core de plataforma… |
|---|---|
| Duplicas login, billing, contabilidad e infra en cada app | Se construyen una vez y todos los rubros los heredan |
| La data queda fragmentada en silos | Toda la data en un lugar → BI y IA cross-negocio |
| Cada rubro nuevo = meses de desarrollo | Cada rubro nuevo = un pack de configuración (días) |
| Mantienes N sistemas | Mantienes 1 core + packs ligeros |
| Sin efecto de red de datos | El dato se acumula → mejor IA, benchmarks, scoring |
5. El modelo de datos canónico (la clave de "toda la data")
Todo escribe al mismo esquema, etiquetado por tenant_id (empresa) y vertical. Un comprobante de la pollería y uno del gimnasio son la misma entidad comprobante con reglas distintas.
💡 Como todo comparte el esquema canónico, el Data Warehouse puede comparar márgenes, rotación y estacionalidad entre rubros y entre clientes (anonimizado) — un activo que ningún competidor local tiene.
6. El Agente Configurador (onboarding por IA)
Como los rubros son config-as-data, un agente de IA (Claude vía MCP) puede crear un negocio nuevo conversando:
Esto no es otro producto: es una capa de orquestación sobre el mismo core, usando la arquitectura MCP + Claude ya descrita en el documento técnico.
7. Estrategia de plataforma y monetización
- Suscripción base (core + 1 vertical) + add-ons (IA, módulos extra, sedes).
- Packs verticales como SKUs (Agua, Gym, Resto, Autopartes…): cada uno acelera la venta a ese nicho.
- Marketplace de packs: terceros (consultores) crean packs sobre el core → efecto plataforma.
- Servicios de datos (a futuro, con consentimiento): benchmarks de industria, scoring crediticio, compras grupales — habilitados por la data unificada.
8. Consideraciones y riesgos
| Tema | Cómo se maneja |
|---|---|
| Aislamiento de datos | tenant_id obligatorio + Row-Level Security; la consolidación analítica usa datos agregados/anonimizados con consentimiento |
| Gobernanza y privacidad | Política de uso de datos clara; opt-in para benchmarks; cumplimiento Ley N° 29733 (Protección de Datos Personales, Perú) |
| Versionado de packs | Cada pack tiene versión; migraciones controladas para no romper tenants en producción |
| Personalización vs. estándar | El core no se bifurca por cliente; las diferencias viven en el pack/config, nunca en el código base |
| Escala | Multi-tenant shared-schema con tenant_id (ver documento de arquitectura) escala a miles de tenants sin un sistema por cliente |
9. Conclusión
Sí: ConTodo puede (y debe) ser el core de muchos negocios. La arquitectura config-as-data ya demostrada en la demo es la prueba de concepto. El camino:
- Endurecer el core (facturación SUNAT real, inventario en tiempo real, billing, API/MCP).
- Formalizar el formato de "Vertical Pack" (lo que hoy es
verticalData). - Construir el Agente Configurador para onboarding por IA.
- Activar el Data Warehouse para BI y servicios de datos cross-negocio.
Cada negocio vendido deja de ser "un proyecto" y pasa a ser más data y más músculo para la plataforma.