Roadmap del backend ConTodo

Objetivo: pasar de demo navegable (front + datos representativos + persistencia local) a un producto real multi-tenant, competitivo y AI-first. Caso piloto: empresa que produce y distribuye agua.

0. Estado actual (honesto)

Capa	Hoy
Frontend / UX	✅ Funcional, multi-rubro, navegable
Datos	🟡 Representativos (mock) + persistencia en navegador (localStorage)
Copiloto IA	🟡 Real con Gemini vía endpoint server (si hay GEMINI_API_KEY); si no, respuestas de respaldo
Backend / BD / Auth	❌ Por construir
SUNAT / Pagos	❌ Por construir

1. Decisión de stack (pragmático para llegar rápido)

Para time-to-market + AI-first, MVP full-stack sobre lo que ya existe:

• Next.js (Route Handlers / Server Actions) como API — un solo repo con el front.
• PostgreSQL gestionado (Supabase o Neon) con Row-Level Security.
• Prisma/Drizzle como ORM; Auth (Supabase Auth o Auth.js) con tenant_id en el token.
• Cola/jobs (Vercel Cron / Upstash QStash) para SUNAT, conciliación y forecasts.
• IA: Gemini/Claude vía capa de herramientas (MCP) que lee/escribe el ERP de forma segura por tenant.

La propuesta técnica original (Rails + PostgreSQL + Redis + Sidekiq) sigue válida para escala; se puede extraer servicios después. Hoy prima velocidad sin sacrificar el modelo multi-tenant.

2. Multi-tenant: el corazón

• Aislamiento: tenant_id obligatorio en todas las tablas + RLS (la base bloquea acceso cruzado, no solo el código).
• Config por rubro: lo que hoy es verticalData se vuelve Vertical Pack versionado en BD (módulos activos, productos semilla, reglas, PCGE).
• Fuente de la verdad única → habilita la consolidación de data y la IA.

3. Fases y entregables

Fase	Entregable	Por qué importa
1. Core	Auth multi-tenant, RBAC, modelo canónico, API REST, Vertical Packs en BD	Base sobre la que todo se apoya
2. Operación	Ventas, inventario en tiempo real (descuenta al vender), compras, caja	El dolor #1 del cliente de agua: stock en línea
3. Cumplimiento	Facturación electrónica SUNAT (OSE/SEE), boleta/factura/NC/ND, PLE/SIRE, asientos PCGE	Lo que ningún global hace bien en Perú
4. Pagos	Adaptador de pagos (Culqi/Izipay/Yape) + conciliación con referencia CT-APP-TENANT-corr	Saber de dónde vino cada sol (ver doc 19)
5. AI-first	Copiloto sobre datos reales (MCP), forecast de ventas/inventario/caja, agente configurador	El diferenciador competitivo

4. Qué significa "AI-first" (no IA pegada al final)

• Cada módulo expone herramientas (no solo pantallas) → el LLM puede consultar y ejecutar acciones con permisos del usuario.
• Forecasting integrado: predicción de ventas, punto de reposición de bidones, proyección de caja.
• Agente configurador: crea/ajusta el negocio conversando (config-as-data).
• Hoy ya hay un primer paso real: el Copiloto responde con Gemini usando los datos del negocio en la demo.

4.1 ¿Un MCP por empresa (tenant)? No: uno solo, multi-tenant

Igual que no corres una API por cada empresa, tampoco corres un MCP por empresa. Corres un solo MCP multi-tenant donde cada llamada lleva el tenant_id y el rol del usuario, y las herramientas filtran por ese tenant.

Enfoque	Veredicto
1 MCP multi-tenant (recomendado)	El token de sesión define tenant_id + rol; cada herramienta valida y filtra. Un solo servidor, escala a miles de empresas, barato.
1 MCP por empresa	Pesadilla operativa (un servidor por cliente), caro, y no da más aislamiento del que ya logras con tenant_id + RLS + credenciales por sesión.

El aislamiento real viene de: credenciales con tenant_id por sesión + tenant_id en cada consulta + RLS en la base + chequeo de permiso por herramienta (un vendedor no puede llamar tools de contabilidad). Así el agente de la Empresa A no puede ver datos de la B.

Matices:

• Per-tenant ≠ servidor por tenant. Si una empresa conecta su propia IA (p. ej. Claude Desktop) a su ConTodo, le das un endpoint/credencial por tenant, pero detrás está el mismo servidor MCP compartido.
• Cliente enterprise que exija instancia dedicada por compliance → despliegue dedicado como excepción (tier enterprise), no por defecto.
• Herramientas a medida por rubro → se activan por configuración/feature-flags dentro del mismo MCP, no con otro servidor.

5. Por qué seremos competitivos

Frente	ConTodo	Odoo / globales	Legados (CONCAR/SISCONT)
SUNAT nativo	✅	🟡 localización cara	✅ pero on-premise
Multi-tenant cloud	✅	🟡	❌
Inventario en línea	✅ tiempo real	🟡	❌
AI-first	✅ copiloto + agentes	❌	❌
Multi-rubro (1 core)	✅	🟡	❌

6. Primeros pasos concretos (semana 1–2)

1. Crear repo backend (o carpeta api/ + BD en el mismo repo) y provisionar Postgres (Supabase/Neon).
2. Modelar tenants, usuarios, roles + RLS; migrar profiles/verticalData a tablas.
3. Endpoint de ventas e inventario reales (reemplazar mock por BD) — empezar por el rubro agua.
4. Conectar el Copiloto a datos reales (ya tiene la vía Gemini).
5. En paralelo: pedir tarifas a Culqi/Izipay y definir modelo de recaudación/split (doc 19).

Recomendación: construir vertical agua de punta a punta (venta → inventario en línea → reparto → cobranza → SUNAT) como primer caso real; luego replicar a los demás rubros activando packs.