Cómo Contratar a un Desarrollador para Tu App
La mayoría de los fundadores abordan la contratación de desarrolladores de la misma manera que compran un producto: comparan características, comparan precios, eligen uno. Este es casi siempre el enfoque equivocado, y lleva a resultados que van desde "mediocre y caro" hasta "perdí todo y empiezo de nuevo."
Aquí hay un proceso mejor.
Define para qué estás contratando realmente
Antes de publicar en ningún sitio, escribe una descripción clara de: - Qué hace la app (un párrafo) - El stack tecnológico o la plataforma (o pide su recomendación) - Los entregables específicos (pantallas, funcionalidades, integraciones) - El plazo hacia el que trabajas - Tu rango de presupuesto (sí, inclúyelo: los desarrolladores cualificados se autoseleccionarán y perderás menos tiempo)
Los briefs vagos atraen propuestas vagas. Los briefs específicos atraen a desarrolladores que han leído todo.
Dónde encontrar buenos candidatos
Referencias: La mejor fuente, con diferencia. Pregunta a otros fundadores en tu red que hayan construido apps con las que estén satisfechos. Una referencia cálida de alguien en cuyo criterio confíes vale 50 solicitudes en frío.
Toptal y Arc.dev: Redes de freelancers verificados con tarifas más altas pero calidad preseleccionada. Bueno para fundadores que no pueden evaluar la calidad técnica por sí mismos.
Upwork y Freelancer.com: Alto volumen, alta varianza. Puedes encontrar excelentes desarrolladores aquí, pero la relación señal-ruido requiere experiencia para navegarla. Úsalo solo con un brief claro y un proceso de evaluación estructurado.
LinkedIn: Bueno para encontrar desarrolladores que buscan trabajo activamente o están abiertos al trabajo freelance. Busca desarrolladores con experiencia en el stack específico en tu región.
El proceso de evaluación que funciona
Paso 1: Revisión del brief (30 minutos de tu tiempo) Lee cada propuesta. Descalifica inmediatamente a cualquiera que: (a) no haya leído tu brief, (b) te haya dado una respuesta de plantilla genérica, o (c) no pueda explicar claramente cómo abordaría tu proyecto específico.
Paso 2: Videollamada (45 minutos) Pídeles que te expliquen un proyecto similar al tuyo que hayan construido. Pregunta: ¿Cuál fue el problema técnico más difícil? ¿Qué harían de manera diferente? Pregunta cómo manejan los cambios de alcance, la frecuencia de comunicación y la entrega de código. Escucha en busca de claridad, honestidad sobre las limitaciones y si hacen preguntas sobre tu proyecto o simplemente se venden a sí mismos.
Paso 3: Proyecto de prueba remunerado (500€–2.000€) Paga una tarea pequeña y claramente definida que sea directamente relevante a tu proyecto. Esto podría ser: construir una pantalla con datos reales, configurar el flujo de autenticación o diseñar el esquema de base de datos para tus entidades principales. Evalúa la calidad del resultado, la comunicación durante la tarea y el cumplimiento del brief.
Paso 4: Verificación de referencias Llama (no envíes correos electrónicos) a al menos dos clientes recientes. Pregunta: ¿Entregaron a tiempo? ¿Hubo sobrecostes? ¿Les contratarías de nuevo? ¿Cuál fue la parte más difícil de trabajar con ellos?
Los elementos imprescindibles del contrato
Antes de que comience el trabajo, tu contrato debe incluir: - Cláusula de cesión de propiedad intelectual: todo el código escrito para este proyecto es de tu propiedad - Cláusula de acceso: tienes acceso de administrador a todos los repositorios, entornos de despliegue y cuentas de dominio - Estructura de pago vinculada a hitos: nunca pagues más del 20–30% antes de la entrega del primer hito - Cláusula de rescisión: puedes rescindir por cualquier motivo con 2 semanas de preaviso, y todo el trabajo hasta la fecha debe ser entregado - Proceso de solicitud de cambios: cualquier cambio de alcance requiere aprobación por escrito y una estimación revisada antes de que comience el trabajo
Si un desarrollador rechaza alguno de estos términos, no lo contrates.
El error más costoso
Pagar por adelantado en su totalidad, o pagar grandes cantidades sin entregables correspondientes. Esto elimina todo tu poder de negociación si la calidad es mala o el proyecto se estanca. Estructura tus pagos para mantenerte un hito por delante, nunca dos.
Comunidades donde los buenos desarrolladores ya pasan su tiempo
Las plataformas de empleo son donde los desarrolladores buscan trabajo. Las comunidades son donde lo hacen. Publicar en el segundo grupo suele dar con personas que no buscan trabajo activamente pero que aceptarán un proyecto interesante de un fundador que aparece donde ellos ya están.
- GitHub: No es un portal de empleo, pero sí el lugar más rico para evaluar a un desarrollador antes incluso de hablar con él. Más sobre esto más abajo.
- Stack Overflow: Un sitio veterano de preguntas y respuestas para programadores. Un desarrollador con un buen historial de respuestas sobre temas relevantes para tu stack ha ayudado de forma demostrable a desconocidos a resolver problemas reales, en público, durante años.
- Reddit: Subreddits como r/reactnative, r/FlutterDev o r/iOSProgramming están llenos de desarrolladores en activo. Buscas a quienes responden preguntas con criterio, no a quienes solo publican autopromoción.
- Grupos de Discord y Slack: La mayoría de los frameworks importantes tienen un chat de comunidad oficial. Son buenos lugares para encontrar especialistas y hacerte una idea de quién explica las cosas con claridad frente a quién solo presume.
- Quedadas locales y conferencias técnicas: Especialmente valiosas para fundadores europeos que quieren a alguien en una zona horaria compatible. Un desarrollador que da charlas o asiste con regularidad a estos encuentros suele estar comprometido con su oficio más allá del trabajo diario.
La señal que buscas es la misma en todas partes: ¿esta persona ayuda a los demás, explica con claridad y se mantiene al día? Esos tres rasgos predicen una buena relación de trabajo mejor que cualquier lista de tecnologías en un CV.
Cómo leer un portafolio sin ser técnico
No puedes juzgar la calidad del código si no sabes leer código. Pero puedes juzgar muchas otras cosas, y la mayoría importan más para un MVP.
Abre las apps de verdad. Un portafolio de capturas de pantalla no demuestra nada. Descarga dos o tres de las apps que el desarrollador dice haber construido y úsalas como un cliente real. ¿Son rápidas? ¿Se cuelgan? ¿Tienen sentido las pantallas? ¿Hay algo evidentemente roto? Una app que te frustra también frustrará a tus usuarios.
Mira el perfil de GitHub. En GitHub, el historial público de contribuciones de un desarrollador es visible para cualquiera. Según la propia documentación de GitHub, el gráfico de contribuciones muestra la actividad pública a lo largo del tiempo. No estás leyendo el código: estás comprobando señales. ¿Hay actividad reciente, o todo se detuvo hace dos años? ¿Tiene proyectos reales con varias actualizaciones a lo largo de meses, o solo un puñado de experimentos de un día? No te fijes solo en los cuadritos verdes; rellenar el gráfico con commits sin sentido es un truco conocido. Lo que importa es si los repositorios contienen trabajo real y sostenido.
Pregunta cuál fue exactamente su papel. "Yo construí esta app" puede significar que escribió cada línea, o que era una de ocho personas y solo tocó la pantalla de ajustes. Pregunta directamente: ¿qué construiste tú personalmente y qué hizo el resto del equipo? Los desarrolladores honestos responden esto con precisión. Los vagos se incomodan.
Comprueba que el portafolio encaja con tu proyecto. Un desarrollador brillante que solo ha construido videojuegos puede no ser el adecuado para una app de reservas con pagos y panel de gestión. La experiencia relevante supera al talento puro en un primer desarrollo, porque no tienes presupuesto para pagar la curva de aprendizaje de nadie.
Cómo suenan realmente las buenas respuestas en una entrevista
Los pasos de la entrevista te dicen qué preguntar. Aquí tienes cómo interpretar lo que oyes, porque la forma de una respuesta revela más que su contenido.
Sobre su problema técnico más difícil. Una buena respuesta es específica y humilde: describen una restricción real, las opciones que sopesaron, la concesión que eligieron y lo que les costó. Una respuesta débil es o bien "nada fue realmente difícil" (inexperiencia o arrogancia) o un muro de jerga diseñado para cerrar la conversación en lugar de explicarla.
Sobre qué harían de forma diferente. Todo desarrollador con experiencia tiene cosas de las que se arrepiente en proyectos pasados. Quien afirma que no cambiaría nada o bien no ha construido mucho o no es honesto al respecto. Quieres autocrítica medida, no un discurso de ventas.
Sobre tu proyecto en concreto. La mejor señal en cualquier entrevista es si el desarrollador te hace preguntas. Quien suelta de inmediato un precio y un plazo sin entender a tus usuarios, tus casos límite o tus prioridades, está adivinando. Quien cuestiona partes de tu alcance, o señala que una funcionalidad será más cara de lo que esperas, te está haciendo un favor. Esa fricción es por lo que pagas.
Sobre lo que no sabe. Pregunta por algo justo fuera de la experiencia que ha declarado. "No he hecho eso, pero así es como lo averiguaría" es una respuesta fuerte. Fingir que se sabe todo es el rasgo más caro que puede tener un desarrollador, porque aparece más tarde en forma de errores cometidos con seguridad.
Propiedad intelectual: por qué los fundadores europeos necesitan una cláusula explícita
Esto merece más de una línea, porque la posición legal por defecto probablemente no es la que supones.
En Estados Unidos, la doctrina del "work made for hire" puede situar la propiedad del trabajo encargado en la empresa que lo pagó, cuando así lo dice el contrato. Muchos fundadores asumen que esto es universal. No lo es. En el Reino Unido y en buena parte de la UE, lo habitual es lo contrario: salvo que tu contrato te ceda los derechos de forma explícita, el desarrollador que escribió el código puede conservar los derechos de autor sobre él, aunque tú lo hayas pagado.
La consecuencia práctica es grave. Sin una cesión por escrito, podrías no tener el derecho legal de modificar tu propia app, entregarla a otro desarrollador o vender tu empresa de forma limpia, porque parte del producto sigue perteneciendo a otra persona.
Así que, para un desarrollo europeo, no te fíes de una frase de "work for hire" al estilo estadounidense copiada de una plantilla. Tu contrato necesita:
- Una cesión explícita de toda la propiedad intelectual del trabajo a ti o a tu empresa, efectiva en el momento de la creación o del pago.
- Una renuncia a los derechos morales allí donde la ley lo permita, para que el desarrollador no pueda oponerse después a los cambios que hagas en el trabajo.
- Una garantía de originalidad, que confirme que el código es suyo para cederlo y que no toma material de un cliente anterior ni de una licencia que pudiera contaminar tu proyecto.
Esta es la única área donde pagar a un abogado local para que revise una cláusula de una página casi siempre merece la pena. El coste es pequeño. El coste de equivocarse puede ser tu empresa entera.
Cómo gestionar la relación después de contratar
Contratar bien es la mitad del trabajo. La otra mitad es la relación de trabajo, y la mayoría de las rupturas entre fundador y desarrollador son fallos de gestión, no de talento.
Acuerda un ritmo de comunicación por escrito. Decide antes de empezar con qué frecuencia recibirás actualizaciones y por qué canal. Una breve actualización escrita al final de cada semana, más una llamada en directo, funciona para la mayoría de los desarrollos de MVP. El silencio es la primera señal de alarma; un ritmo fijo elimina la ambigüedad.
Exige software funcional en cada hito. No aceptes "está casi terminado" como entregable. Cada hito debe producir algo que puedas abrir y usar de verdad, aunque esté incompleto. El progreso que no puedes ver no es progreso que puedas verificar.
Mantén los accesos a tu nombre desde el primer día. El repositorio, la cuenta de hosting, el dominio, los listados en las tiendas de apps: todo esto debe estar registrado bajo tus cuentas, con el desarrollador añadido como colaborador. Nunca dejes que tu negocio dependa de iniciar sesión en una cuenta que pertenece a otra persona.
Canaliza cada cambio de alcance por un único proceso escrito. Cuando quieras un cambio, ponlo por escrito, pide una estimación de coste e impacto en el plazo, y apruébalo antes de que empiece el trabajo. Esto protege a ambas partes y mantiene el presupuesto honesto.
Trata el proyecto de prueba como el inicio de un periodo de prueba, no como el final del filtrado. Las primeras semanas del proyecto real te dicen si la colaboración funciona. Si la comunicación es lenta, los plazos se incumplen sin aviso o la calidad se desvía, abórdalo de inmediato y de forma directa. Un buen desarrollador agradece el feedback claro. Si los problemas persisten, tu estructura de pagos por hitos es lo que te permite separarte sin perder todo el presupuesto.