# Presupuesto — Remediación crítica plataforma Kynda

**Fecha:** 6 de agosto de 2026 · **Validez de la oferta:** 30 días
**Base:** auditoría técnica del repositorio `kynda-poc` (hallazgos verificados sobre el código)
**Unidad:** jornada de desarrollo efectiva · **Tarifa:** 450 €/jornada
**Calendario:** estimado con 1 desarrollador senior a dedicación completa

---

## 1. Qué cubre este paquete

Solo lo que hoy impide operar con datos reales de clientes. No incluye la IA de validación, ni el motor de contenido, ni el white-label: eso es evolución de producto y va en la propuesta de Fase 1.

Tres bloques, en orden de urgencia:

1. **Cerrar los agujeros de seguridad** — hoy cualquier usuario puede aprobar evidencias de cualquier marca, y un participante puede auto-aprobarse el impacto atacando la base de datos directamente.
2. **Arreglar el reporting** — los KPIs devuelven cifras falsas sin avisar por encima de mil evidencias.
3. **Construir el gobierno que falta** — roles reales y panel de superadministrador, sin el cual no se pueden cerrar del todo los puntos 1 y 2 ni dar de alta un cliente sin desplegar código.

---

## 2. Desglose por bloque

### R0 — Arranque

| Contenido | Jornadas |
|---|---|
| Acceso a repositorio y proyecto Supabase, entorno local operativo, ejecución de la suite de tests existente, línea base de estado | 1–2 |

### R1 — Cierre de agujeros de autorización

| Contenido | Jornadas |
|---|---|
| Guardián de rol y filtrado por marca en las tres acciones de validación de Ops | 1 |
| Restricción en base de datos: solo el equipo validador puede llevar una evidencia a aprobada, rechazada o bloqueada (triggers sobre `action_execution` y `evidence`) | 1–1,5 |
| Alta de usuario: derivar la marca de una invitación real en base de datos, no de metadatos que controla el propio usuario | 1,5–2 |
| Revertir el `GRANT ALL` a roles públicos, cerrar la inserción en el registro de auditoría, eliminar el respaldo a `user_metadata` en la resolución de tenant | 1–1,5 |
| Comprobación de pertenencia, inscripción y ámbito al subir evidencia | 0,5–1 |
| Propiedad de campaña en el export de KPIs; fin de la reactivación silenciosa de accesos revocados | 0,5–1 |
| Cola de Ops acotada por marca | 0,5–1 |
| Pruebas de regresión de todo el perímetro de autorización | 1,5–2 |
| **Subtotal** | **7,5–11** |

### R2 — Corrección del reporting y rendimiento base

| Contenido | Jornadas |
|---|---|
| Filtrado por marca y campaña en SQL en las consultas de KPI, con verificación de todos los puntos de llamada | 1,5–2 |
| Siete índices ausentes, empezando por los que afectan a cada petición autenticada | 0,5–1 |
| Caché de petición en las funciones de sesión y pertenencia | 0,5 |
| Test que demuestre que los KPIs son correctos por encima del umbral de mil evidencias | 1 |
| **Subtotal** | **3,5–4,5** |

### R3 — Roles reales y panel de superadministrador

| Contenido | Jornadas |
|---|---|
| Modelo de permisos servidor: matriz de roles, guardianes reutilizables, retirada del parche que hace pasar a un admin de marca por operaciones | 2–3 |
| Alta y edición de marcas desde interfaz (hoy exige editar un fichero SQL y desplegar) | 2,5–3,5 |
| Gestión de usuarios de staff: crear cuentas de operaciones reales, asignar los seis roles del modelo (hoy solo se pueden asignar dos) | 2,5–3,5 |
| Trazabilidad de cambios de permisos en el registro de auditoría | 1 |
| Pruebas de aislamiento entre marcas con los roles nuevos | 1,5–2 |
| **Subtotal** | **9,5–13** |

### R4 — Correcciones que bloquean una prueba con usuarios reales

| Contenido | Jornadas |
|---|---|
| Subida de evidencias: atomicidad de los siete pasos, comprobación de errores, validación de tamaño y tipo en servidor, límite real de Vercel | 2–2,5 |
| Aplicación de plazas por jornada en servidor; validación de los campos dinámicos antes de que entren a los KPIs | 1–1,5 |
| Idempotencia al aprobar y rechazar; unificación de las tres implementaciones divergentes | 1–1,5 |
| Herencia de configuración al crear jornadas (consulta que ordena por una columna inexistente) | 0,25 |
| Pantallas de error y de no encontrado; confirmación en acciones destructivas | 1–1,5 |
| Etiquetas de la navegación móvil y duplicación del árbol de páginas | 0,5–1 |
| **Subtotal** | **5,75–8,25** |

### R5 — Puerta de calidad y respaldo

| Contenido | Jornadas |
|---|---|
| El despliegue de migraciones exige integración continua en verde; reactivar la comprobación de tipos y añadir análisis estático | 1–1,5 |
| Activar recuperación a un punto en el tiempo, respaldo de las fotos de evidencia y primer ensayo de restauración | 1–1,5 |
| **Subtotal** | **2–3** |

---

## 3. Resumen económico

| Bloque | Jornadas | Importe (450 €/jornada) |
|---|---|---|
| R0 Arranque | 1–2 | 450 – 900 € |
| R1 Autorización | 7,5–11 | 3.375 – 4.950 € |
| R2 Reporting y rendimiento | 3,5–4,5 | 1.575 – 2.025 € |
| R3 Roles y superadmin | 9,5–13 | 4.275 – 5.850 € |
| R4 Bloqueantes de prueba con usuarios | 5,75–8,25 | 2.588 – 3.713 € |
| R5 Calidad y respaldo | 2–3 | 900 – 1.350 € |
| **Total** | **29,25–41,75** | **13.163 – 18.788 €** |

Cifra de referencia para cerrar: **35 jornadas, 15.750 €**.

### Calendario

Con un desarrollador senior a dedicación completa: **6 a 8 semanas**.
Con dos desarrolladores en paralelo (R1+R2 por un lado, R3 por otro): **4 a 5 semanas**.

---

## 4. Opción de entrega por tramos

Si el cliente necesita aprobar por partes, el orden que minimiza riesgo es este. Cada tramo deja el sistema en un estado mejor que el anterior y se puede parar entre uno y otro.

| Tramo | Bloques | Jornadas | Importe | Qué desbloquea |
|---|---|---|---|---|
| **Tramo 1 — Urgente** | R0 + R1 + R2 | 12–17,5 | 5.400 – 7.875 € | Se puede operar con datos reales sin riesgo de fuga entre marcas ni informes falsos |
| **Tramo 2 — Producto vendible** | R3 | 9,5–13 | 4.275 – 5.850 € | Kynda da de alta clientes sin desarrollador; roles de verdad |
| **Tramo 3 — Prueba con usuarios** | R4 + R5 | 7,75–11,25 | 3.488 – 5.063 € | Piloto con voluntarios reales sin fallos visibles ni pérdida de datos |

Mi recomendación es no separar el Tramo 1: los tres bloques que lo componen se tocan entre sí y partirlos genera retrabajo.

---

## 5. Criterios de aceptación

El paquete se da por entregado cuando:

- Un usuario sin rol de operaciones no puede aprobar ninguna evidencia, ni desde la aplicación ni atacando la base de datos directamente. Demostrado con test automatizado.
- Un usuario de la marca A no puede leer ni escribir ningún dato de la marca B. Demostrado con la suite de aislamiento existente, ampliada a los vectores encontrados.
- Los KPIs de una campaña coinciden con el cálculo manual sobre la base de datos con más de mil evidencias aprobadas en la plataforma.
- Kynda da de alta una marca nueva y asigna roles desde la interfaz, sin tocar código ni desplegar.
- La suite de tests pasa en verde y bloquea el despliegue si falla.
- Existe un ensayo de restauración documentado, con fecha.

---

## 6. Supuestos y exclusiones

**Supuestos**
- Acceso de lectura al repositorio y rol Developer en los proyectos Supabase de validación y producción desde el primer día.
- Una sesión inicial con quien construyó el MVP para resolver dudas de contexto.
- Las estimaciones son jornadas efectivas de desarrollo, no días naturales.
- Se trabaja sobre la arquitectura existente. El veredicto de la auditoría es refactorizar, no reconstruir.

**Excluido de este paquete**
- Capa de validación con inteligencia artificial y motor de generación de contenido. Son el diferencial de producto y van en Fase 1.
- Personalización visual por marca.
- Internacionalización a inglés (estimada aparte en 3 a 5 semanas).
- Rediseño de accesibilidad completo. Aquí solo entran las dos correcciones que rompen funcionalidad; el resto es un paquete propio.
- Asesoría jurídica y revisión de los textos legales, que hoy siguen marcados como borrador en producción.

---

## 7. Nota sobre el origen del trabajo

Conviene separar dos cosas al presentar esto. Una parte de lo que falta en la plataforma responde a un recorte de alcance que el proveedor anterior dejó por escrito en su acta de Hito 1: evidencias solo con foto, validación manual, sin IA. Eso es discutible comercialmente, pero fue transparente.

Los agujeros de autorización y el reporting incorrecto no entran en esa categoría. No son alcance reducido: son defectos en la parte que sí se entregó y se facturó, en un producto cuya propuesta de valor es precisamente la verificación fiable del impacto. Los bloques R1 y R2 de este presupuesto cubren esa segunda categoría.