Cómo contratar y dar instrucciones a un desarrollador cuando no eres técnico
No necesitas ser técnico para contratar bien a un desarrollador. Necesitas saber qué preparar, qué preguntar y cómo es una buena comunicación. Aquí tienes una guía práctica para fundadores no técnicos.
Shayan Jamil·31 de mayo de 2026·6 min de lectura
Contratar a un desarrollador cuando no puedes juzgar el código por ti mismo parece arriesgado y, siendo sinceros, lo es, pero no de la forma que la mayoría piensa. No necesitas entender el trabajo técnico para contratar bien. Necesitas saber qué preparar, qué preguntas revelan de verdad a un buen desarrollador y cómo es una comunicación sana una vez que empieza el trabajo.
He estado al otro lado de cientos de estas conversaciones con fundadores, y las que salen bien siguen un patrón. Así es como puedes prepararte para no estar jugándotela a ciegas.
El problema de negocio: estás juzgando algo que no sabes leer
Un fundador no técnico no puede revisar un pull request ni detectar una decisión de arquitectura poco sólida. Así que te ves obligado a juzgar a un desarrollador por indicadores indirectos: cómo se comunica, cómo define el alcance, lo honesto que es sobre las ventajas y desventajas de cada opción. La buena noticia es que esos indicadores son sorprendentemente fiables. Un desarrollador que se comunica con claridad y define el alcance con cuidado casi siempre hace mejor trabajo que uno que dice "sí" a todo.
El riesgo no es elegir a alguien cuyo código no sabes leer. Es elegir a alguien que te dice lo que quieres oír, desaparece dos semanas y reaparece con algo que no da en el clavo.
Qué preparar antes de contactar a nadie
No necesitas una especificación técnica. Necesitas claridad sobre el problema, no sobre la solución. Antes de contactar a nadie, intenta dejar por escrito:
- El problema que resuelves y para quién, en lenguaje sencillo.
- Lo esencial que debe hacer el producto: la funcionalidad sin la cual no tiene sentido.
- Ejemplos: apps o webs que hagan algo parecido, aunque sea vagamente.
- Tus limitaciones: presupuesto aproximado, plazo aproximado, cualquier fecha límite inamovible.
- Cómo sería el éxito para una primera versión.
No tiene que estar pulido. Media página clara sobre el problema vale más que una lista de deseos vaga con cincuenta funcionalidades, y ayuda a un buen desarrollador a definir el alcance del trabajo con honestidad. (Si estás en la fase de idea, cómo definir el alcance de un MVP es un buen complemento a este artículo).
Buenas señales y señales de alerta
Después de suficientes proyectos, las señales se vuelven fáciles de leer.
Buenas señales:
- Hacen preguntas antes de dar un presupuesto, sobre todo sobre el problema, no solo sobre las funcionalidades.
- Cuestionan el alcance y sugieren qué recortar para una primera versión.
- Explican las ventajas y desventajas en lenguaje sencillo en lugar de esconderse tras la jerga.
- Te dan plazos honestos, incluyendo lo que es incierto.
Señales de alerta:
- Dicen que sí a todo y dan un presupuesto al instante sin hacer preguntas.
- No saben explicar su plan sin jerga, o no quieren hacerlo.
- Se quedan callados durante largos periodos y reaparecen con sorpresas.
- El precio parece demasiado bueno para ser verdad, lo que normalmente significa que acabarás pagando dos veces.
La pregunta de entrevista más útil
"Si tuvieras que recortar esto para lanzar un mes antes, ¿qué quitarías?". Un buen desarrollador tendrá al instante una respuesta meditada. Demuestra que piensa en términos de compromisos y de tu presupuesto. Alguien que insiste en que no se puede recortar nada o no entiende cómo se define un alcance o no quiere hacerlo.
Cómo es una buena comunicación una vez que empieza el trabajo
El mejor indicador de que un proyecto va a salir bien no es la habilidad pura. Es la comunicación. Lo que quieres ver es un ritmo constante: actualizaciones periódicas, un progreso contado con honestidad (incluido lo que va más lento de lo previsto), trabajo entregado en partes pequeñas y revisables en lugar de una gran revelación al final, y una conversación real cuando hay que tomar una decisión.
Así es exactamente como intento trabajar: actualizaciones semanales claras, avisar de los bloqueos el mismo día que los veo y poner sobre la mesa las ventajas y desventajas en lugar de esconderlas. Puedes leer más sobre cómo abordo el trabajo con clientes. La clave es que tú, como fundador no técnico, sí puedes juzgar esto. No necesitas leer código para saber si alguien te mantiene informado y es sincero contigo.
Un ejemplo real
Gran parte de mi trabajo llega de fundadores que tuvieron una primera experiencia complicada: un desarrollador que desapareció o un desarrollo que se alejó de lo que realmente necesitaban. La solución rara vez es más brillantez técnica; es una comunicación más estrecha y una definición honesta del alcance. Cuando los fundadores y yo trabajamos bien juntos, es porque primero nos pusimos de acuerdo sobre el problema central, mantuvimos un ciclo de feedback corto y tomamos las decisiones abiertamente en lugar de esperar que todo saliera bien. Esa es la parte sobre la que tienes control total, seas técnico o no.
Errores comunes de los fundadores no técnicos
- Explicar funcionalidades en lugar del problema, de modo que el desarrollador optimiza lo que no es.
- Contratar solo por precio y pagar dos veces cuando hay que rehacer el trabajo barato.
- No hacer preguntas porque parecen demasiado técnicas, cuando la comunicación es precisamente lo que sí puedes juzgar.
- Aceptar una gran revelación al final en lugar de avances pequeños y periódicos a los que puedas reaccionar.
- Confundir seguridad con competencia: la persona que cuestiona tu alcance suele servirte mejor que la que está de acuerdo con todo.
Cómo trabajo con fundadores no técnicos
- Empiezo por el problema, no por una lista de funcionalidades, y hago pronto las preguntas importantes.
- Defino el alcance con honestidad, incluido qué recortar para una primera versión más ligera y rápida.
- Me comunico en lenguaje sencillo: compromisos y avances, sin muros de jerga.
- Mantengo el ciclo corto con actualizaciones periódicas y trabajo pequeño y revisable.
- Aviso de los bloqueos de inmediato, para que no haya sorpresas al final del proyecto.
No deberías tener que volverte técnico para conseguir un buen software. Deberías poder confiar en la persona que lo construye, y esa confianza es algo que puedes juzgar perfectamente.
¿Buscas un desarrollador con el que puedas comunicarte de verdad?
Si eres un fundador no técnico y quieres a alguien que trate tu proyecto como si fuera suyo (actualizaciones claras, compromisos explicados con honestidad, nada de desapariciones), así es exactamente como trabajo.
Lee un poco sobre cómo trabajo, mira lo que he construido y ponte en contacto para contarme tu proyecto. Haré las preguntas adecuadas antes de empezar.