Informe de ejemplo · nivel Despegue
Así se ve lo que recibes por US$10.
Este es un informe Despegue completo. El proyecto es inventado, pero los hallazgos son los que encontramos con más frecuencia en aplicaciones construidas con asistentes de IA.
El proyecto evaluado
Una aplicación de reservas construida con un asistente de IA en unas tres semanas. Permite ver horarios disponibles, reservar un cupo, pagar una seña y administrar los cupos desde un panel interno. Funciona: el dueño ya la usó con clientes reales. La pregunta que trajo al proyecto fue si estaba en condiciones de publicarse y cobrar con ella.
Resumen en una frase
El producto está bien encaminado y resuelve el problema, pero hoy expone datos personales de quienes reservan y permite que cualquiera modifique la agenda. No lo publiques hasta cerrar los tres primeros puntos de la ruta; son de un día de trabajo.
Hallazgos por área
Cada hallazgo indica qué encontramos, por qué importa en términos concretos y qué hacer.
Protección
La llave maestra de la base de datos viaja al navegador
- Qué encontramos
- La clave service_role de Supabase está incluida en el código que se descarga en el navegador de cada visitante.
- Por qué importa
- Esa clave ignora todas las reglas de acceso. Cualquiera que abra las herramientas de desarrollo puede leer, modificar o borrar la base completa, incluidos los datos de tus clientes. No requiere conocimientos avanzados: es visible en texto plano.
- Qué hacer
- Mover toda operación que la use al servidor y rotar la clave, porque debe considerarse comprometida. En el navegador solo debe quedar la clave pública (anon).
La tabla de reservas es de lectura pública
- Qué encontramos
- Row Level Security está desactivado en las tablas reservas y clientes.
- Por qué importa
- Nombre, teléfono y correo de cada persona que reservó se pueden descargar sin autenticación. Además de ser un problema para tus clientes, es exactamente el tipo de exposición que obliga a notificar un incidente.
- Qué hacer
- Activar RLS y escribir políticas explícitas: cada persona ve solo sus reservas; el panel accede mediante un rol verificado en el servidor.
El panel de administración solo está oculto, no protegido
- Qué encontramos
- La ruta /admin verifica el rol en el componente de React, pero el servidor responde con los datos sin comprobar quién pregunta.
- Por qué importa
- Ocultar un botón no impide llamar a la ruta directamente. Escribir la URL en el navegador entrega el panel completo.
- Qué hacer
- Verificar la sesión en el servidor antes de responder, no en el cliente. El control en el frontend es para la experiencia, nunca para la seguridad.
Cómo está hecho
El precio de la seña está escrito en seis archivos
- Qué encontramos
- El monto y el porcentaje de la seña aparecen repetidos en seis componentes distintos.
- Por qué importa
- Cuando subas el precio vas a cambiarlo en cinco lugares y olvidar uno. Ese tipo de olvido produce cobros inconsistentes que se detectan tarde y por reclamo del cliente.
- Qué hacer
- Definir el precio en un solo módulo de configuración e importarlo. Es un cambio de una hora que evita una clase entera de errores.
El esquema de la base solo existe en el panel de Supabase
- Qué encontramos
- No hay migraciones versionadas: las tablas se crearon a mano desde la interfaz.
- Por qué importa
- No hay forma de recrear la base si se pierde, ni de saber qué cambió y cuándo. Tampoco puedes probar un cambio antes de aplicarlo en producción.
- Qué hacer
- Exportar el esquema actual como primera migración y aplicar los cambios siguientes por ahí. Habilita además tener un ambiente de prueba real.
Lanzamiento
No hay respaldos configurados
- Qué encontramos
- El proyecto usa el plan gratuito de Supabase, que no incluye respaldos automáticos.
- Por qué importa
- Un borrado accidental desde el panel elimina la agenda completa sin vuelta atrás. Es el incidente más común y el más evitable.
- Qué hacer
- Subir al plan con respaldos diarios o programar un volcado automático a almacenamiento externo. Probar la restauración una vez: un respaldo no verificado no es un respaldo.
Las fotos del taller se sirven sin optimizar
- Qué encontramos
- Las imágenes de la galería se cargan en su resolución original, de entre 4 y 6 MB cada una.
- Por qué importa
- La página tarda en abrir en datos móviles, que es como te va a llegar la mayoría, y el consumo de ancho de banda puede generar cobros inesperados al crecer la visita.
- Qué hacer
- Usar el componente de imagen del framework, que redimensiona y sirve formatos modernos automáticamente.
La idea
Pides siete datos antes de mostrar si hay cupo
- Qué encontramos
- El formulario solicita nombre, correo, teléfono, RUT, experiencia previa, cómo conoció el taller y comentarios; recién después muestra la disponibilidad.
- Por qué importa
- La persona invierte esfuerzo sin saber todavía si existe un horario que le sirva. Es el punto donde más gente abandona en este tipo de flujo.
- Qué hacer
- Mostrar primero el calendario con los cupos y pedir solo nombre y contacto para reservar. El resto puede preguntarse después de confirmar, cuando la persona ya está comprometida.
Ruta de mejoras priorizada
Ordenada por riesgo, no por dificultad. Los tres primeros puntos son bloqueantes para publicar.
| Prioridad | Acción | Esfuerzo |
|---|---|---|
| 1 | Sacar la clave service_role del navegador y rotarla | 2 horas |
| 2 | Activar RLS y escribir las políticas de acceso | 3 horas |
| 3 | Verificar la sesión del panel en el servidor | 1 hora |
| 4 | Configurar respaldos y probar una restauración | 1 hora |
| 5 | Centralizar el precio de la seña en un módulo | 1 hora |
| 6 | Exportar el esquema como primera migración | 2 horas |
| 7 | Optimizar las imágenes de la galería | 1 hora |
| 8 | Reordenar el formulario para mostrar cupos primero | 3 horas |
Guía de lanzamiento
El informe incluye instrucciones paso a paso para el proyecto concreto. Este es el índice de esa sección.
- Separar las credenciales de desarrollo y producción, y qué va en cada ambiente.
- Conectar el dominio propio y forzar HTTPS.
- Qué revisar antes de cada publicación y cómo volver atrás si algo sale mal.
- Cómo saber que la aplicación está caída antes de que te escriba un cliente.
- Qué costos aparecen al crecer y en qué punto conviene revisar el plan contratado.
Qué no incluye este nivel
Despegue evalúa y explica; no implementa los cambios. Si después de leerlo quieres conversar las decisiones con un ingeniero, eso es Trayectoria. Si prefieres que Socius lo implemente, eso es Misión y parte desde esta misma evaluación.
Tu proyecto merece esta misma revisión.
Sube el ZIP, recibe tu número de seguimiento y el informe llega a tu correo.
Analizar mi proyecto ↗US$10 · sin suscripción