01
Llaves expuestas
Una llave de pago o de base de datos a la vista de cualquiera que abra la página, o guardada en el historial del código.
Bundle del frontend, historial de git, variables públicas, service_role de Supabase en el cliente.
Lovable · Bolt · v0 · Replit · Cursor · Claude Code · actualizado: oct 2026
Antes de lanzar o de cobrar, reviso tu app y te digo qué puede filtrar datos, regalar tu producto o tirarte la operación, con prueba reproducible.
$7,900 + IVA · precio fijo · 3 días hábiles
Ningún hallazgo sin prueba. Lo que no se pudo probar se reporta aparte como «no comprobado».
Vas a abrir la app a usuarios reales o a empezar a cobrar, y hasta ahora solo la has usado tú.
La armaste con Lovable, Bolt, v0, Replit, Cursor o Claude Code y nadie más ha leído el código.
Guarda datos de tus clientes: nombres, correos, pedidos, documentos.
Un inversionista, un cliente grande o un banco te pidió una revisión antes de firmar.
El asistente "arregla" una cosa y a veces rompe otra, y ya no estás seguro de qué cambió.
Siete revisiones, cada una con una prueba que se puede repetir. Abajo de cada una va lo que se mira por dentro.
01
Una llave de pago o de base de datos a la vista de cualquiera que abra la página, o guardada en el historial del código.
Bundle del frontend, historial de git, variables públicas, service_role de Supabase en el cliente.
02
Un botón oculto no protege nada si el servidor contesta igual a quien lo llama a mano.
Endpoints, funciones serverless y RPC llamados sin sesión y con la sesión de un usuario sin permiso.
03
Cambiar un número en la dirección o hacer una consulta directa basta para leer lo de otra cuenta.
RLS de Supabase apagado o con true, reglas abiertas de Firebase, IDs predecibles en la URL.
04
Algo se rompe y te enteras cuando un cliente te escribe enojado, no antes.
Registro de errores, logs del backend y alerta que llegue a una persona; se provoca un error controlado.
05
Si nadie ha restaurado nunca el respaldo, no sabes si sirve hasta el día que lo necesitas.
Respaldo de base y archivos, frecuencia y restauración a una base aparte contando filas contra producción.
06
Alguien cambia el precio antes de pagar, o el acceso se activa sin que el pago se confirme, o se cobra dos veces.
Precio o plan enviados desde el cliente, webhooks sin verificar la firma, eventos repetidos.
07
Al pedirle que arregle otra cosa, el asistente a veces quita una validación o una prueba sin avisar.
Historial de git de auth, pagos y permisos buscando validaciones quitadas, y las pruebas que haya.
Severidad, prueba reproducible, impacto en lenguaje de negocio y el arreglo concreto: qué archivo y qué cambio.
Para quien decide: ¿se puede lanzar? ¿se puede cobrar? Sin leer una línea de código.
Te explico cada hallazgo, en qué orden atenderlos y cuáles pueden esperar.
Si hay hallazgos críticos, el precio y el plazo de corregirlos, por escrito.
Te lo quedas aunque no contrates nada más.
01
$7,900
precio fijo · 3 días hábiles
Las siete revisiones y las tres rápidas sobre una app: un frontend y su backend, hasta unas 30 mil líneas propias.
02
desde $14,900
precio cerrado tras la auditoría
Se corrigen los hallazgos críticos y altos, con prueba de que ya no se reproducen.
03
desde $4,900
al mes
Parches, respaldos que se prueban y monitoreo, para que la app siga igual de revisada después de lanzar.
Precios en MXN, más IVA. Los servicios de terceros (Supabase, Stripe, hosting) los paga tu empresa directo; yo no cobro nada encima.
Día 0
Llamada corta
Me cuentas qué hace la app, con qué herramienta se hizo y dónde vive. Si no te puedo ayudar, te lo digo ahí mismo.
Día 1
Autorización por escrito
Una página con qué app, qué ambientes, qué cuentas de prueba me das y en qué fechas. Sin ese papel no se toca nada.
Días 1 a 3
Revisión
Trabajo en staging o con cuentas de prueba. Nunca pruebo contra usuarios reales sin tu permiso.
Día 3
Entrega y llamada
Informe, semáforo y una llamada de 45 minutos. Si hay críticos, la cotización cerrada del arreglo.
Si la auditoría no encuentra ningún hallazgo de severidad media o mayor, se te devuelve la mitad. Queda por escrito antes de empezar.
Cada fila del informe trae la forma de repetirlo. Lo que no pude probar va aparte como «no comprobado», nunca como «bien».
Se trata como confidencial, con acuerdo de confidencialidad si lo pides, y las pruebas se hacen solo con tu autorización por escrito.
Esta auditoría es para código nuevo y chico, escrito por un asistente. Si lo que tienes es un sistema heredado con años de lógica de negocio, mira el rescate de sistemas PHP y Laravel. Y si la auditoría encuentra problemas que no se arreglan con parches, la estabilización es la de esa página.
Depende de lo que hizo el asistente en cada proyecto, y esa es la razón de revisarlo. Lovable y Supabase dan buenas bases, pero la seguridad de los datos vive en configuraciones que el asistente puede dejar a medias: las políticas de acceso por fila (RLS), las llaves que quedan en el frontend o las funciones que no comprueban quién las llama. Una app puede verse y funcionar perfecto con esas puertas abiertas. La forma de saberlo es probarlo con dos cuentas distintas, que es lo que hace la auditoría.
RLS (Row Level Security) es la regla de Supabase y de Postgres que decide qué filas de una tabla puede leer o cambiar cada usuario. Si está apagado, o tiene una política que dice true, cualquier usuario con sesión, y a veces cualquier visitante, puede pedir los registros de todos los demás con una sola consulta. Es el equivalente a que cada cliente pueda abrir el cajón de los demás. Se prueba con dos cuentas: la A pide los datos de la B y se ve qué contesta el servidor.
No necesariamente. Prefiero trabajar en un ambiente de staging o con cuentas de prueba que tú me das, y producción solo si lo autorizas por escrito. Para leer el código me basta acceso de solo lectura al repositorio. Las pruebas que podrían afectar datos reales, como reenviar un webhook o repetir un pago, se hacen en el ambiente de pruebas de tu pasarela.
Queda en el informe con su prueba, su impacto y el arreglo concreto, marcado como crítico, y en la llamada decidimos el orden en que se atiende. Si hay críticos, te doy una cotización cerrada para corregirlos; puedes contratarme, dárselo a tu equipo o a quien tú quieras. El informe es tuyo.
Sí. El código y los datos de tu app se tratan como confidenciales y firmo un acuerdo de confidencialidad si lo pides. Las pruebas se hacen únicamente con tu autorización por escrito, que define qué se revisa, en qué ambientes y en qué fechas.
Se puede revisar igual. Las siete revisiones aplican a cualquier app que haya escrito un asistente de IA, o una persona con prisa: Cursor, Claude Code, Windsurf, Copilot o el código que te pasó alguien más. Lo que cambia es el entorno: Supabase, Firebase, un backend propio en Node, Python o PHP. Si el tamaño pasa de unas 30 mil líneas propias o son varias apps, se cotiza aparte.
La auditoría cuesta $7,900 + IVA a precio fijo y se entrega en 3 días hábiles desde que tengo la autorización y las cuentas de prueba. Cubre una app: un frontend y su backend, hasta unas 30 mil líneas propias. Si no aparece ningún hallazgo de severidad media o mayor, te devuelvo la mitad. El arreglo de los críticos empieza en $14,900 a precio cerrado y el mantenimiento en $4,900 al mes, también más IVA.
No como parte de la auditoría: te entrego el informe y no cambio tu código. Si hay críticos, el arreglo se cotiza aparte y se corrige lo que apareció, con prueba de que ya no se reproduce, sin rehacer lo que funciona. Si la app tiene problemas de fondo que no se arreglan con parches, te lo digo en el informe y la ruta es la del rescate de sistemas.
Con dos líneas (la herramienta, dónde vive el código y qué te preocupa) te digo si conviene la auditoría y cuándo podría entregarte el informe.
Completa el formulario y respondo en menos de 1 hora en horario laboral y en 24 h fuera de él. También puedes escribirme directo: