Cómo una auditoría de remediación justifica un presupuesto fiable

Un presupuesto de reparación fiable nace de las pruebas, no de un recorrido por la interfaz. Un proyecto heredado puede parecer pulido mientras su restablecimiento de contraseña revela qué cuentas existen, la comprobación de administrador solo se ejecuta en el navegador y la base de datos acepta registros que el producto jamás podrá usar. Un servicio de remediación que calcula el precio a partir de capturas de pantalla o una llamada breve está poniendo precio a la incertidumbre. Al final, el comprador paga esa incertidumbre mediante ampliaciones del presupuesto, defectos que nadie detectó o ambas cosas.

La auditoría debe responder dos preguntas distintas: qué está roto y qué controla realmente el servicio como para poder repararlo. Esta distinción importa en proyectos creados con Lovable, Bolt, v0, Cursor o Replit, porque el código visible quizá sea solo una parte del sistema. La configuración de autenticación, las políticas de base de datos, las variables de entorno, las cuentas de despliegue, el DNS, el envío de correo, las reglas de almacenamiento y los paneles de terceros pueden estar en otros sitios. Un buen presupuesto dibuja todo el sistema operativo, registra las pruebas e indica qué incógnitas siguen abiertas.

El comprador debe poder relacionar cada tarea presupuestada con una comprobación fallida o una carencia de propiedad documentada. Esa trazabilidad cambia la conversación comercial. Evita que una refactorización cosmética se anteponga a unos datos expuestos y ofrece a ambas partes una definición común de trabajo terminado. Cuando el servicio no pueda mostrar la comprobación fallida, debe clasificar el trabajo como mejora preventiva o investigación, en vez de presentar una suposición como un defecto.

El presupuesto empieza por el acceso, no por las estimaciones

El servicio necesita acceso de lectura a todos los componentes capaces de cambiar el comportamiento antes de fijar un alcance cerrado. Casi nunca basta con el repositorio. La primera pasada de la auditoría debe crear un registro de activos y propiedad que relacione cada componente en ejecución con una cuenta, un propietario y un entorno de despliegue.

El registro debe incluir el repositorio de código y su historial, el proyecto de alojamiento, los dominios de producción y preproducción, la base de datos, el proveedor de autenticación, el almacenamiento de archivos, las funciones sin servidor, los trabajos en segundo plano, el servicio de correo, el proveedor de pagos, la analítica, el registro de errores y cualquier automatización que despliegue o modifique datos. Para cada activo, hay que anotar quién lo posee, quién puede administrarlo, cómo se puede transferir el acceso y si producción depende de una cuenta personal.

En este punto muchos compradores descubren que no son dueños del producto que pagaron. Puede que la agencia controle el repositorio. Un antiguo contratista quizá sea dueño del equipo de alojamiento. El fundador puede acceder a la base de datos, pero no tener códigos de recuperación. Un presupuesto no puede dar por hecho en silencio que esos vacíos se resolverán solos.

Pida al servicio un registro de acceso con el estado de cada activo. Un ejemplo útil indicaría que el repositorio pertenece a la organización compradora y confirmaría el acceso de lectura mediante la pantalla de miembros. Registraría la base de datos de producción con propietario desconocido, sin acceso para auditar y con un nombre de conexión como única prueba. Mostraría el proyecto de alojamiento en la cuenta de un contratista, con acceso de visualización y transferencia pendiente, mientras que la administración del dominio y el DNS ya pertenecería al comprador.

La falta de acceso a la base de datos en este ejemplo no es una nota administrativa menor. Impide verificar políticas, restricciones, migraciones, copias de seguridad y la forma real de los datos. El presupuesto debe marcar el trabajo relacionado como condicional o excluirlo hasta que llegue el acceso. Un servicio que da la misma cifra cerrada antes y después de ver este registro no ha puesto precio al proyecto real.

La autenticación debe probarse como un sistema

El auditor debe seguir cada recorrido de identidad desde el navegador hasta los datos que autoriza. Ver que una pantalla de inicio de sesión funciona solo demuestra que un recorrido ideal cambió unas credenciales por una sesión. No dice nada sobre la recuperación de contraseña, la verificación del correo, el vencimiento de la sesión, los cambios de función, la eliminación de cuentas ni el acceso entre organizaciones.

Empiece con una matriz de identidades y funciones. Enumere visitantes anónimos, usuarios normales, usuarios invitados, usuarios suspendidos, administradores, personal de soporte y procesos de servicio. Después, pruebe qué puede leer y cambiar cada identidad. Las comprobaciones más útiles cruzan un límite: el usuario A pide el registro del usuario B, un usuario suspendido reutiliza una sesión antigua, un usuario normal llama directamente a un endpoint de administración y un navegador sin sesión repite una solicitud antes válida.

El OWASP Application Security Verification Standard separa autenticación, gestión de sesiones y control de acceso por una buena razón. Los equipos suelen mezclar estos conceptos. La autenticación demuestra quién presentó una credencial. La autorización decide si esa identidad puede realizar esa acción sobre ese objeto. Una sesión válida aún puede enviar una solicitud no autorizada, así que una protección de rutas en el cliente o un botón oculto no protegen una API.

En una aplicación web con Supabase, revise las concesiones de la base de datos y las políticas de Row Level Security en lugar de confiar en el comportamiento de la interfaz. La documentación de Supabase indica que las tablas de esquemas expuestos necesitan RLS, y su guía de seguridad de la API explica que las concesiones deciden qué funciones pueden alcanzar un objeto mientras las políticas deciden qué filas pueden tocar. La auditoría debe enumerar tablas, vistas, funciones y contenedores de almacenamiento, y después ejecutar las políticas con al menos dos usuarios de prueba reales.

Una matriz compacta de pruebas revela más huecos que una nota que diga «la autenticación funciona». Debe intentar que el usuario A lea la fila privada del usuario B y guardar la solicitud y la respuesta denegada. Debe cambiar role en el cuerpo de una solicitud y conservar tanto el rechazo del servidor como la fila sin cambios. También debe llamar a una API con una sesión caducada, invocar una función administrativa de forma anónima y reutilizar el token de actualización de un usuario eliminado. Cada resultado necesita una marca de tiempo y el registro correspondiente del proveedor o de la aplicación.

El auditor también debe comprobar las listas permitidas de redirección, las URL de retorno de OAuth, los atributos de las cookies, el almacenamiento de tokens, los límites de frecuencia en los recorridos de recuperación y verificación, y si los mensajes de error revelan cuentas registradas. Si la autenticación vive en código generado del cliente mientras las escrituras privilegiadas usan una credencial de servicio, el presupuesto debe incluir el traslado de ese límite de confianza a un componente controlado por el servidor.

Cada secreto necesita una ubicación y una decisión de rotación

El servicio debe inventariar las credenciales en el árbol actual, todo el historial de Git, la configuración de compilación, las variables del alojamiento, los ejemplos locales, los registros y los paquetes generados. Buscar solo en los archivos actuales omite archivos .env borrados y claves enviadas al repositorio tres semanas antes. Quitar una credencial de la rama actual no vuelve a convertirla en secreta.

El inventario debe distinguir los identificadores publicables de las credenciales privilegiadas. Por ejemplo, Supabase documenta las claves publicables como aptas para componentes públicos cuando RLS protege los datos, mientras que las claves secretas y las antiguas claves service_role solo deben estar en componentes de servidor porque tienen acceso elevado y pueden saltarse RLS. Considerar una filtración cada clave visible genera ruido. Considerarlas todas inofensivas provoca incidentes.

El auditor puede empezar con búsquedas reproducibles como estas:

git log -p -G '(api[_-]?key|secret|token|password)'
git grep -nE '(BEGIN (RSA|OPENSSH) PRIVATE KEY|service_role|sk_live_)'

El primer comando debe devolver los commits y parches coincidentes. El segundo devuelve líneas del árbol actual bajo seguimiento con la forma ruta:línea:coincidencia. Estas búsquedas no demuestran que todo sea seguro, porque las credenciales pueden tener formatos desconocidos, estar en binarios o existir solo en el panel de una plataforma. Sí crean pruebas revisables y muestran si el presupuesto inicial incluye la limpieza del historial.

La documentación de protección de envíos de GitHub explica cómo bloquear secretos reconocidos antes de que entren en un repositorio. Ese control ayuda con commits futuros, pero no rota una credencial ya expuesta. Para cada hallazgo, el informe debe indicar el propietario de la credencial, sus privilegios, los entornos alcanzados, el último uso conocido, el método de rotación y si la rotación romperá otro servicio. El alcance de la reparación debe incluir la rotación y los cambios de configuración dependientes, no solo borrar la cadena.

También hay que inspeccionar los paquetes del navegador y las llamadas de red después de una compilación de producción. Una variable exclusiva del servidor puede hacerse pública por un prefijo de compilación incorrecto, la serialización en los datos de una página o un cliente de API generado. Si la auditoría no puede acceder al panel del proveedor correspondiente, debe decir «exposición sin verificar» en vez de «no hay secretos expuestos».

La lógica de negocio necesita ejemplos con dinero y estados

El auditor debe reconstruir las reglas del producto al margen del código actual. Las aplicaciones generadas suelen implementar las pantallas con fidelidad mientras reparten las reglas de negocio entre controladores de botones, activadores de base de datos, funciones sin servidor y condicionales nacidos de un prompt. Una revisión línea por línea no permite saber si esas reglas coinciden con el negocio salvo que alguien escriba primero el comportamiento esperado.

Elija los recorridos que crean un estado irreversible o con consecuencias económicas: registro e invitación, pago, cambios de suscripción, consumo de créditos, aprobaciones, reembolsos, eliminación de registros, exportaciones y excepciones administrativas. Para cada recorrido, registre sus condiciones previas, el actor autorizado, la transición de estado, los efectos secundarios, el comportamiento ante reintentos y el resultado de los fallos. Después, compare ese modelo con el código y los datos reales.

Supongamos que una compra de créditos sigue esta secuencia:

1. El navegador crea un pedido pendiente.
2. Un proveedor de pagos envía un evento de finalización firmado.
3. Una función de servidor verifica la firma y marca el evento como procesado.
4. Una única transacción de base de datos registra el pago y añade los créditos.
5. Un evento repetido devuelve éxito sin volver a añadir créditos.

Si la aplicación actual añade créditos tras una redirección del navegador, un usuario puede repetir la solicitud. Si el webhook actualiza el pedido antes que los créditos y falla la segunda escritura, el dinero y el derecho adquirido dejan de coincidir. Si los reintentos suman créditos dos veces, un reintento normal del proveedor se convierte en un error de saldo. La auditoría debe ejecutar dos veces el mismo evento, interrumpir el recorrido entre escrituras cuando sea posible y conservar las filas anteriores y posteriores.

Este ejercicio aclara una distinción que las auditorías débiles omiten: una función rota produce un comportamiento observable, mientras que una invariante rota permite un estado imposible. Arreglar el botón puede restaurar el recorrido ideal, pero dejar saldos duplicados, registros huérfanos o transiciones no autorizadas en la base de datos. El presupuesto debe incluir tanto la reparación del código como la conciliación de datos cuando los registros reales ya puedan incumplir la regla.

Los compradores deben aportar ejemplos en lenguaje sencillo, incluidas las excepciones incómodas. ¿Quién puede revertir una aprobación? ¿Puede un usuario pertenecer a dos organizaciones? ¿Qué ocurre con los registros compartidos cuando se marcha el propietario? ¿La cancelación se aplica ahora o al terminar el periodo pagado? Si nadie puede responder, el servicio debe presupuestar una decisión de descubrimiento y no disfrazar una decisión de producto como ingeniería.

La integridad de la base de datos va más allá de ejecutar consultas

El auditor debe comparar el modelo de datos previsto, el historial de migraciones y el esquema real de producción. Las aplicaciones pueden parecer funcionales mientras dependen de campos de propietario que admiten nulos, identificadores externos duplicados, texto donde debería haber un estado restringido, claves foráneas ausentes o marcas de tiempo generadas de forma incoherente por varios clientes.

Empiece por la estructura: tablas, columnas, tipos, valores predeterminados, claves primarias, claves foráneas, restricciones de unicidad, restricciones de comprobación, índices, vistas, funciones, activadores y políticas RLS. Confirme que las migraciones pueden crear el esquema actual desde una base de datos vacía. Después, compare el estado de las migraciones con producción. Los cambios manuales hechos en un panel y ausentes del control de versiones forman parte del alcance de remediación, porque el siguiente despliegue puede borrarlos o contradecirlos.

Ejecute consultas de integridad dirigidas según el modelo de negocio. Para una aplicación con varias organizaciones, un punto de partida útil sería:

select id from projects where organization_id is null;
select external_id, count(*) from payments group by external_id having count(*) > 1;
select m.id from memberships m
left join organizations o on o.id = m.organization_id
where o.id is null;
select status, count(*) from orders group by status order by status;

La salida esperada es un conjunto vacío para las tres primeras comprobaciones y un conjunto revisado de valores permitidos para la última. Los resultados no vacíos no son simples tareas de limpieza. Muestran qué invariante no aplicó el esquema y dónde el código de la aplicación aún podría crear filas incorrectas.

Revise las rutas de acceso a datos para detectar inyección y actualizaciones generales accidentales. Las bibliotecas de cliente con parámetros solo ayudan cuando los desarrolladores las usan bien. El SQL dinámico dentro de funciones, los filtros construidos mediante cadenas, los auxiliares de consultas sin procesar y las herramientas de administración también necesitan revisión. Busque además actualizaciones o eliminaciones sin condiciones de organización, funciones creadas con privilegios elevados y vistas que exponen columnas ocultas en la interfaz principal.

La existencia de una copia de seguridad no basta. La auditoría debe identificar la retención, la cuenta que controla las restauraciones, la última copia correcta y si alguien ha probado a restaurarla en un entorno independiente. Un presupuesto para cambios invasivos de esquema necesita un plan de reversión y verificación de datos. Sin él, «reparar la base de datos» significa experimentar con la única copia que importa.

Las dependencias revelan deuda de mantenimiento y riesgo de ejecución

El auditor debe demostrar que el proyecto se instala y compila desde un checkout limpio con un archivo de bloqueo guardado. Un despliegue funcional creado meses atrás no demuestra que un nuevo ingeniero pueda reproducirlo. Los proyectos generados suelen acumular bibliotecas de interfaz solapadas, envoltorios abandonados, SDK sin uso y versiones fijadas para silenciar un error de compilación.

Registre la versión del entorno de ejecución, el gestor de paquetes, el estado del archivo de bloqueo, el comando de instalación, el comando de compilación y los avisos resultantes. Ejecute la herramienta de alertas del ecosistema, pero interprete su salida. La documentación de npm dice que npm audit informa de vulnerabilidades conocidas en las dependencias configuradas. No puede encontrar un fallo de autorización en código propio, y una alerta en un paquete usado solo durante el desarrollo no tiene la misma exposición que el código ejecutable del servidor.

Una captura de pruebas útil para un proyecto JavaScript es:

node -v
npm -v
npm ci
npm run build
npm audit

El informe debe conservar los códigos de salida, el primer error sobre el que se pueda actuar, el artefacto generado y la salida de la auditoría. No acepte un presupuesto que convierta cada alerta en una tarea de actualización de paquetes. El servicio debe rastrear si se distribuye el código vulnerable, identificar la versión compatible más segura y señalar las actualizaciones que obligan a cambiar API o framework.

La revisión de arquitectura debe acompañar a la revisión de dependencias porque ambas afectan a la misma estimación. Dibuje los puntos de entrada, las funciones de servidor, el estado compartido, los clientes de datos y las reglas de negocio duplicadas. Cuente las copias generadas solo cuando el recuento cambie el trabajo. Un único componente de 900 líneas que controla rutas, carga de datos, validación y estado de ventanas puede necesitar separación antes de una reparación segura. Diez componentes ordenados no necesitan refactorización de forma automática.

La recomendación popular de «reescribirlo bien» suele ser errónea. A los equipos les gustan las reescrituras porque la estimación parece sencilla y nadie tiene que entender código incómodo. Una reescritura también descarta casos límite que funcionan, conocimiento de migraciones y comportamiento de producción del que ya dependen los usuarios. La auditoría solo debe recomendar una reconstrucción cuando la base actual impida verificar o reparar, y debe nombrar ese bloqueo.

Las pruebas deben proteger el límite reparado

La auditoría debe medir si las pruebas detectan los fallos que el presupuesto promete corregir. Una insignia, un recuento de pruebas o un comando en verde significan poco si la suite simula todos los límites y nunca comprueba autorización, persistencia o reintentos.

Primero ejecute los comandos existentes desde un checkout limpio y registre qué funciona, falla, se bloquea o exige variables de entorno sin documentar. Clasifique las pruebas por lo que cubren: funciones puras, componentes, controladores de API, políticas de base de datos y recorridos completos de usuario. Después, relacione cada hallazgo de alto riesgo con una prueba que falle antes de la reparación y funcione después.

Para la autenticación, use dos usuarios y compruebe que el acceso cruzado se deniega. Para un evento de pago, repita el mismo identificador de evento y compruebe que el saldo cambia una sola vez. Para una eliminación, compruebe tanto la cascada prevista como los registros que deben mantenerse. Para una migración, aplíquela a una copia parecida a producción y ejecute las consultas de integridad. Estas pruebas generan evidencia de un límite reparado, no solo cobertura de código.

El presupuesto debe indicar qué pruebas añadirá el servicio y dónde se ejecutan. También debe decir qué seguirá siendo manual. La entrega de correos, la configuración de cuentas de terceros, el comportamiento de navegadores móviles y los cambios de DNS quizá necesiten un guion de aceptación en vez de una prueba automatizada estable. Fingir que todo riesgo pertenece a una suite integral eleva el coste y produce pruebas frágiles.

No convierta el porcentaje de cobertura en criterio de aceptación salvo que el servicio defina qué código cuenta y por qué importa el umbral. Una suite pequeña alrededor de identidad, dinero, acciones destructivas y separación entre organizaciones puede proteger mejor una remediación que cientos de pruebas de capturas.

La propiedad del despliegue puede invalidar una reparación correcta

El auditor debe seguir cómo un commit revisado se convierte en la aplicación de producción y quién puede autorizar cada paso. El código fuente puede ser correcto mientras el sitio activo apunta a otra rama, conserva variables antiguas, ejecuta una función obsoleta o se despliega desde una cuenta inaccesible para el comprador.

Registre la rama de producción, el comando de compilación, el directorio de salida, el entorno de ejecución, los nombres de las variables de entorno, el activador de despliegue, la asignación de dominio, la gestión de TLS, el paso de migración de base de datos y el método de reversión. Compare la configuración entre los entornos local, de vista previa, de preproducción y de producción. Los valores pueden diferir, pero su finalidad y su propietario no deben ser un misterio.

Después haga una comprobación de procedencia. Elija un identificador de compilación inocuo, colóquelo en un punto de diagnóstico aprobado, despliegue mediante la ruta documentada y verifique que producción muestra el mismo identificador. Esto detecta cargas manuales, proyectos paralelos y confusión de ramas. Retire después el identificador si no tiene utilidad operativa.

La propiedad importa tanto como la configuración. El comprador debe controlar las cuentas de organización, la facturación, los métodos de recuperación, los dominios y las credenciales de producción. El servicio de remediación puede necesitar administración temporal, pero la entrega debe dejar propietarios concretos bajo control del comprador y retirar a colaboradores antiguos. Las contraseñas compartidas no son un plan de entrega.

La auditoría también necesita hablar de interrupciones y reversión. Si una migración de base de datos y una versión de la aplicación deben llegar juntas, explique cómo evita el equipo que el código antiguo lea mal el nuevo esquema. Si una reversión no puede deshacer una transformación de datos, use una reparación hacia delante y un punto de copia de seguridad. Una promesa genérica de «volver atrás si hace falta» no cubre migraciones destructivas.

FixMyMess ofrece una auditoría de código gratuita que cubre el diagnóstico antes de cualquier compromiso y puede aportar estas pruebas a compradores que no pueden inspeccionar por sí mismos un proyecto generado con IA. El entregable útil sigue siendo el hallazgo, su prueba, la reparación propuesta y el propietario necesario para completarla.

Un presupuesto defendible separa hechos de suposiciones

El presupuesto final debe relacionar precio y calendario con un registro de hallazgos basado en pruebas. Cada línea necesita un síntoma, una causa raíz o hipótesis actual, el componente afectado, la gravedad, la acción de reparación, el método de verificación, la dependencia y el estado del alcance. «Arreglar autenticación» no define un alcance. «Trasladar la asignación de funciones al servidor, restringir las actualizaciones de perfil y añadir pruebas de políticas entre usuarios» sí.

Agrupe el trabajo en tres bloques. El trabajo confirmado tiene pruebas y puede admitir un precio cerrado. El trabajo condicional tiene un desencadenante claro, como obtener acceso a la base de datos o encontrar filas reales no válidas. El trabajo excluido queda fuera del control del servicio o de la decisión actual del comprador. Esta estructura permite comparar presupuestos sin fingir que ha desaparecido toda incertidumbre.

La gravedad y la confianza de la estimación deben permanecer separadas. Un salto de autorización crítico puede ser fácil de reproducir y barato de reparar. Una incoherencia de datos de gravedad media puede exigir días de análisis porque nadie sabe cuántas filas afectó. Una etiqueta describe el impacto; la otra, cuánto entiende el servicio sobre el trabajo. Mezclarlas empuja a inflar el precio de hallazgos llamativos y a infravalorar los ambiguos.

Cada hallazgo debe llevar una referencia de evidencia que el comprador pueda revisar. Para una lectura entre organizaciones, puede ser una solicitud y respuesta censuradas, las identidades de los usuarios y la política que la permitió. Para una compilación fallida, conserve el commit del checkout limpio, la versión del entorno, el comando, el código de salida y el primer error relevante. Las capturas ayudan con la configuración de paneles, pero las exportaciones en texto se comparan mejor después de reparar. Oculte datos personales y valores de credenciales sin eliminar el contexto necesario para repetir el resultado.

Las estimaciones también necesitan unidades que encajen con el trabajo. Presupueste una migración definida junto con su verificación como un elemento. Presupueste una limpieza repetida según un intervalo declarado de registros o una bolsa de tiempo con un punto de aprobación. No esconda la coordinación, la transferencia de cuentas, las copias de datos y la vigilancia de la publicación bajo la gestión del proyecto. Esas tareas consumen tiempo real y a veces exigen la intervención del comprador o de un proveedor anterior.

El calendario debe mostrar puertas de control, no solo fechas de inicio y entrega. Una secuencia práctica puede exigir acceso a cuentas antes de verificar políticas, aprobación del comprador sobre reglas de negocio discutidas antes de reparar la lógica, una copia de seguridad antes de migrar y pruebas de aceptación antes de publicar. Si una puerta depende de un tercero, nombre esa dependencia y explique qué trabajo puede continuar mientras esté bloqueada.

El lenguaje de aceptación debe describir resultados observables. Por ejemplo, «un usuario normal recibe una respuesta denegada al pedir la factura de otra organización» se puede probar. «La autorización es segura» no. «La aplicación se instala desde un checkout limpio y la compilación de producción termina correctamente con el entorno registrado» es mejor que «el código es estable». La misma norma vale para reparar datos: indique la consulta de integridad y el resultado vacío esperado.

Los compradores deben preguntar cómo gestiona el servicio un hallazgo que cambia después de empezar. Un proceso razonable muestra las pruebas nuevas, explica por qué la auditoría inicial no podía descubrirlas, indica el efecto sobre el precio y el calendario y espera la aprobación, salvo que una acción inmediata evite daños. Esto protege a ambas partes. También deja en evidencia auditorías débiles, porque los hallazgos normales que debieron aparecer durante la inspección no pueden rebautizarse como sorpresas.

Por último, el presupuesto debe decir qué recibe el comprador en la entrega. Como mínimo, espere el código reparado, las migraciones, un inventario de configuración sin valores secretos, las pruebas añadidas, el registro de hallazgos con su estado de resolución, las instrucciones de despliegue, el registro de propiedad y los riesgos residuales conocidos. La retirada de accesos debe figurar como tarea. Una aplicación reparada sin registro operativo se convierte en el siguiente misterio heredado.

Pida estos anexos al presupuesto:

• El registro de activos y propiedad, con los huecos de acceso.
• El registro de hallazgos, con pruebas y límites de reparación.
• El plan de pruebas y aceptación para cada cambio de alto riesgo.
• El plan de despliegue, migración, reversión y entrega.
• Las suposiciones, exclusiones y tarifas o reglas de aprobación para el trabajo condicional.

El servicio también debe señalar las decisiones que corresponden al comprador. Los ingenieros pueden mostrar que dos comportamientos de cancelación entran en conflicto, pero no pueden elegir la política comercial sin autoridad. Coloque esa decisión en el calendario con un responsable y una fecha límite para que no se convierta en un retraso invisible.

Rechace las estimaciones basadas en adjetivos. «Limpieza menor», «listo para producción» y «refuerzo de seguridad estándar» no se pueden aceptar ni probar. Un buen presupuesto permite que otro profesional competente revise las mismas pruebas y entienda por qué existe el trabajo. Si sigue faltando acceso, la cifra honesta corresponde a una fase de investigación acotada seguida de un alcance revisado. La precisión inventada antes de inspeccionar es teatro comercial, y las aplicaciones heredadas ya contienen bastante ficción.