Remediación a precio fijo vs por hora: cómo elegir un modelo más seguro

Por qué la fijación de precios se complica cuando el código está desordenado

La remediación es una idea simple: tomar software que más o menos funciona y hacerlo fiable. Eso significa arreglar los bugs visibles, además de los problemas que sólo aparecen con usuarios reales, datos reales y necesidades reales de seguridad.

La fijación de precios se complica porque el código desordenado oculta trabajo. Puedes abrir la app y ver un problema obvio, como que falle el inicio de sesión. Pero el sumidero de tiempo suele ser la reacción en cadena detrás: manejo de sesiones roto, restricciones de base de datos faltantes, atajos inseguros o una configuración de despliegue que nunca se terminó.

Los prototipos generados por IA son especialmente buenos aparentando estar completos mientras siguen siendo frágiles. A menudo ensamblan librerías rápido, repiten patrones en varios archivos y dejan marcadores que parecen inofensivos hasta que vas a producción. Un prototipo puede pasar una demo y aun así salir con secretos expuestos, validación inconsistente o lógica que falla cuando dos personas usan la app al mismo tiempo.

Para un propietario no técnico, “desordenado” suele sentirse así: arreglar un bug crea dos más, las funciones se comportan distinto según la página o el dispositivo, y los pequeños cambios tardan una eternidad porque nadie está seguro de qué se romperá. La app puede funcionar localmente pero fallar en producción, y escuchas términos como “espagueti”, “hard-coded” o “sin tests”.

Por eso elegir entre precio fijo y por hora puede ser difícil al principio. Ambos modelos intentan responder la misma pregunta: ¿cómo pagas de forma justa cuando la lista completa de problemas todavía no es visible?

Los desconocidos son normales. No significan que tu proyecto esté condenado. Puedes gestionarlos si tratas el descubrimiento como parte del trabajo. Un bug “simple” en el checkout podría ser en realidad un problema de esquema de base de datos más falta de validación en servidor. Hasta que alguien lea el código y trace los flujos de usuario reales, nadie puede prometer responsablemente el esfuerzo exacto.

Una forma práctica de reducir la incertidumbre es empezar con un diagnóstico corto del código y luego decidir cómo fijar el precio del trabajo de reparación según lo encontrado.

Precio fijo vs por hora: la definición simple

Cuando la gente dice “precio fijo” (o reparación de software con oferta fija), se refieren a acordar tres cosas desde el inicio: qué se va a arreglar, cómo se verá “terminado” y cuánto costará. El trabajo se trata como un paquete con entregables claros.

Arreglar por hora es más simple de otra manera: pagas por el tiempo empleado. El alcance puede cambiar a medida que el equipo aprende más sobre el código. Si aparece un nuevo problema, no renegocias todo el proyecto cada vez. Decides si seguir según el progreso y el presupuesto.

La verdadera compensación es coste predecible frente a flexibilidad.

El precio fijo suele funcionar mejor cuando quieres certeza del coste y una línea de llegada clara. El por hora suele funcionar mejor cuando esperas sorpresas y quieres margen para pivotar.

Un ejemplo rápido: imagina un prototipo construido por IA donde el inicio de sesión funciona en un enlace de demo, pero falla en producción porque hay secretos expuestos y el flujo de auth es inconsistente. Si ya sabes las correcciones exactas necesarias, el precio fijo puede funcionar bien. Si sospechas que hay más problemas escondidos detrás del primer error, por hora a menudo reduce el conflicto porque el descubrimiento es parte del plan.

Cuáles son los desconocidos habituales (y por qué aparecen tarde)

El código desordenado oculta problemas como una casa oculta daños por agua. Todo parece bien hasta que abres una pared, abres la ducha y descubres que la fuga está detrás de las baldosas. La remediación de software es similar: los mayores riesgos suelen estar detrás de la primera función que falla en un entorno real.

Los desconocidos que aparecen más a menudo son previsibles, aunque los detalles exactos no lo sean:

• Autenticación que funciona localmente pero falla con sesiones reales, cookies o redirecciones
• Secretos expuestos (claves de API, contraseñas de base de datos) integrados en el código o logs
• Flujo de datos poco claro (nadie sabe de dónde viene un valor o por qué cambia)
• Dependencias ocultas, como un servicio de terceros, una migración faltante o una variable de entorno supuesta
• Brechas de seguridad que no aparecen en pruebas de camino feliz (consultas inseguras, controles de acceso débiles)

Estos problemas aparecen tarde porque las pruebas tempranas suelen ser superficiales. Un click-through rápido se pierde las partes que sólo aparecen bajo carga, con usuarios reales o con datos reales. Si la app fue generada rápidamente por una herramienta de IA o parcheada por varias personas, el código puede parecer legible y aun así estar lógicamente equivocado.

El trabajo de descubrimiento cambia las estimaciones porque convierte conjeturas en hechos. Hasta que alguien trace flujos clave de extremo a extremo (login, pagos, acciones de admin, escrituras de datos), no sabes si estás arreglando un bug pequeño o tirando de un hilo que deshace todo el suéter.

Los requisitos poco claros empeoran esto. Si nadie puede decir qué significa “correcto”, los ingenieros acaban persiguiendo síntomas. En la práctica, el mayor desconocido suele ser a menudo no el código, sino la definición de “hecho”, especialmente en casos límite.

Cómo el precio fijo maneja los desconocidos

Un precio fijo puede parecer más seguro porque conoces el número por adelantado. Pero sólo funciona cuando “terminado” está claro. La verdadera pregunta no es la tarifa, sino cómo el plan trata las sorpresas que se esconden en código desordenado.

Con precio fijo, la incertidumbre se maneja ajustando el alcance. Eso normalmente significa especificar exactamente qué se reparará, qué entornos están incluidos y qué cuenta como éxito. Si la app “más o menos funciona”, metas vagas como “hacerla estable” son donde las ofertas fijas fallan.

Un acuerdo sano a precio fijo protege a ambas partes con algunas salvaguardas:

• Criterios de aceptación por escrito (qué probarás y qué debe pasar)
• Supuestos (por ejemplo: se puede acceder al hosting, las APIs clave siguen existiendo)
• Exclusiones claras (qué no está incluido, como rediseñar la UI o añadir nuevas funciones)
• Un camino de solicitudes de cambio (cómo las sorpresas se convierten en trabajo nuevo, con precio y plazo)
• Una opción por fases (diagnosticar primero y luego arreglar)

Cuando aparecen sorpresas, un buen equipo de precio fijo no hace el trabajo ilimitado ni sacrifica calidad en silencio. Ponen la sorpresa en evidencia. Luego eliges: renegociar alcance y precio, o añadir una fase separada.

Para evitar un mal precio fijo, insiste en un diagnóstico antes de comprometerte con la reparación completa. Una auditoría corta puede revelar dependencias ocultas, migraciones rotas, variables de entorno faltantes y arquitectura en espagueti.

El precio fijo suele funcionar mejor cuando los resultados son concretos: puedes listar los fallos principales que deben arreglarse, tienes acceso a logs y cuentas de terceros, y puedes acordar una lista de comprobación simple que demuestre que la app funciona.

Si un proveedor no puede describir cómo maneja las solicitudes de cambio, el precio “fijo” no es realmente más seguro. Sólo oculta el riesgo hasta después.

Cómo el trabajo por hora maneja los desconocidos

El trabajo por hora suele ser el ajuste más honesto cuando el código está desordenado y nadie puede ver el problema completo aún. Pagas por la investigación y las correcciones a medida que ocurren, en lugar de fingir que el alcance se conoce el primer día.

La ventaja es la flexibilidad. Si el equipo descubre que el problema real no es el botón de login sino un esquema de base de datos malo, pueden pivotar sin renegociar un contrato cada vez que la verdad cambia.

La desventaja es la deriva de costes. Por hora puede convertirse en depuración abierta, y los “arreglos rápidos” pueden generar retrabajo después. El presupuesto se va cuando los equipos persiguen síntomas en lugar de causas raíz, intentan reescrituras parciales que siguen creciendo o siguen descubriendo que múltiples áreas dependen del mismo patrón roto.

Para hacer que por hora sea seguro, necesitas límites y puntos de parada frecuentes:

• Acotar el tiempo de descubrimiento (por ejemplo, 4–8 horas) y exigir hallazgos por escrito
• Fijar un tope semanal y requerir aprobación antes de sobrepasarlo
• Definir “hecho” como hitos visibles (auth funciona de extremo a extremo, despliegue pasa)
• Añadir reglas de pausa (detener si se necesita una reescritura o si aparecen dependencias ocultas)
• Exigir notas de progreso en lenguaje claro, no sólo una hoja de horas

Por hora es más seguro cuando se trata como investigación controlada más fases de arreglo, no como un contador sin fin.

Una forma paso a paso de elegir el modelo

Elegir entre precio fijo y por hora es más fácil si lo tratas como una decisión en dos fases: primero aprende con qué estás lidiando y luego elige el contrato que coincida con el riesgo.

1. Definir el resultado en términos de usuario. Escribe qué significa “funcionar” como acciones reales, no tareas técnicas. Ejemplo: “Un nuevo usuario puede registrarse, confirmar el correo, iniciar sesión y restablecer la contraseña sin atascarse.”
2. Solicita una fase corta de diagnóstico. Antes de que alguien cotice una gran reparación, pide una auditoría acotada en el tiempo que mapee los problemas y las causas probables.
3. Acordar comprobaciones de aceptación. Decide qué prueba usarás para confirmar que la reparación es real. Manténlo observable y repetible.
4. Elige el modelo de la Fase 2 según el diagnóstico. Si el trabajo está claramente definido y es comprobable, el precio fijo puede ser seguro. Si el diagnóstico muestra grandes incógnitas (arquitectura enredada, flujos de datos poco claros, muchos casos límite), por hora puede ser más seguro.
5. Programa endurecimiento y preparación de despliegue. Muchas apps “funcionan” hasta que se mueven a producción. Reserva tiempo para cheques de seguridad, configurar entornos y un plan de despliegue limpio.

No necesitas un documento de aceptación largo. Unos pocos puntos claros suelen bastar:

• Inicio de sesión, cierre de sesión y restablecimiento de contraseña funcionan en Chrome y Safari.
• Los pagos se completan y los pagos fallidos muestran un mensaje útil.
• No hay secretos expuestos en la app o en los logs.
• Un escaneo básico de seguridad no encuentra rutas de inyección SQL.

Si trabajas con prototipos generados por IA (de herramientas como Bolt, v0, Cursor, Replit o Lovable), una auditoría corta suele marcar la diferencia entre una cotización fija confiada y una situación “incógnitas por todos lados” que requiere trabajo por hora.

Errores comunes que hacen arriesgados ambos modelos

La mayoría de las peleas sobre precios no tratan realmente del precio. Ocurren cuando nadie acuerda qué significa “hecho”, y las partes desordenadas del código sólo aparecen después de empezar a trabajar.

Una trampa común con las ofertas fijas es aprobar un alcance que es más sensación que plan. Si el alcance es vago, la cotización se basa en supuestos que nunca aprobaste. Después, cada sorpresa se convierte en una solicitud de cambio y o pagas extra o aceptas un arreglo parcial que no aguanta.

El trabajo por hora tiene el modo de fallo opuesto: puede sentirse seguro al principio y luego crecer en silencio. Sin un tope de presupuesto, una regla clara de parada o revisiones regulares, pequeñas investigaciones se convierten en tiempo sin fin.

La seguridad es otro lugar donde ambos modelos fallan. La gente se enfoca en el bug visible y se salta lo básico como claves de API filtradas, consultas inseguras o controles de acceso débiles. Así es como una app “funcionando” se convierte en un incidente después.

Un tercer error es tratar síntomas en lugar de la estructura. Si la app es espagueti, parchear la línea que falló puede crear dos fallos nuevos. Una buena reparación suele incluir algo de refactorización y límites más claros.

Señales de alarma que predicen problemas:

• El alcance no está escrito en lenguaje claro y verificable.
• No hay una definición de “hecho” que puedas probar.
• Nadie menciona seguridad o manejo de datos.
• Las actualizaciones son vagas (“haciendo progresos”) en vez de mostrar resultados completados.
• El plan depende de “lo resolveremos después” para funciones centrales.

Lista rápida antes de firmar algo

El código desordenado está lleno de sorpresas. El objetivo antes de empezar no es predecirlo todo. Es acordar qué significa “hecho”, quién puede acceder a qué y qué pasa si aparecen problemas ocultos.

Las cinco cosas a confirmar

Antes de aprobar una cotización o iniciar trabajo por hora, aclara estos puntos:

• Define el éxito en términos simples y comprobables. Apunta a 3–5 enunciados como “Los usuarios pueden registrarse e iniciar sesión”, “El correo de restablecimiento funciona”, “El checkout se completa sin errores” o “No hay secretos expuestos en el repo.”
• Confirma acceso, no sólo permisos. Asegúrate de que alguien pueda abrir el repo, ver logs y desplegar. Falta de acceso al hosting o variables de entorno puede parar el trabajo desde el día uno.
• Nombra los riesgos “debe arreglar” por adelantado. Bugs de autenticación, pérdida de datos y agujeros de seguridad deben ser prioridades.
• Fija un techo de presupuesto y una fecha límite de decisión. Incluso con trabajo por hora, puedes poner un tope de gasto y un punto de parada.
• Revisa si necesitas más que arreglar bugs. Si el problema real es estructura enredada, patrones inseguros o despliegues inestables, planea refactorización y preparación de despliegue.

Pregunta de seguimiento: ¿cómo se manejan las solicitudes de cambio? Cuando aparecen nuevos problemas (y aparecerán), quieres una regla simple para si se incluyen, se estiman por separado o se mueven a una segunda fase.

Qué pedir por escrito

No necesitas un contrato largo, pero sí un rastro claro por escrito:

• Un resumen corto del alcance más lo que se excluye explícitamente
• El método de aceptación (tests, demo en staging o una lista de comprobación firmada)
• Un plan de riesgos (qué pasa si una dependencia crítica o un módulo oculto falla)

Ejemplo: un prototipo que falla en producción

Un fundador tiene una app construida por IA que luce genial en una demo. Puedes hacer clic, añadir items y ver un dashboard. Luego usuarios reales intentan registrarse y todo se desmorona: algunos nunca reciben el correo de confirmación, otros entran como el usuario equivocado y algunas inscripciones hacen que la app crashee.

Tras mirar más de cerca, los desconocidos aparecen rápido:

• El flujo de autenticación está cosido con varias librerías, por lo que las sesiones expiran al azar.
• Se comprometieron secretos (claves de API y tokens) en el repo, así que la app está a una fuga de un incidente costoso.
• Las consultas a la base de datos funcionan con datos de demo pequeños, pero se vuelven lentas e inconsistentes con registros reales.

Ahora tienes que elegir precio fijo o por hora, y la opción más segura depende de cuánto quede por descubrir.

Opción A: precio fijo después de una auditoría corta

El precio fijo puede funcionar bien si primero haces una auditoría rápida y conviertes los hallazgos en una lista de reparaciones definidas. Para este prototipo, eso podría ser: arreglar el flujo de login y sesión de extremo a extremo, rotar y eliminar secretos expuestos, y estabilizar las consultas más problemáticas.

Pagas por un alcance por escrito y una definición clara de “hecho”. Si aparecen nuevos problemas fuera del alcance (por ejemplo, una incompatibilidad profunda del framework), se convierten en una solicitud de cambio separada en lugar de expandir el trabajo en silencio.

Opción B: por hora con un timebox y un tope

Por hora puede ser más seguro cuando esperas problemas ocultos y quieres flexibilidad. La clave es evitar un contador sin fin. Una configuración práctica es una investigación acotada en el tiempo (por ejemplo, 6–10 horas) seguida de topes semanales y un plan corto semanal.

Pide un límite de horas semanal, un plan escrito de “próximas 3 tareas” antes de empezar y una regla de parada cuando un arreglo se convierta en una reconstrucción.

Qué cambia si hace falta una reconstrucción parcial

Si la auditoría muestra que la capa de auth es fundamentalmente incorrecta (no hay un modelo de usuario fiable, middleware que entra en conflicto o un esquema que no puede soportar cuentas reales), una reconstrucción parcial puede ser más barata y segura que parchear. En ese caso, el precio fijo vuelve a ser atractivo, porque el alcance de la reconstrucción puede definirse en torno a una porción limpia y comprobable (auth + flujo de datos principal), en lugar de perseguir casos límite sin fin.

Próximos pasos: reducir riesgo y seguir adelante

Si quieres menos sorpresas, no empieces discutiendo el precio. Empieza haciendo el trabajo más pequeño y claro. El código desordenado esconde problemas, así que el movimiento más seguro es convertir incógnitas en una lista corta de problemas conocidos antes de que alguien se comprometa con una gran reparación.

Si necesitas certeza de coste, comienza con una fase de diagnóstico y pide una lista por escrito de lo que está roto, lo que es riesgoso y lo que puede esperar. Una vez claro, puedes pasar a una fase de precio fijo que cubra una porción definida del trabajo (no “arreglar todo”).

Si necesitas flexibilidad, por hora puede seguir siendo seguro con salvaguardas: un tope semanal, hitos claros y puntos de parada acordados donde decides si continuar, cambiar de dirección o pausar.

A veces la “solución” más segura es reconstruir. Si la arquitectura está enredada, los problemas de seguridad están por todas partes o las funciones básicas se siguen rompiendo entre sí, parchear puede costar más que reemplazar.

Si heredaste un prototipo generado por IA de herramientas como Lovable, Bolt, v0, Cursor o Replit, FixMyMess (fixmymess.ai) ofrece una auditoría de código gratuita para primero sacar la lista real de problemas. Desde ahí, es más fácil elegir el modelo de precio correcto, y muchos proyectos de remediación pueden completarse en 48–72 horas una vez que el alcance está claro.