← Volver al blog

Cómo contratar desarrollo a medida sin que se te vaya de las manos

Casi todos los proyectos a medida que vi salir mal no fracasaron por una mala elección de tecnología. Fracasaron por algo que se decidió mal en la primera semana y que nadie volvió a mirar hasta que ya era caro corregirlo.

Esta es la guía que le daría a cualquiera antes de su primera reunión con un desarrollador o un estudio, esté del lado que esté.

Antes de hablar de precio, hablá de la pregunta

Todo proyecto que vale la pena tiene una pregunta de negocio detrás, no una lista de funcionalidades. "Quiero una app para mi gimnasio" no es una pregunta. "¿Puedo dejar de perseguir a mis socios para que me paguen?" sí lo es.

Si en la primera reunión solo hablás de funcionalidades — login, panel de administración, notificaciones — y nadie pregunta cuál es el problema de fondo, es una señal de alerta. Un desarrollador que entiende el problema va a proponerte menos funcionalidades, no más, porque va a saber cuáles importan.

Podés leer más sobre cómo se traduce esa pregunta en alcance en de idea a MVP.

Las tres preguntas que hay que hacer en la primera reunión

¿Qué queda explícitamente afuera de esta primera versión? Si la respuesta es "todo entra", el presupuesto y el plazo que te den van a ser ficción. Un alcance real siempre tiene una lista de exclusiones tan clara como la de inclusiones.

¿Cómo se entrega el trabajo, en qué ciclos? La respuesta correcta describe entregas cortas y revisables — dos semanas, no dos meses. Si la única entrega es al final, no tenés forma de corregir el rumbo a tiempo, y para cuando ves el resultado, ya se gastó el presupuesto entero.

¿Qué pasa si a mitad de camino me doy cuenta de que necesito algo distinto? Todo proyecto cambia sobre la marcha. La pregunta no es si va a pasar, es cómo se maneja cuando pasa. Si la respuesta es "eso rompe el contrato", estás por firmar algo rígido para un proceso que no lo es.

Cómo estructurar el pago sin regalar el control

Nunca 100% por adelantado. Sin excepción. El pago por adelantado completo elimina cualquier incentivo del otro lado para entregar a tiempo o bien.

Nunca 100% contra entrega final tampoco. Esto empuja al desarrollador a estirar el trabajo en secreto durante meses sin que vos veas nada, porque el pago está todo atado al final.

Lo que funciona es pagar contra hitos verificables. Un anticipo razonable para arrancar (30-40% es común), y el resto atado a entregas concretas que podés ver funcionando, no a fechas del calendario. "Pago cuando el sistema de cobros procesa una transacción real" es un hito. "Pago el 15 de cada mes" no lo es.

Las señales de alerta que aprendí a reconocer

Un presupuesto que nadie puede explicar cómo se calculó. Un presupuesto serio se puede desglosar por funcionalidad o por etapa. Si la respuesta es un número sin desglose, ese número probablemente tiene mucho colchón adentro, o muy poco.

Nadie pregunta por tus usuarios reales. Si en ningún momento de la conversación preguntan quién va a usar el producto y qué sabe hacer esa persona, el producto que van a construir va a estar pensado para el desarrollador, no para quien lo va a usar todos los días.

La respuesta a todo es "sí, se puede". Un desarrollador que nunca dice que no, o que no te muestra un trade-off, no te está protegiendo de nada. Todo tiene un costo, y alguien que no te lo muestra te lo va a cobrar después, en tiempo o en calidad.

El plazo no cambia aunque cambie el alcance. Si agregás algo a mitad de camino y el plazo original sigue intacto, alguna otra cosa se está recortando sin que te avisen — generalmente calidad o testing.

Lo que sí es una buena señal

Alguien que te pregunta "¿por qué querés esto?" antes de preguntarte "¿cómo lo querés?". Alguien que te dice que una funcionalidad que pediste no es necesaria para la primera versión, y te explica por qué. Alguien que te muestra el trabajo funcionando cada dos semanas, aunque todavía le falten cosas.

Ninguna de esas señales tiene que ver con el stack tecnológico. Tienen que ver con si la persona del otro lado está pensando en tu negocio o en su próximo sprint.

Una guía, no una garantía

Nada de esto elimina el riesgo por completo — ningún proyecto de software está libre de sorpresas. Pero reduce el riesgo más común, que no es técnico: es el de descubrir a mitad de camino que nadie tenía el mismo proyecto en la cabeza.

Si estás evaluando un desarrollo a medida y querés que la primera conversación sea sobre estas preguntas, escribime.