Qué te tiene que mostrar un dev antes de confiarle tu producto
Estás por transferirle a alguien USD 30.000 para que construya tu producto, y no sabés programar. No podés revisar el código, así que tu única defensa es saber qué pedir antes de pagar. La mayoría de los founders no técnicos descubren tarde lo que debieron exigir el día uno.
Antes de confiarle tu producto a un dev, te tiene que mostrar cinco cosas concretas: trabajo previo navegable, un proceso de entregas frecuentes, propiedad del código a tu nombre, una estimación con supuestos explícitos, y un plan de qué pasa si se va. No hace falta saber código para evaluar ninguna de las cinco. Importan porque, según estadísticas de outsourcing 2026, entre el 25% y 50% de los proyectos tercerizados fallan, y casi nunca es por falta de talento: es por falta de claridad y de las protecciones correctas desde el principio.
Lo escribo desde el lado del que construye. Cuando un buen profesional te muestra estas cosas sin que se las pidas dos veces, es buena señal. Cuando se resiste o se ofende, ahí tenés tu respuesta, y te acabás de ahorrar un dolor de cabeza caro.
Trabajo previo que puedas navegar, no solo screenshots
Un dev confiable te muestra productos reales funcionando, con links que podés abrir y usar, no solo capturas de pantalla bonitas. Los screenshots se maquillan; un producto en vivo, no. Pedí entrar, hacer clic, romper algo. Si todo lo que tiene son imágenes y "confiá en mí", desconfiá.
Mirá especialmente productos parecidos al tuyo en complejidad. Que alguien haya hecho una landing impecable no garantiza que pueda construir un SaaS con usuarios, pagos y lógica de negocio. Y prestá atención al detalle: ¿los productos que muestra siguen vivos y mantenidos, o son cáscaras abandonadas? Sobre por qué el código que se mantiene en el tiempo vale más que el que impresiona, escribí código que no pide atención.
Un portafolio de screenshots es una promesa. Un producto en vivo que podés tocar es una prueba.
Un proceso de entregas, no un "avisamos cuando esté"
Un buen dev te muestra cómo va a entregar antes de empezar, y la respuesta correcta incluye demos frecuentes. El estándar sano son entregas cada una o dos semanas: ves el producto funcionando, lo probás, y decidís si seguís en esa dirección o corregís. Lo opuesto, "nos avisás cuando esté listo dentro de tres meses", es la receta del desastre.
Las entregas frecuentes son tu mejor protección porque te dejan cortar temprano si algo va mal, en vez de descubrirlo cuando ya gastaste todo. Esto se conecta con cómo pagás: el dinero atado a entregas, no por adelantado.
| Señal | Buena | Mala |
|---|---|---|
| Ritmo de entrega | Demos cada 1-2 semanas | "Avisamos al final" |
| Forma de pago | Atada a entregas | 100% por adelantado |
| Comunicación | Proactiva y clara | Hay que perseguirla |
| Cambios de alcance | Documentados y cotizados | "Después lo vemos" |
El 66% de los proyectos de IT se pasan de presupuesto, y los que entregan seguido y cobran contra entrega se pasan mucho menos. Sobre la lógica de mostrar avances antes de tener todo perfecto, escribí por qué dejé de planear releases perfectos.
El código tiene que ser tuyo desde el día uno
Tu producto te pertenece, y eso incluye el código: el repositorio tiene que estar a tu nombre desde el primer commit. Suena obvio, pero es uno de los errores más caros y silenciosos. Muchos founders descubren meses después que el código vive en la cuenta del dev o de la agencia, y que recuperarlo o migrarlo cuesta una fortuna o directamente no se puede.
Pedilo explícito antes de empezar: el repositorio en tu cuenta de GitHub, vos como dueño, el dev como colaborador. No es desconfianza, es higiene básica. Un profesional serio lo entiende y no se ofende; al contrario, suele proponerlo él mismo.
La señal de alarma más fuerte de todas: si alguien se resiste a darte la propiedad del código, no le confíes tu producto. Punto. El que quiere dejarte atado es el que te va a costar caro el día que quieras cambiar de proveedor o sumar a otra persona al equipo, algo que toqué en fractional CTO vs contratar vs cofundar.
Una estimación con supuestos, no un número mágico
Una buena estimación te dice qué incluye, qué no incluye y bajo qué supuestos se hizo, no solo un precio final. "Tu MVP sale USD 35.000" sin desglose es una bandera roja. La pregunta correcta es: ¿qué pasa si algo tarda más, si cambia el alcance, o si un supuesto resulta falso?
Un MVP a medida cuesta hoy entre USD 25.000 y 55.000, pero el número solo significa algo si sabés qué cubre. Pedí que la estimación liste las funciones incluidas, las explícitamente excluidas, y cómo se cotizan los cambios. Eso te protege del 27% de retrabajo promedio que tienen los proyectos tercerizados cuando el alcance no estaba claro.
Una estimación honesta admite incertidumbre. La que promete precisión absoluta sobre algo que todavía no existe, miente.
Un plan de qué pasa si se van
Un dev confiable te deja preparado para que otra persona pueda continuar su trabajo, aunque eso signifique que un día no te necesite. Esto incluye documentación mínima, código ordenado y el uso de tecnologías estándar que cualquier developer competente pueda retomar. Si el producto depende de una herramienta exótica que solo esa persona entiende, estás encerrado.
La pregunta de oro que tenés que hacer: "si mañana no podés seguir, ¿otra persona puede tomar esto y continuar?". La respuesta te dice todo sobre cuánto pensó en vos y no solo en facturarte. El recorrido completo para no equivocarte al elegir a quién construye está en tenés la idea, no el código: cómo construir tu SaaS.
Las cinco señales en orden, como checklist
Antes de firmar y transferir, repasá esta lista. Si alguien falla en tres o más, no es tu persona.
- Trabajo previo navegable: productos en vivo que podés abrir y usar, no solo capturas.
- Entregas cada 1-2 semanas: un ritmo de demos pactado antes de empezar, no "avisamos al final".
- Propiedad del código: el repositorio a tu nombre desde el primer commit, sin discusión.
- Estimación con supuestos: qué incluye, qué no, y cómo se cotizan los cambios de alcance.
- Plan de continuidad: documentación y tecnología estándar para que otro pueda retomarlo.
Esta lista no requiere que sepas una sola línea de código para usarla. Cada punto es una pregunta directa que cualquier founder no técnico puede hacer en la primera reunión. La respuesta, y sobre todo la actitud frente a la pregunta, te dice más que cualquier currículum. Un buen profesional responde estas cinco cosas con naturalidad porque ya las tiene resueltas; el que improvisa o esquiva es el que te va a costar caro. Usá la lista como filtro: te ahorra meses de descubrir por las malas lo que podías saber en treinta minutos.
Preguntas frecuentes
¿Cómo evalúo a un desarrollador si no sé programar?
No evalúes el código, evaluá las señales que cualquiera puede leer: trabajo previo en vivo que puedas navegar, un proceso de entregas cada una o dos semanas, propiedad del código a tu nombre, una estimación con supuestos claros y un plan de continuidad. Entre el 25% y 50% de los proyectos tercerizados fallan por falta de claridad, no de talento, así que estas señales te protegen más que cualquier conocimiento técnico.
¿Por qué es tan importante ser dueño del repositorio?
Porque tu producto te pertenece y el código es tu producto. Si el repositorio queda en la cuenta del dev o la agencia, recuperarlo o migrarlo después puede costar una fortuna o ser imposible. Pedí el repositorio a tu nombre desde el primer commit. Si alguien se resiste a dártelo, es la señal más fuerte para no confiarle tu producto.
¿Está bien pagar todo el desarrollo por adelantado?
No. El estándar sano son pagos atados a entregas: ves algo funcionando cada una o dos semanas y pagás contra eso. Pagar el 100% por adelantado te quita tu única palanca si el proyecto se desvía. Como el 66% de los proyectos de IT se pasan de presupuesto, cobrar contra entrega te deja cortar temprano si la cosa no avanza.
¿Qué hago si un dev se ofende cuando le pido estas cosas?
Tomalo como información valiosa. Un buen profesional entiende que estas condiciones te protegen sin quitarle nada y muchas veces las propone él mismo. El que se ofende cuando pedís propiedad del código, demos frecuentes o una estimación con supuestos suele ser el que te quiere dejar atado. La reacción a tus pedidos razonables es, en sí misma, una validación.
¿Cómo sé si la estimación que me dieron es realista?
Una estimación realista admite incertidumbre y lista supuestos; una sospechosa promete un número exacto sin desglose. Un MVP a medida ronda los USD 25.000-55.000, pero el monto solo significa algo si sabés qué incluye, qué excluye y cómo se cotizan los cambios. Si te dan un precio cerrado sin condiciones sobre algo que todavía no existe, pedí el desglose antes de firmar.