¿Precio fijo o por hora? Cómo pagarle a un desarrollador

Paga un precio fijo cuando el trabajo se puede describir con claridad antes de empezar, y por hora cuando no. Un arreglo bien definido, una landing o una función bien especificada encajan con un precio cerrado; investigar un error desconocido o explorar una idea nueva encaja con horas y un tope. Para cambios continuos, un plan mensual suele ser más simple que ambos.

En esta guía verás cómo funciona cada modelo, quién asume el riesgo en cada caso, las combinaciones que mezclan lo mejor de los dos y qué dejar por escrito para que nadie se lleve sorpresas.

¿Cómo funciona cada modelo de cobro?

¿Cuándo conviene el precio fijo?

El precio fijo funciona cuando ambas partes pueden imaginar el resultado terminado. Por ejemplo:

• Conectar un dominio propio y corregir las redirecciones del inicio de sesión que se rompen con él.
• Agregar suscripciones de Stripe con tres planes con nombre y precio.
• Construir una pantalla bien descrita a partir de un diseño.

Sus ventajas son la previsibilidad y el foco en el resultado. Sabes cuánto pagas antes de empezar, y el desarrollador tiene todos los motivos para trabajar de forma eficiente.

Sus debilidades aparecen cuando el alcance es difuso. Quien cotiza un precio fijo sobre algo poco claro le suma un margen por lo desconocido, así que puedes terminar pagando más de lo que habría salido por hora. Y cada cambio que pidas en el camino se vuelve una negociación.

¿Cuándo tiene más sentido cobrar por hora?

Por hora funciona cuando nadie puede saber el tamaño del trabajo hasta empezar:

• "A veces los usuarios pierden la sesión y no sabemos por qué."
• "Queremos ver si esta idea se puede hacer con lo que tenemos."
• "La app está lenta y no sabemos dónde."

Solo pagas el tiempo usado y puedes cambiar de rumbo con libertad. El riesgo es que no hay techo. Una investigación puede alargarse mucho, sobre todo si el desarrollador está conociendo tu código desde cero.

¿Cómo haces más seguro el trabajo por hora?

1. Acuerda un tope, por ejemplo un número de horas, antes de empezar.
2. Pide un corte a la mitad del tope: qué se encontró, qué falta y si conviene seguir.
3. Pide registros de tiempo que digan en qué se usó cada bloque de horas.
4. Define un punto de salida: "Si al llegar al tope no se encuentra la causa, entrega un resumen escrito de lo que se descartó".

¿Hay un punto intermedio?

Sí, y muchas veces es la mejor opción para una app con problemas que todavía no entiendes del todo:

1. Primero, un diagnóstico pagado. Una revisión corta del código, con precio cerrado, que termina en un informe escrito.
2. Después, precio fijo por arreglo. Una vez conocidos los problemas, cada uno se puede cotizar con claridad.

Así lo desconocido queda en una caja pequeña y con tope, y lo conocido, con precios cerrados. Nuestra guía sobre cuánto cuesta arreglar una app hecha con IA explica por qué las cotizaciones varían tanto antes de un diagnóstico.

En proyectos más grandes, el pago por etapas hace algo parecido: el proyecto se divide en fases, cada una con su entregable y su precio, y puedes parar después de cualquiera.

¿Y los planes mensuales o igualas?

Cuando el trabajo nunca termina del todo (arreglos, actualizaciones, cambios pequeños, monitoreo), cotizar cada tarea por separado es lento para todos. Un plan mensual te da un costo conocido y alguien que ya conoce la app. Revisa:

• Qué incluye: ¿solo arreglos o también funciones nuevas?
• Qué tan rápido responden y en qué días.
• Qué pasa con el tiempo que no usas: ¿se acumula o se pierde?
• Cómo cancelar y con cuánto aviso.

¿Qué debe quedar por escrito, sea cual sea el modelo?

1. Alcance. Qué se entrega y qué queda explícitamente fuera.
2. Aceptación. Cómo van a saber ambos que está terminado: "un usuario puede pagar y ve la insignia Pro en menos de un minuto".
3. Cambios. Cómo se manejan los pedidos nuevos: otra cotización, horas extra o la siguiente etapa.
4. Forma de pago. Anticipo, pago por etapa y cuándo vencen las facturas.
5. Propiedad. Que el código pasa a ser tuyo una vez pagado. Nuestra explicación sobre quién es dueño del código hecho con IA cuenta por qué importa (y por qué conviene que lo revise un abogado).
6. Accesos y entrega. Código en tu repositorio, cuentas a tu nombre y documentación al final.

¿Qué señales de alerta debes vigilar?

• Un precio fijo dado sin mirar el código ni el diseño.
• Trabajo por hora sin estimación, sin tope y sin avances.
• Un precio fijo muy bajo para algo que claramente toca pagos o permisos, lo que suele significar que se va a tapar el síntoma y no la causa.
• Nada de alcance por escrito.

Respuestas rápidas

¿El precio fijo siempre sale más caro? No siempre. En trabajo claro puede salir más barato porque no se pierde tiempo negociando. En trabajo poco claro suele incluir un margen por el riesgo.

¿Puedo cambiar de modelo a mitad del proyecto? Sí, y es habitual: empezar por hora para investigar y pasar a precio fijo cuando el trabajo ya está definido.

¿Pago todo por adelantado? En trabajos grandes, pagar por etapas protege mejor a ambas partes que pagar todo al principio o al final.

¿Qué modelo conviene para una app hecha con IA que tiene errores? Un diagnóstico corto pagado y luego precio fijo por arreglo, porque los problemas casi nunca se conocen hasta que alguien lee el código.

¿Cómo cobra Devonauts?

Trabajamos con diagnóstico y luego precio fijo: la App Rescue Audit cuesta USD 299, cada arreglo encontrado recibe un precio cerrado que apruebas antes, y el trabajo continuo va en planes mensuales. Mira nuestros precios, el mantenimiento de software y el desarrollo de MVP, o escríbenos.