Cronograma de subida a producción + desarrollos pendientes hasta Beta 2
👇 Toca un bloque para desplegar sus tareas
Semana T+1 · 1-2 días · BLOQUEANTE para todo
📖 ¿Qué es? Sistema que permite cambiar la base de datos (añadir campos, tablas nuevas) sin perder los datos del cliente. Como un "control de versiones" para la estructura interna donde guardamos todo.
Sin Alembic, cualquier cambio de esquema en producción = pérdida de datos. Es lo primero que hay que hacer.
pip install alembic en requirements.txtalembic init alembic en backend/env.py con SQLAlchemy engine actualalembic revision --autogenerate -m "initial schema"alembic_multi.py que itera por despachobackend/requirements.txt, backend/alembic/, backend/app/main.py (quitar create_all())Semana T+2 a T+3 · 2-3 días · BLOQUEANTE
📖 ¿Qué es? Guardar los documentos del cliente en un "trastero" externo y seguro, separado del servidor donde corre la app. Si el servidor cae, los documentos siguen a salvo y se pueden recuperar en otro lado.
Hoy los documentos viven en /uploads del VPS. Si el VPS muere, se pierden. Hay que migrar a S3-compatible.
backend/app/services/storage.py con backends local (dev) y s3 (prod)boto3 o aiobotocores3://gestdok-docs/{tenant_id}/{uuid}.extbackend/app/services/storage.py (nuevo), backend/app/api/routes/documentos.py, backend/app/core/config.pySemana T+3 · 1 día · Bloqueante seguridad
📖 ¿Qué es? Sistema para que las sesiones de los usuarios caduquen automáticamente y se pueda "echar" a alguien (despido, baja) sin que mantenga su acceso. Lo actual no caduca nunca, lo que es un riesgo de seguridad.
Hoy los JWT no caducan. Si filtras un token, es permanente. Hay que separar access (15 min) y refresh (7 días) con tabla en BD.
refresh_tokens/auth/refresh que rota el refresh y devuelve nuevo access/auth/logout que invalida el refreshapiFetch que renueva al primer 401backend/app/core/auth.py, backend/app/api/routes/auth.py, backend/app/models/models.py (+RefreshToken), frontend/app.js (apiFetch)Semana T+5 · 2-3 días
📖 ¿Qué es? Mover la aplicación de tu PC a un servidor profesional que está siempre encendido. Hoy, si apagas tu PC, todos los usuarios se quedan sin servicio.
Reemplazar el túnel cloudflared (que cae si apagas tu PC) por hosting profesional.
*.gestdok.com)pg_dump | age encrypt → ambas regionesSemana T+6 · 3-5 días · Patrón PC58
📖 ¿Qué es? Permitir al auditor cargar la nómina del cliente y cruzarla automáticamente con su contabilidad. Detecta en segundos cosas como "pago al trabajador sin reflejo contable" o "cuotas SS no contabilizadas".
Cargar TC2/RNT del cliente y cruzar con cuentas 640 (sueldos), 642 (SS empresa), 4751 (IRPF a ingresar), 471 (créditos SS), 465 (remuneraciones pendientes).
NominaRegistro en models.py (análogo a LibroIvaFactura)backend/app/services/extractores/personal/nominas.py/cargar-nomina, /nomina, /generarmodels.py (+modelo), extractores/personal/nominas.py (nuevo), papeles_generados.py (+endpoints), app.js (+modal)Semana T+7 a T+8 · 3-4 días por cédula · Patrón PC58
📖 ¿Qué es? Lo mismo que el papel de IVA (PC58) pero para los otros impuestos: IRPF del trabajador (modelo 111), Seguridad Social y el Impuesto de Sociedades de la empresa. Cierra el bloque fiscal completo de la auditoría.
Completar el ciclo B08 (Administraciones Públicas) con las cédulas que faltan tras PC58 IVA:
_calcular_conciliacion_iva renombrado a genéricoSemana T+9 a T+10 · Hito Beta 1
📖 ¿Qué es? El gran momento: dar acceso a 2-3 despachos amigos para que usen Gestdok con auditorías de clientes reales. Es la primera vez que el producto sale de tu PC y empieza a recibir feedback honesto.
Hito principal del MVP. La beta arranca con uso real.
Semana T+11 · 5-7 días
📖 ¿Qué es? La memoria son las notas explicativas que acompañan a las cuentas anuales (balance + PyG). En auditoría, hay que revisar que están completas, cuadran con los EEFF y cumplen con el PGC. Aquí se añade un checklist guiado para el auditor.
Papel donde el auditor revisa que la memoria entregada por el cliente cumple PGC + concuerda con Balance/PyG.
Semana T+12 · 5-7 días
📖 ¿Qué es? Documento que firma la dirección del cliente al final del trabajo, confirmando que no oculta cosas (fraude, partes vinculadas, hechos posteriores). Es una protección legal obligatoria para el auditor según NIA-ES 580.
Documento legal firmado por la dirección del cliente al cierre del trabajo. Confirma responsabilidades sobre estados financieros, fraude, partes vinculadas, etc.
Semana T+13 a T+14 · 2-3 semanas · La pieza más compleja
📖 ¿Qué es? El documento principal de la auditoría: la opinión firmada del auditor (limpia / con salvedades / negativa / denegada). Es lo que se entrega al cliente y al Registro Mercantil. La pieza más importante y la más compleja de implementar.
El documento más importante: la opinión firmada del auditor. Reutiliza OnlyOffice que ya tienes integrado.
InformeAuditoria: tipo_opinion (limpia/calificada/denegada/adversa), fecha_emision, plantilla_base_id, contenido_html, estado_version, firma_socio_id{{cliente.nombre}}, {{materialidad.final}}, {{fecha_emision}}Semana T+15 a T+16 · Hito Beta 2
📖 ¿Qué es? Segunda beta donde los despachos amigos ya pueden cerrar auditorías completas dentro de Gestdok, incluido firmar el informe final. A partir de aquí Gestdok es producto vendible a despachos de pago.
Los despachos de Beta 1 estrenan el ciclo completo. Pueden cerrar una auditoría desde inicio hasta informe firmado sin salir de Gestdok.
Semana T+1 · 2-3 reuniones
📖 ¿Qué es? Hablar con un abogado especializado en protección de datos para que prepare los contratos legales que necesitamos para vender. Sin estos contratos firmados, no podemos firmar con ningún despacho cliente (RGPD lo prohíbe).
Conseguir asesoría especializada en TIC + RGPD + LOPDGDD. No vale un abogado generalista.
Semana T+2 a T+4 · 3 semanas de redacción
📖 ¿Qué es? Que el abogado nos redacte los 5 documentos legales obligatorios: contrato con el cliente (DPA), política de privacidad, condiciones de uso, política de cookies y aviso legal. Es el cinturón de seguridad RGPD.
Documentos legales necesarios antes del primer despacho de pago (en beta puede ser simplificado).
Semana T+4 a T+5 · Necesario antes de Beta 1
📖 ¿Qué es? Documento simplificado para los despachos amigos durante la beta. Dice claramente "esto está en pruebas, puede fallar, no garantizamos nada todavía" y limita la responsabilidad mientras iteramos.
Documento "ligero" para que los 2-3 despachos amigos puedan firmar y usar la beta sin riesgo legal.
Semana T+10 a T+11 · ~150 €/mes recurrente
📖 ¿Qué es? Contratar una consultora especializada en protección de datos como "delegado externo" (DPO). La LOPDGDD obliga a tenerlo cuando se manejan muchos datos (8+ despachos clientes). Cubre la asesoría legal continua RGPD.
Obligatorio LOPDGDD art. 34 cuando se tratan datos a gran escala (8+ despachos).
| Asesoría legal (DPA + 5 docs) | 2.500-3.500 € único |
| Hetzner Cloud + Storage V1 | ~50 €/mes |
| Dominio gestdok.com | ~12 €/año |
| Sentry + UptimeRobot | 0 € (tier free) |
| DPO externalizado (desde T+10) | 150 €/mes |
| Total 4 meses MVP | ~3.500-4.500 € |
| Bloque A Infra (T+1 → T+4) | ~4 semanas |
| Beta 1 features (T+5 → T+8) | ~4 semanas |
| 🎯 Beta 1 LIVE | ~T+10 |
| Beta 2 features (T+11 → T+14) | ~4 semanas |
| 🎯 Beta 2 LIVE | ~T+16 |
| Total para tener producto vendible | ~4 meses |