🔒
Acceso privado
Ingresa la contraseña para continuar
Contraseña incorrecta
Instancia por cliente · Sin multi-tenancy · Full control

FacturaEC

Una instalación independiente por cada cliente empresa. Mismo código, configuración y base de datos propios, servidor dedicado — cero dependencia entre clientes.

11sem
MVP funcional
28sem
Producto completo
~15min
Onboarding nuevo cliente
1
Instancia por empresa
Cómo funciona

Un repositorio, N instalaciones independientes

El código es el mismo para todos los clientes. Cada empresa tiene su propio servidor, su propia base de datos y su propia configuración. No hay un cliente afectando a otro.

Repositorio Central GitHub · misma versión para todos monorepo NestJS + React deploy.sh deploy.sh deploy.sh Cliente A — Empresa XYZ empresa-xyz.factura-ec.com NestJS + React PostgreSQL Redis Nginx + SSL RUC: 0912345678001 · cert. propio Cliente B — Comercial ABC comercial-abc.factura-ec.com NestJS + React PostgreSQL Redis Nginx + SSL RUC: 1712345678001 · cert. propio Cliente C — Distribuidora N distrib-n.factura-ec.com NestJS + React PostgreSQL Redis Nginx + SSL RUC: 0512345678001 · cert. propio Las instancias no se comunican entre sí — aislamiento total por diseño

Aislamiento real

Cada cliente tiene su propia BD, sus propios certificados y su propio proceso. Una caída o un error en el cliente A no existe para el cliente B.

Personalización sin límites

Si el cliente C necesita un campo extra, un flujo distinto o una integración específica, se toca esa instancia sin afectar a nadie más.

Data en sus manos

Empresas con requisitos de compliance, bancos, o clientes que no pueden usar SaaS compartido pueden alojar en su propio servidor.

Comparación

Instancia dedicada vs SaaS multi-tenant

Cada modelo tiene su lugar. Esta comparación asume el mismo equipo de 3 devs y el mismo stack NestJS + React.

Dimensión Instancia por cliente SaaS multi-tenant
Complejidad del código Menor
Sin tenant_id, sin aislamiento lógico, schemas simples
Mayor
Todo el código lleva contexto de empresa, mayor riesgo de fuga de datos
Tiempo de MVP 11 semanas
Sin SuperAdmin, sin multi-tenant
14 semanas
Multi-tenancy + SuperAdmin añaden complejidad
Onboarding de un cliente nuevo Script ~15 min
Requiere servidor disponible. Automatizable.
Registro web <1 min
Self-service, sin intervención técnica
Actualizaciones Script por instancia
Hay que correr el update en cada cliente. Automatizable con pipeline.
Un deploy, todos actualizados
Todos los clientes siempre en la última versión
Personalización por cliente Total
Campos extra, flujos distintos, integraciones ad-hoc
Limitada
Solo lo que el sistema prevé para todos
Aislamiento de datos Por diseño
BDs y servidores separados. No es posible la fuga entre clientes.
Lógico (por código)
Un bug puede exponer datos de otro tenant
Escalar a 100+ clientes Operacional
100 servidores, 100 BDs — costoso sin automatización
Código
Escala con la infraestructura compartida
Monitoreo central No nativo
Requiere dashboard de salud adicional (iter 3+)
Natural
Un solo sistema, métricas centralizadas
Tipo de cliente ideal Empresas mediana/grande
Pagan por instancia, quieren control total
Empresas pequeñas / volumen
Muchos clientes, bajo costo por cliente
Equipo

3 devs full stack — mismo equipo, menor carga

Los roles son idénticos al plan SaaS. La diferencia es que la complejidad de multi-tenancy desaparece, liberando tiempo para el deploy script — el nuevo entregable crítico de este modelo.

Tech Lead · Full Stack + DevOps + Deploy
Lead / Arquitecto
Monorepo + Docker Compose + CI/CD desde S1
auth + company (single-tenant, simple)
Dueño del sri-service
Deploy script v1 como entregable del MVP
Update script + automatización por cliente
100% · Semana 1 → 28
Full Stack Dev Sr. · Documentos + Integración
Dev 1 — Ciclo de vida + Emisión
document-service desde S1 (schema + CRUD)
notification-service · RIDE PDF · email
UI de emisión · historial · estados
integration-service + API pública (iter 3)
Conectores ERP (iter 4)
100% · Semana 1 → 28
Full Stack Dev Mid · Catálogo + Admin
Dev 2 — Core + Paneles
Design system + componentes UI desde S1
catalog-service + UI admin MVP
Admin avanzado (iter 2)
ERP UI + Reportes ATS (iter 4–5)
Portal cliente final (iter 5)
100% · Semana 1 → 28
🧪
Testers — equipo separado
S9: QA funcional en ambiente SRI pruebas. S18: QA comprobantes completos. S24: QA conectores + ATS. El deploy script también debe ser testeado con un cliente real antes de usar en producción.
Cronograma

28 semanas — MVP en 11

4 semanas menos que el plan SaaS. Se eliminan la complejidad multi-tenant, el SuperAdmin y el aislamiento lógico de datos. El deploy script entra como entregable del MVP.

Tech Lead (TL)
Dev 1 (D1)
Dev 2 (D2)
Deploy tooling
MES 1
MES 2
MES 3
MES 4
MES 5
MES 6
MES 7
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
MVP FUNCIONAL · semanas 1–11 · todos los devs desde S1
Monorepo + Docker Compose + CI/CDTL — infra base
S1–S3 · TL
auth + company (single-tenant) + config UITL full stack — simple, sin multi-tenant
S2–S5 · TL
🔑 sri-service: XML + firma + WS SRITL — dueño del conocimiento
S4–S11 · TL · sri-service
document-service + CRUD + estadosD1 — desde S1
S1–S6 · D1
notification-service + RIDE PDF + UI emisiónD1 full stack
S5–S11 · D1
Design system + catalog base + UI adminD2 — desde S1
S1–S11 · D2
🚀 Deploy script v1TL — primer entregable operacional
S8–S11 · TL · deploy
Testing piloto · QA entra S9QA + 3 devs
S9–S11
ITERACIONES POST-MVP · semanas 12–28
Iter 1 · Comprobantes completosTL amplía sri-service
S12–S18 · TL
Iter 2 · Catalog avanzado + AdminD2 full stack
S12–S18 · D2
Iter 3 · API pública + webhooksD1 full stack
S12–S20 · D1
🚀 Deploy script v2 + update pipelineTL — automatización multi-cliente
S15–S20 · TL · ops
Iter 4 · Conector ERP + Conta/MónicaD2 + D1 full stack
S19–S24 · D1+D2
Iter 5 · Reportes ATS + portal clienteD2 full stack
S22–S27 · D2
Hardening + docs + go-live3 devs + QA
S26–S28
Sprints · Scrumentregable c/2 sem.
S1
S2
S3
S4
S5
S6
S7
S8
S9
S10
S11
S12
S13
S14
Firma XAdES
⭐ 1ª Factura SRI
🏁 MVP + Deploy v1
Comprobantes ✓
ERP + Deploy v2
🚀 Go-live
Operaciones

Flujo de onboarding — nuevo cliente

El deploy script es el mecanismo que convierte el código en una instancia viva en minutos. Es tan crítico como el código de la aplicación.

PREVIO Servidor VPS o cloud PASO 1 deploy.sh <cliente> <ruc> <dominio> AUTO .env generado RUC · dominio · secrets AUTO Docker Compose app · pg · redis AUTO Nginx + SSL dominio · Let's Encrypt Online ~15 minutos Actualización: update.sh <cliente> → git pull → docker compose up --build → migraciones → ✓

deploy.sh <cliente>

Parámetros: nombre del cliente, RUC, dominio, credenciales iniciales. El script clona el repo, genera el .env, levanta los contenedores, configura Nginx y corre las migraciones. Resultado: instancia viva en ~15 minutos.

update.sh <cliente>

Corre en el servidor del cliente. Hace git pull de la última versión etiquetada, rebuilds los contenedores y corre las migraciones nuevas. Si falla, hace rollback al tag anterior. Sin downtime si se usa blue/green.

update-all.sh

Itera sobre todos los clientes registrados y corre el update en cada uno de forma secuencial o en paralelo. Se construye en iter 2 cuando ya hay más de 2 clientes activos. Reduce el overhead de actualización masiva.

Alcance del producto

MVP + iteraciones — instancia dedicada

El MVP es idéntico al plan SaaS en funcionalidad, pero más simple en código. Lo que desaparece: multi-tenancy, SuperAdmin, tenant context en JWT, y tenant_id en las tablas.

MVP · Semanas 1–11
Emite facturas válidas en el SRI · un servidor · una empresa
GATEWAY
api-gateway
ACCESO
auth-service
CONFIG
company (1 empresa)
NÚCLEO SRI
sri-service
DOCS
document-service
SALIDA
notification
+ UI: login · emisión facturas · historial · RIDE preview · re-envío email
+ deploy.sh + update.sh
Solo facturas en MVP
Iteraciones post-MVP
ITER 1 · S12–S18
Comprobantes completos
Notas C/D · retenciones · guías de remisión · liquidaciones de compra
ITER 2 · S12–S18
Catálogo + Admin + Ops
catalog-service · admin avanzado · update-all.sh · health dashboard básico
ITER 3 · S12–S20
API pública
integration-service · REST documentado · webhooks · auth por API key
ITER 4–5 · S19–S28
Conectores + Reportes
ERP · Conta/Mónica · ATS XML · portal cliente final
Entregable operacional

El deploy script es un entregable de primera clase

En este modelo, el script de despliegue no es un detalle de infraestructura — es lo que hace escalable el negocio. Sin él, cada cliente nuevo es trabajo manual que crece con el tiempo.

deploy.sh — onboarding nuevo cliente
$./deploy.sh empresa-abc 1712345678001 factura.empresa-abc.com
# 1. Clonar repositorio
git clone repo → /srv/empresa-abc
# 2. Generar .env con los parámetros
COMPANY_RUC=1712345678001
APP_DOMAIN=factura.empresa-abc.com
DB_NAME=factura_empresa_abc
# 3. Levantar contenedores
docker compose up -d --build
# 4. Correr migraciones
docker exec app npm run migration:run
# 5. Nginx + SSL automático
certbot --nginx -d factura.empresa-abc.com
✓ Instancia activa — ~15 minutos
update.sh — actualizar cliente
$./update.sh empresa-abc v2.3.0
git fetch && git checkout v2.3.0
docker compose up -d --build
docker exec app npm run migration:run
✓ Actualizado sin downtime
update-all.sh — actualizar todos (iter 2+)
$./update-all.sh v2.3.0
# itera sobre /srv/clientes/*
for cliente in $(ls /srv/clientes); do
  ./update.sh $cliente $VERSION
done
✓ N clientes actualizados desde 1 comando
Gestión de riesgos

Riesgos específicos del modelo por instancia

Los riesgos de código se reducen. Los riesgos operacionales aumentan — se mitigan con automatización.

Riesgo Nivel Impacto Mitigación
Fragmentación de versiones
clientes en versiones distintas
ALTA Con el tiempo, soportar v1, v2, v3 en paralelo es inmanejable Política de versiones: máximo 2 versiones activas. Update-all.sh en cada release. Ventana de actualización de 30 días antes de deprecar versión anterior.
Parche de seguridad urgente
vulnerabilidad en producción
ALTA Si 20 clientes tienen la vulnerabilidad, hay que correr update.sh 20 veces update-all.sh resuelve esto. Para emergencias: pipeline de CI que corre el update en todos los servidores automáticamente al hacer push a una rama hotfix.
Customización que diverge
un cliente con código modificado
MEDIA Al actualizar esa instancia hay conflictos de merge Política estricta: las customizaciones van en archivos de configuración o en hooks definidos, nunca en el código core. Si requiere código, va en una rama mantenida.
Sin visibilidad central
no saber qué clientes están caídos
MEDIA Soporte reactivo — el cliente te avisa que está caído Health check endpoint en cada instancia. Dashboard central mínimo (iter 2) que hace ping a todos los clientes y muestra estado. Alertas vía email o Slack.
Crecimiento del overhead operacional
muchos clientes = muchos servidores
MEDIA Con 50+ clientes, la gestión manual es inviable Este modelo es ideal hasta ~30 clientes sin automatización avanzada. Con update-all.sh y health dashboard, escala bien. Para 100+, evaluar migrar a Kubernetes o SaaS.
SRI actualiza XSD ALTA Todos los clientes generan XMLs inválidos hasta actualizar Mismo riesgo que en el plan SaaS pero más grave: hay que actualizar N instancias. Mitigación: update-all.sh + monitoreo de rechazos SRI en todos los clientes.
Certificado vencido del cliente ALTA La instancia no puede emitir hasta renovar Alertas en la propia instancia (30/15/5 días) + notificación al email del admin del cliente. El cliente gestiona su certificado de forma autónoma.