Silos
Tu catálogo, tus precios y tus reglas viven repartidos entre cinco proveedores que no comparten una sola verdad.
Runtime multi-tenant · pre-cutover
El motor que unifica funnels, checkout, suscripciones, contenido, analytics y automatización — con aislamiento total por tenant, billing in-house y una traza forense de cada centavo.
/ 01 — el problema
Un CMS acá, un checkout allá, suscripciones en otra herramienta, analytics que no cuadran. La lógica de tu negocio se dispersa entre SaaS que no se hablan entre sí.
Tu catálogo, tus precios y tus reglas viven repartidos entre cinco proveedores que no comparten una sola verdad.
El ciclo de vida de tus suscripciones vive dentro del procesador. Migrar de Stripe a PayPal es rehacerlo todo.
Cuando algo falla, reconstruir qué pasó son ocho consultas manuales y una tarde perdida.
Sumar un segundo negocio duplica la infraestructura en lugar de reutilizarla.
/ 02 — los motores
Genéricos por diseño: lo específico de cada negocio entra por composición, nunca por fork. La frontera plataforma↔tenant la verifica un gate en CI.
Landings, checkout y upsells como datos versionados. Variantes y experimentos nativos, sin pegar tres herramientas.
Productos, ofertas, cupones, suscripciones y renovaciones son tuyos. El procesador sólo mueve la plata.
Un lattice de planes config-driven decide acceso por área y contenido. Los claims sobreviven a la cancelación.
Fábrica de webcomics, libros y podcasts con versionado por edición, imagen por IA y audio sincronizado.
MRR, ARR, churn y LTV desde una única capa canónica. Una sola fórmula, cero dashboards que se contradicen.
Manifests declarativos que reaccionan a platform.events. El sistema se opera solo y deja rastro de todo.
/ 03 — billing
Nexus es merchant-managed: no delega el ciclo de vida en Stripe Subscriptions ni en PayPal. Un cron propio cobra con los métodos de pago guardados, aplica dunning y concilia. El modelo de negocio vive en el runtime, no en el procesador.
Reintentos de cobro · dunning
intercambiables · auto-detección Vault ↔ Billing Agreement
/ 04 — observabilidad forense
Cada acción emite un trace_id que atraviesa todos los spans y aterriza en platform.events, consultable en SQL. Un dossier reconstruye el caso completo sin adivinar.
/ 05 — multi-tenant
Cada tenant tiene su propia autenticación, su schema Postgres, su dominio y sus cookies. Los motores se comparten; los datos, jamás. La frontera la enforced un gate de arquitectura.
El negocio educativo de dibujo: Academy por membresía y Collection de piezas reclamables.
Banco de pruebas de la plataforma. Valida motores nuevos sin billing activo.
El plano de control global: operación, observabilidad y automations.
El próximo tenant. Traés tu dominio; heredás los seis motores el día uno.
/ 06 — operado por agentes
Nexus se diseñó para operarse con agentes IA de desarrollo y operación — Claude Code, Codex — sobre datos, no sobre capturas. La observabilidad tiene una guía escrita para agentes y una bitácora consultable: no es un asistente de cara al cliente, es un sistema legible por máquinas.
# nexus agent-notes list --area billing
note "renovación 8412 recuperada"
trace_id 7f3a·c9e1·84b2
dunning reintento +7d → ok
fuente platform.events
# si no está en la base, no pasó./ 07 — precios
Visión de producto. Hoy Nexus opera un puñado de negocios propios en pre-cutover; abrir el runtime a terceros es la hoja de ruta. Los planes son indicativos.
Un negocio, los seis motores, billing propio.
Varios negocios sobre el mismo núcleo, con automations y partners.
Aislamiento dedicado, SLAs y onboarding a medida.
* Nexus está en pre-cutover: WooCommerce sigue siendo la producción viva. Las cifras y los planes ilustran el modelo del producto; no son una oferta comercial vigente.
Onboarding asistido, tus seis motores el día uno y una traza de cada evento desde la primera línea.
Acceso por invitación · pre-cutover