Contratar desarrollador full stack freelance: qué preguntar

Contratar desarrollador full stack freelance sale bien cuando las preguntas se hacen antes de empezar: alcance, propiedad del código, mantenimiento, comunicación y qué pasa si algo sale mal. Este artículo reúne las siete preguntas que conviene hacer, con sus señales de alarma y una lista para preparar tu proyecto.

Dos aclaraciones antes de la lista. Un full stack no tiene por qué ser especialista en todo, y no existe una tarifa de referencia universal: dos proyectos que parecen iguales rara vez cuestan lo mismo. Lo que sí se puede comparar es la calidad de las respuestas.

Qué es (y qué no es) un desarrollador full stack

Un desarrollador full stack diseña, desarrolla y despliega soluciones completas: desde la experiencia de usuario hasta la infraestructura backend, pasando por la gestión y el análisis de datos. Esa es la definición útil a la hora de contratar: un full stack responde del conjunto, no de una sola capa.

Esa amplitud tiene un límite honesto: full stack no significa experto en todo. Significa llevar un proyecto de punta a punta, sabiendo cuándo profundizar y cuándo traer a un especialista. Aplicaciones web, sistemas internos, integraciones entre servicios o automatización de procesos suelen encajar en ese perfil.

La primera pregunta no es técnica, sino de encaje: ¿tu proyecto necesita a alguien que resuelva el conjunto, o a un especialista en una pieza? Una aplicación completa, un sistema interno o una plataforma que integra varios servicios encajan con un full stack. Pedirle que sea el mejor en cada capa es tan injusto como pedirle a un especialista que resuelva lo demás.

Contratar desarrollador full stack: siete preguntas que deciden el proyecto

Estas preguntas sirven para cualquier cliente y cualquier freelance. Si las haces antes de firmar, la mayoría de los malentendidos desaparecen. Van en el orden en que conviene plantearlas.

1. ¿Qué entra en el alcance y qué queda fuera?

El alcance es la lista cerrada de lo que se entrega: funcionalidades, pantallas, integraciones y contenido. Pide que quede por escrito, con sus límites: "panel con gestión de usuarios y pedidos" dice algo; "una web completa" no dice nada. Lo que quede fuera debe nombrarse también, para que nadie lo dé por supuesto.

Pregunta además cómo se factura: con precio fijo sobre un alcance definido o con tarifa por hora o mes para proyectos evolutivos. Y pide criterios de aceptación desde el inicio: cómo se decide, en cada hito, que algo está terminado.

2. ¿De quién es el código y quién tiene los accesos?

La respuesta correcta es corta: tuyo y tú. Al finalizar deberías recibir el código fuente completo, la documentación técnica, las guías de despliegue, las credenciales de acceso y la transferencia completa de la propiedad intelectual. Todo queda en tus manos, y es la respuesta que conviene exigir a cualquiera.

Matiza dos puntos. Primero, el cuándo: pide un repositorio compartido desde el primer día y despliegues en cuentas a tu nombre. Segundo, las licencias: plantillas, librerías de pago o servicios de terceros tienen sus propias condiciones y suscripciones. Pregunta qué piezas son tuyas y cuáles son alquiladas.

3. ¿Qué pasa después del lanzamiento?

Todo software necesita mantenimiento: actualizaciones de seguridad, corrección de errores, optimizaciones y, tarde o temprano, nuevas funcionalidades. Pregunta si el freelance ofrece planes de mantenimiento y qué incluyen. Un mantenimiento web serio define los términos según el proyecto: tiempos de respuesta, qué entra en la cuota y qué se factura aparte.

Desconfía de dos extremos: quien entrega y desaparece sin explicar cómo mantener lo construido, y quien te ata a una cuota obligatoria sin la cual nada funciona. El punto sano es un proyecto que otro profesional podría mantener gracias a su documentación, con la opción de seguir con quien lo construyó. Pregunta también por la garantía inicial y qué fallos cubre.

4. ¿Cómo nos comunicamos y con qué ritmo?

Pide un ritmo concreto: actualizaciones semanales por escrito funcionan bien en la mayoría de los proyectos, con reuniones de seguimiento cuando el momento lo pide. Pregunta qué herramientas muestran el progreso (tableros donde puedas comprobar el avance sin preguntar) y en qué horario se responde. Si el freelance trabaja en remoto desde otro país, confirma cómo se solapan las jornadas.

La comunicación es también una prueba temprana. Si tarda días en responder antes de firmar, tardará lo mismo después. Valora la claridad por encima de la rapidez: una actualización semanal que explica decisiones vale más que mensajes diarios que no dicen nada.

5. ¿Cómo se prueba y cómo se entrega?

Pregunta por las pruebas antes de hablar de fechas. Un trabajo serio incluye varios niveles: pruebas unitarias, pruebas de integración entre piezas, pruebas de extremo a extremo que simulan a un usuario real, revisiones de rendimiento y accesibilidad, además de pruebas manuales. Basta con oír que existen y que forman parte del proceso, no de un extra opcional.

Pregunta también por la entrega: desarrollo iterativo con entregas frecuentes que puedas ver y probar, o una única entrega final. Conviene lo primero: ver avances cada poco tiempo permite corregir cuando corregir es barato. Y confirma que el despliegue incluye monitorización.

6. ¿Qué ocurre si cambia el alcance?

Cambiará. Todo proyecto descubre a mitad de camino algo que nadie vio al principio, y eso no es un fracaso: es información nueva. Lo que distingue a un buen freelance es tener un procedimiento: el cambio se describe por escrito, se estima su coste en tiempo y dinero, y se aprueba antes de ejecutarse.

Lo que conviene temer es lo contrario: cambios hechos «de favor» sin registrar, que luego aparecen en la factura o retrasan la entrega. Un modelo de pagos por hitos ayuda aquí: cada hito tiene sus entregables acordados, y lo que entra después se valora aparte. Pregunta también por el caso inverso: si recortas alcance, ¿baja el precio?

7. ¿Qué pasa si desapareces a mitad del proyecto?

Es la pregunta incómoda y la más importante. La gente desaparece por motivos normales (enfermedad, otro proyecto, pérdida de interés), y el proyecto debe sobrevivir a eso. La protección no es la confianza, es la estructura: repositorio compartido desde el primer día, cuentas y accesos a tu nombre, documentación al día y entregas frecuentes.

Pregunta además por lo formal: contrato claro que proteja a ambas partes, criterios de aceptación desde el inicio y rondas de revisión en cada hito. Y si vas a compartir información sensible antes de firmar, pide un acuerdo de confidencialidad. Quien se ofende ante esta pregunta te está dando información valiosa sobre cómo gestiona los desacuerdos.

Señales de alarma en una propuesta freelance

Cinco señales piden parar antes de firmar. El alcance vago: presupuestos de una línea para proyectos de meses. La ausencia de preguntas: quien acepta tu briefing sin cuestionar nada no lo ha entendido; espera preguntas incómodas sobre objetivos y prioridades. El pago íntegro por adelantado sin hitos: los pagos por hitos protegen a ambas partes. La prisa artificial: «este precio solo vale esta semana». Y el silencio sobre mantenimiento y propiedad del código.

Ninguna señal condena a nadie para siempre; todas piden una conversación antes de seguir. Si las respuestas te dejan intranquilo, sigue buscando. Contratar programador es una decisión reversible al principio y carísima a la mitad.

Cómo evaluar el portafolio de un candidato

El portafolio es donde verificas lo que la conversación prometió. No mires solo las capturas: lee cómo se cuenta cada proyecto. Un buen proyecto explica el problema, las decisiones tomadas y los trade-offs aceptados; uno flojo solo muestra imágenes bonitas. Fíjate también en la variedad: ¿ha resuelto problemas parecidos al tuyo?

La guía sobre el portafolio de desarrollador web explica qué busca quien contrata al abrir uno: claridad de perfil, prueba real, proceso y camino a contactar. Si el portafolio de un candidato es confuso, sus proyectos suelen llevar el mismo sello.

Para practicar esa lectura, dos proyectos del Portfolio sirven de ejemplo: Flores Inc — Plataforma E-commerce Headless y Boost Studio — Marketing SPA. Léelos con ojo crítico, como si evaluaras a un desconocido. Y en cualquier portafolio, desconfía de los testimonios o las cifras que no se pueden verificar: si no hay forma de comprobarlos, lo honesto es omitirlos.

Cómo preparar tu proyecto antes de contactar

Antes de escribir a un freelance, reúne la información que permite una primera valoración honesta:

• Objetivos: qué debe conseguir el proyecto, en una frase.
• Público: a quién va dirigido y desde qué dispositivos lo usará.
• Funcionalidades principales: las cinco o seis que no pueden faltar, y cuáles son deseables.
• Referencias visuales: webs que te gusten y las que no, aunque sea solo para decir por qué.
• Plazos: la fecha que necesitas y la que sería razonable.
• Presupuesto aproximado: un rango, aunque sea amplio. Ayuda a proponer alcances realistas.

Con eso se puede programar una reunión de descubrimiento para profundizar en los detalles técnicos. Un proceso sano suele combinar análisis de requisitos, un diseño de arquitectura con su planificación, entregas iterativas y frecuentes, pruebas continuas, despliegue con monitorización y soporte tras el lanzamiento. Un proyecto razonable suele ir de unas semanas a varios meses, siempre que el alcance esté bien definido y las expectativas coincidan.

Y si tu proyecto necesita automatizar parte de su operación, lee antes la guía sobre automatización de procesos con APIs: qué automatizar primero y cuándo no automatizar nada. Muchos encargos empiezan como «una web» y resultan ser «una integración»; distinguirlo pronto ahorra meses.

Qué poner en tu primer correo

El primer correo no necesita ser largo: qué quieres lograr, para quién, qué debería hacer el proyecto en sus líneas esenciales, cuándo lo necesitas y qué presupuesto manejas. Con eso se puede saber si el encaje es razonable y qué propuesta tendría sentido. Si prefieres una llamada de descubrimiento, pídela directamente.

Contratar desarrollador full stack es, al final, una decisión de confianza informada: verificas el criterio con las siete preguntas, confirmas la prueba en el portafolio y empiezas con un alcance que ambas partes entienden. Si este artículo te sirve para contratar a cualquier profesional, ya cumple su función.

Si quieres que ese proyecto lo hablemos, escríbeme desde la página de contacto: cuéntame tu caso en unas líneas y te respondo con una primera valoración honesta, incluido un no cuando crea que no soy la persona indicada.