Cómo contratar a un ingeniero de software freelance sin salir quemado

Para contratar a un ingeniero de software freelance sin salir quemado: verifica que haya lanzado software que siga funcionando hoy, habla directo con la persona que va a escribir el código, empieza con un hito pequeño de alcance fijo y pagado, mantén el código y cada cuenta a tu nombre desde el día uno, y trata las demos semanales de software funcionando como el único reporte de avance que cuenta. Haz esas cinco cosas y una mala contratación te cuesta unos pocos miles y un mes, en vez de un año y una reescritura.

Soy ingeniero de software freelance, así que este artículo es yo delatando a mi propia industria. Una parte importante de mis proyectos a lo largo de los años han sido rescates: sistemas que empezó alguien más y llegaron a medio terminar, sin documentación, o construidos de modo que solo el autor original podía tocarlos. Los patrones detrás de esos rescates se repiten, y todos eran visibles antes de firmar el contrato.

¿Por qué contratar ingenieros sale mal tan seguido?

Asimetría de información. No puedes leer código, así que no puedes evaluar directamente lo que estás comprando, y la seguridad en uno mismo es barata de fingir en una llamada de venta. La salida es dejar de intentar evaluar el código y empezar a evaluar el comportamiento: qué han lanzado, qué te preguntan, cómo arman el trato y cómo manejan no estar disponibles. Todo eso se observa antes de gastar dinero de verdad, y predice el resultado mejor que cualquier página de portafolio.

¿Qué deberías revisar antes de la primera llamada?

Tres cosas, ninguna requiere conocimiento técnico:

• Software que siga en producción. No capturas de pantalla ni actividad en GitHub: productos reales, con usuarios, que llevan años funcionando. Pregunta “¿qué has construido que siga funcionando hoy, y quién lo mantiene?”. La longevidad es la credencial más difícil de fingir. Yo me apoyo en esto: una década manteniendo la plataforma de un cliente dice más que cualquier certificación que pudiera listar.
• Historial de mantenimiento, no solo de lanzamiento. Cualquiera lanza la versión uno. El ingeniero que quieres ha vivido con sus propias decisiones durante años y te puede decir cuáles lamenta. Pregúntale qué haría distinto en un proyecto viejo; una respuesta pensada es buena señal, una mirada en blanco no.
• Cómo escribe. Vas a comunicarte con esta persona por escrito durante meses. Si sus propuestas, artículos o hasta correos son específicos y claros, la colaboración suele serlo también. La escritura vaga anticipa software vago.

¿Qué preguntas exponen a un ingeniero flojo en diez minutos?

Róbate estas para la primera llamada:

1. “¿Qué NO construirías en este proyecto?“ Los ingenieros fuertes recortan alcance por instinto y con gusto te dirán cuáles de tus ideas posponer. Los flojos dicen que sí a todo, porque cada sí factura.
2. “Llévame por algo que hayas lanzado y siga funcionando.” Escucha los detalles: restricciones reales, números reales, una decisión de diseño que puedan defender. Los recorridos de buzzwords significan que la profundidad no está.
3. “¿Qué pasa cuando te enfermas, te vas de vacaciones o desapareces?“ Estás contratando a una persona, así que la respuesta honesta involucra documentación, código convencional que otro ingeniero pueda retomar, y que tú seas dueño de todo. “Eso no va a ser problema” es un problema.
4. “¿Cómo tomaría el relevo otro ingeniero si nos separamos?“ La buena respuesta es aburrida: framework estándar, estructura estándar, readme, tus cuentas. Si la respuesta implica que quedas amarrado a él, créele.
5. “¿Cómo decides que algo está terminado?“ Estás escuchando por pruebas, una definición de terminado, y demos de software funcionando. Si “terminado” significa “subí el código”, la calidad ahora es tu trabajo.

¿Cuáles son las señales de alarma en una propuesta?

Señal de alarma	Lo que suele significar
Por hora abierto sobre un alcance vago	El riesgo de estimación es tuyo; el taxímetro corre mientras se descubre el alcance
No pregunta nada sobre tu negocio	Está construyendo desde una plantilla, no para tu operación
“Primero deberíamos reconstruir todo esto”	A veces es cierto, muchas veces es el diagnóstico más facturable posible
Un precio muy por debajo del rango de mercado	La diferencia reaparece después como reproceso, atraso o abandono
Sí a cada función, cero objeciones	Nadie está al timón; compras horas, no criterio
Cuentas y repos creados a su nombre	Amarre, sea intencional o no

Sobre la señal del precio: contrasta cualquier cotización contra rangos reales antes de creértela. Una oferta a un tercio del piso de un rango no anticipa un ahorro, anticipa reproceso, atraso o abandono.

¿Cómo armas el trato para que no te quemes feo?

La estructura importa más que la persona, porque limita el daño de una mala elección:

1. Empieza con un hito pequeño, pagado y de alcance fijo. Un flujo de trabajo, un entregable definido, un precio real, normalmente en el rango de una automatización acotada. Estás comprando software funcionando y una vista previa de cómo opera esta persona. Nunca empieces una relación grande al tamaño grande.
2. Sé dueño de todo desde el día uno. El repositorio de código vive en tu organización de GitHub. El hosting, el dominio y los servicios de terceros están registrados a tus cuentas, con el ingeniero invitado. Este solo hábito elimina la mayoría de las historias de terror, incluida la clásica negociación con rehén por un nombre de dominio.
3. Demos de software funcionando, cada semana. No reportes de estado ni porcentaje completado: una pantalla que puedas hacer clic. Si el software no se puede mostrar en pantalla, todavía no existe, por más que el reporte diga 80%.
4. Alcance fijo por fase, siempre. Después de cada hito, dimensiona el siguiente de nuevo con lo que ambos aprendieron. Esto mantiene honestas las estimaciones y te da una salida limpia en cada frontera.
5. Pon el mantenimiento por escrito antes del lanzamiento. Quién arregla bugs, a qué tarifa, con qué tiempo de respuesta. El momento más barato para negociar el soporte es mientras todavía quieren el proyecto.

Respuestas rápidas

¿Necesito una especificación detallada antes de contactar a alguien?

No, y una especificación rígida escrita sin un ingeniero muchas veces amarra las ideas equivocadas. Trae el problema de negocio, el flujo de trabajo actual y tu rango de presupuesto. Un buen ingeniero convierte eso en alcance contigo; esa conversación ya es parte de la evaluación.

¿Marketplace o recomendación?

Las recomendaciones de alguien cuyo proyecto de verdad puedes ver le ganan a los marketplaces, porque la longevidad se ve. Los marketplaces funcionan si aplicas todo lo de arriba e ignoras las estrellas de reseña; las calificaciones de cinco estrellas miden amabilidad, no si el software sobrevivió dos años.

¿Necesito un contrato?

Sí, uno corto: alcance, precio, calendario de pagos, y una cláusula que diga que tú eres dueño del código y de todas las cuentas. Si un freelance se resiste a la cláusula de propiedad, esa es la señal de alarma más barata que vas a recibir.

Ya me quemé. ¿Se puede salvar el proyecto?

Casi siempre, y muchas veces sin una reescritura completa. Un rescate empieza con una auditoría de lo que existe, y luego la misma estructura de arriba aplicada desde donde esté el código. Si estás en ese punto, la auditoría gratuita de abajo es justo para esto: mándame lo que tienes y te digo con honestidad si es salvable, y cuánto costaría en cualquier caso.