Qué preguntar antes de contratar a un desarrollador de apps
Checklist de preguntas para contratar desarrollador de apps: portfolio, código, precio cerrado, pagos, mantenimiento y señales de alarma.
Germán Hernández
· 7 min de lectura
Antes de contratar a un desarrollador de apps pregunta por su portfolio verificable en las tiendas, quién es el dueño del código y de las cuentas de App Store y Google Play, si el precio es cerrado u por horas, cómo se reparten los pagos y qué pasa si algo falla después de publicar. Si no puede responder con claridad a estas preguntas, sigue buscando.
Elegir mal a quien construye tu app cuesta más que el dinero del proyecto: cuesta el tiempo que pierdes, el lanzamiento que se retrasa y, muchas veces, un código que nadie más quiere tocar después. Esta lista es la que uso yo mismo para que un cliente me pueda evaluar, y la misma que te serviría con cualquier otro desarrollador o agencia.
¿Puedo ver apps reales que hayas publicado?
Pide el nombre exacto de dos o tres apps y búscalas tú mismo en App Store o Google Play. No te conformes con capturas de pantalla en un PDF: instala la app, mira las valoraciones, la fecha de la última actualización y si sigue activa. Una app que dejó de actualizarse hace dos años dice mucho sobre el mantenimiento que vas a recibir.
Si el desarrollador solo puede enseñar mockups o proyectos "en proceso de aprobación" desde hace meses, es una señal de alarma.
¿De quién es el código y las cuentas cuando termine el proyecto?
Esta es la pregunta que más disgustos evita. Antes de firmar nada, aclara por escrito:
- El repositorio de código queda a tu nombre desde el primer commit, no se entrega al final.
- La cuenta de desarrollador de Apple y la de Google Play están registradas con tu empresa, no con la del proveedor.
- El dominio y los servicios en la nube (base de datos, hosting) están en tu cuenta, aunque el desarrollador los configure.
Si el proveedor se niega a traspasar algo de esto, o lo deja "para más adelante", tienes un problema: te quedas atado a esa persona o empresa para siempre, incluso para un cambio pequeño.
¿Precio cerrado o por horas?
Ambos modelos son legítimos, pero cambian el riesgo que asumes:
| Precio cerrado | Por horas | |
|---|---|---|
| Riesgo de sobrecoste | Lo asume el desarrollador | Lo asumes tú |
| Necesita alcance definido de antemano | Sí | No, se puede ir ajustando |
| Encaja mejor con | Un producto con funciones claras (MVP, app de reservas, catálogo) | Proyectos con mucha incertidumbre o que cambian sobre la marcha |
| Riesgo principal | Que el alcance esté mal definido y todo cambio se cobre aparte | Que el proyecto se alargue sin un límite claro |
Si te proponen precio cerrado, pide que el alcance quede por escrito: pantallas, funciones incluidas y explícitamente las que no. Si es por horas, pide una estimación de horas totales y un aviso si se va a superar en más de un 15-20%.
¿Qué no está incluido en el precio?
Todo presupuesto serio tiene una lista de exclusiones, no solo de entregables. Pregunta específicamente por:
- Cuentas de desarrollador de Apple (99 USD/año) y Google (25 USD de pago único): normalmente las paga el cliente.
- Integraciones con sistemas que ya usas (ERP, TPV, CRM).
- Varios roles de usuario o permisos distintos si no los pediste desde el principio.
- Diseño de marca, logo o contenido (fotos, textos) si no se menciona explícitamente.
- Funciones de IA a medida, que casi siempre se cotizan aparte.
Un presupuesto sin lista de exclusiones no está mal hecho a propósito, pero te deja expuesto a "eso es un extra" en mitad del proyecto.
¿Cómo se estructuran los pagos?
Un reparto habitual y razonable es 50% al empezar y 50% en la entrega, cuando la app ya está publicada y funcionando. En proyectos más largos, es normal dividir en hitos: por ejemplo, diseño aprobado, primera versión funcional y publicación final. Desconfía de quien pide el 100% por adelantado, y también de acuerdos sin ningún pago inicial en proyectos pequeños, porque suele significar que no hay compromiso real con el calendario.
¿Qué pasa si algo se rompe después de publicar?
Pregunta cuánto soporte incluye el precio tras la entrega (30 días es habitual para un proyecto cerrado) y qué ocurre después: ¿hay un plan de mantenimiento mensual, se cobra por incidencia, o simplemente desaparece el contacto? También pregunta cómo te van a avisar si Apple o Google cambian sus requisitos técnicos y tu app necesita una actualización para seguir publicada, algo que pasa con más frecuencia de la que parece.
¿Cómo va a ser la comunicación durante el proyecto?
Pide una respuesta concreta, no un "hablamos por WhatsApp". ¿Vas a ver avances cada semana en tu propio móvil, o solo al final? ¿Hay una persona de contacto fija o rotan según disponibilidad? En proyectos con agencias grandes, pregunta si vas a tratar directamente con quien programa o solo con un gestor de cuenta que traslada mensajes, porque eso afecta a la velocidad con la que se resuelven dudas.
Freelance, agencia o estudio pequeño: qué esperar de cada uno
| Freelance | Agencia grande | Estudio pequeño | |
|---|---|---|---|
| Precio | Más bajo | Más alto | Intermedio |
| Interlocución | Directa, una persona | Gestor de cuenta + equipo | Directa con quien desarrolla |
| Riesgo de disponibilidad | Alto (una persona, una baja o cambio de planes te deja parado) | Bajo | Medio |
| Velocidad de respuesta | Depende de la carga de trabajo | Más lenta, pasa por capas | Rápida |
| Adecuado para | Proyectos pequeños, presupuesto ajustado | Proyectos grandes, con varios equipos implicados | Un punto intermedio: cercanía de freelance con más capacidad que una persona sola |
Ninguna opción es mejor en abstracto. Depende de tu presupuesto, de cuánta gestión quieres hacer tú y de cuánto riesgo asumes si la persona o el equipo no está disponible cuando lo necesitas.
Señales de alarma a las que prestar atención
- No quiere enseñar apps publicadas con su nombre o el de su empresa.
- Se resiste a poner por escrito quién es dueño del código y las cuentas.
- El presupuesto no menciona qué queda fuera de alcance.
- Pide el pago completo por adelantado en un proyecto grande.
- No da un calendario con hitos, solo una fecha final vaga.
- Evita hablar de qué pasa después del lanzamiento.
Preguntas frecuentes
¿Es mejor un freelance o una agencia para mi primera app?
Depende del presupuesto y de cuánta certeza necesitas sobre disponibilidad. Un freelance suele ser más barato pero implica más riesgo si esa persona no está disponible; una agencia da más respaldo pero cuesta más y añade capas de comunicación.
¿Cuánto es razonable pagar por una primera versión de app?
En el mercado español, una primera versión con app, web y backend básico se mueve normalmente entre 3.000 y 15.000 EUR según alcance y quién lo desarrolle. En Fluxer Labs trabajo con un paquete de precio cerrado de 3.000 EUR para app, web y panel de gestión en 4 semanas.
¿Debo firmar un contrato aunque sea un proyecto pequeño?
Sí. No hace falta que sea complejo, pero debe recoger alcance, precio, plazos, forma de pago y a quién pertenecen el código y las cuentas al terminar. Es la mejor protección para ambas partes.
Si quieres ver ejemplos reales de apps publicadas antes de decidir con quién trabajar, puedes revisar proyectos entregados. Y si prefieres resolver dudas concretas sobre tu caso, hablamos sin compromiso.
