Cómo contratar un desarrollador web freelance (sin arrepentirte)

Contratar a un desarrollador es incómodo porque estás comprando algo que no puedes inspeccionar antes de que exista, de alguien cuyo trabajo no puedes juzgar del todo, en un campo donde el vocabulario está diseñado para que asientas sin más. La mayoría de los proyectos de web que salen mal no fallan porque el desarrollador no supiera programar. Fallan porque nadie acordó qué se estaba construyendo, y ambas partes lo descubrieron en la semana cinco.

Llevo ocho años del lado receptor de estas conversaciones, y he visto llegar a clientes cargando los escombros de un intento anterior más veces de las que me gustaría. Esto es lo que le diría a un amigo que me preguntara cómo hacerlo bien.

Decide qué estás comprando en realidad

Antes de hablar con nadie, responde a una pregunta: ¿qué tiene que ser cierto seis meses después del lanzamiento para que haya valido la pena el dinero? No "una web bonita". Cincuenta consultas cualificadas al mes. Veinte pedidos online a la semana. Que tu equipo deje de responder la misma pregunta por teléfono cuarenta veces al día. Un sitio que tu equipo pueda actualizar sin llamar a nadie.

Esto importa porque cambia a quién deberías contratar. Un freelance con fuerte perfil de diseñador es la elección correcta para un sitio de marca donde la estética aporta el valor. Alguien con profundidad en ecommerce es lo correcto para una tienda. Alguien fuerte en SEO técnico es lo correcto si todo el punto es el tráfico orgánico. Son personas genuinamente distintas, y el mejor en la categoría equivocada igual te va a decepcionar.

También te dice qué no necesitas. Muchos negocios piden un desarrollo a medida cuando un sitio de cinco páginas bien ejecutado haría el trabajo, y el dinero estaría mejor invertido en fotografía y un presupuesto de contenido.

Dónde buscar

Referencias de negocios como el tuyo. Sigue siendo, con diferencia, la fuente con mayor tasa de acierto. Pregúntale a alguien cuyo sitio admires quién se lo hizo y si volvería a contratarlo — la segunda mitad de esa pregunta es la que importa.

Marketplaces (Upwork, Fiverr, Malt, Workana). Útiles por el volumen y por la protección de los pagos en depósito. La contrapartida es que estas plataformas premian la velocidad y los precios bajos, así que tendrás que revisar propuestas escritas por un bot en cuatro segundos. Una propuesta que menciona algo específico de tu negocio vale por diez que no lo hacen.

Directorios de plataforma. Shopify Partners, el directorio de Experts de Webflow y programas similares listan gente que realmente ha entregado trabajo en esa plataforma. Grupo más reducido, nivel mínimo más alto.

LinkedIn y redes locales. Más lento, pero es donde encuentras desarrolladores que trabajan en tu idioma y tu zona horaria y pueden sentarse en una reunión cuando importa.

Pide tres presupuestos. No uno, porque no tendrás punto de referencia. No ocho, porque te pasarás un mes comparando y los buenos ya habrán aceptado otro trabajo.

Escribe un brief que dé presupuestos comparables

Aquí está el mecanismo que casi nadie ve: los briefs vagos no producen presupuestos vagos, producen presupuestos incomparables. Si dices "necesito una web para mi clínica", un desarrollador cotiza cinco páginas, otro cotiza doce páginas con sistema de reservas online, y un tercero cotiza una plantilla con tu logo pegado encima. Tres cifras, radicalmente distintas, y ninguna te dice nada sobre los desarrolladores.

Un brief que arregla esto es corto. Una página que cubra:

• A qué se dedica el negocio, en dos líneas, y quién te compra.
• El objetivo, en términos medibles — la pregunta de los seis meses de arriba.
• Una lista de páginas. Aunque sea aproximada. "Home, sobre nosotros, cuatro páginas de servicio, blog, contacto."
• Funcionalidad: formularios, reservas, pagos, membresías, idiomas, integraciones con herramientas que ya pagas.
• Qué existe ya: sitio actual, hosting, dominio, logo, fotografía, textos.
• Qué vas a aportar tú y qué necesitas de ellos. El contenido es la causa más común de retraso, con diferencia.
• Dos o tres sitios que te gustan, y una línea de por qué en cada uno.
• Tu fecha límite, y si es real o aspiracional.

Envía el mismo documento a los tres. Ahora las diferencias entre los presupuestos te dicen algo sobre quién los escribió, en lugar de sobre cuánto adivinó cada uno.

Cómo evaluar un portafolio

No juzgues los portafolios por lo bonitos que son. Júzgalos por la evidencia. Cuatro cosas que hacer, ninguna te llevará mucho tiempo:

Abre los sitios en tu móvil. No las capturas de pantalla — los sitios en vivo. La mayoría de tus visitantes llegarán desde un móvil, y un portafolio lleno de maquetas de escritorio que se desmoronan a 390 píxeles te dice exactamente cuánta atención recibió lo móvil.

Comprueba si siguen en línea. Un portafolio donde la mitad de los enlaces están muertos, aparcados o redirigidos significa que los clientes se fueron o que el trabajo es antiguo. Ambas cosas valen la pena saberlas.

Busca tu tipo de problema, no tu sector. Negocio multisede, catálogo grande, flujo de reservas, dos idiomas, área de membresía — esas son las partes difíciles. Un desarrollador que ya ha resuelto la tuya vale más que uno que resulta que ha construido para otro dentista.

Pregunta qué hizo exactamente. En trabajos de agencia y proyectos de equipo, "yo construí esto" puede significar cualquier cosa. La respuesta a "¿qué parte fue tuya, y qué fue lo difícil?" separa a la gente rápido. Las respuestas reales son concretas y ligeramente poco favorecedoras; las inventadas se quedan suaves y generales.

Nueve preguntas que vale la pena hacer

1. ¿Quién va a hacer el trabajo realmente? Si se lo pasan a un equipo que nunca vas a conocer, deberías saberlo ahora.
2. ¿Qué está incluido, desglosado? Diseño, desarrollo, carga de contenido, formularios, configuración de SEO, formación, configuración de hosting — que quede listado, no implícito.
3. ¿Cuántas rondas de revisión están incluidas, y qué cuenta como una? "Revisiones ilimitadas" es una mentira o un precio pensado para absorber el dolor.
4. ¿Quién es dueño del sitio una vez pagado? El código, el diseño y el contenido deberían ser tuyos.
5. ¿En qué cuentas están el hosting y el dominio? Deberían estar a tu nombre, con tu facturación. Esta es la forma más común, con diferencia, de terminar secuestrado.
6. ¿Podré editarlo yo mismo, y cómo? Pide una demostración sobre un sitio real de otro cliente, no una promesa.
7. ¿Qué pasa después del lanzamiento? Periodo de garantía para errores, opciones de mantenimiento, cuánto cuesta una petición por horas.
8. ¿Qué necesitas de mí, y cuándo? Un desarrollador que ha pensado en tus obligaciones ha llevado proyectos reales.
9. ¿Puedo hablar con un cliente anterior? La reacción importa tanto como la referencia.

Señales de alarma que realmente predicen problemas

Algunas señales de alerta son folclore. Estas son las que yo sí tomaría en cuenta:

Un presupuesto sin alcance adjunto. Una sola cifra y una fecha de inicio, sin nada que describa qué recibes. Todas las disputas que he escuchado se remontan a esto.

Nunca preguntan sobre tu negocio. Si la primera llamada es enteramente sobre páginas, plugins y precio, y nadie pregunta quiénes son tus clientes o cómo es un buen mes, estás comprando construcción sin arquitectura.

Sí a todo. Todo proyecto real tiene compensaciones. Alguien que acepta cada petición, cronograma y presupuesto sin rebatir ni una vez, o no ha entendido el trabajo, o planea renegociar más tarde.

Pago completo por adelantado, o ninguna estructura de pago. Los hitos protegen a ambas partes. Un depósito es normal; el importe completo antes de que exista nada no lo es.

Hosting y dominio a su nombre "por comodidad". Cómodo hasta el momento en que quieres irte.

Respuestas lentas y vagas antes de que hayas pagado nada. Esta es la rapidez máxima que verás jamás. La comunicación no mejora después de la factura.

Rankings número uno garantizados. Nadie puede garantizar eso. Es un indicador fiable de que otras afirmaciones también merecen comprobarse.

Señales buenas que casi nadie nota

Te dicen algo que no querías oír. "No necesitas esta función." "Esa fecha límite no es realista con el contenido que tienes." Que te convenzan de no gastar dinero es la señal más fuerte que vas a recibir.

Preguntan por tu contenido pronto. El contenido es lo que retrasa los proyectos. Alguien que lo plantea en la primera conversación ya se ha quemado antes y aprendió.

Explican las cosas sin jerga ni condescendencia. Entender algo lo suficientemente bien como para explicarlo con sencillez no es una habilidad blanda — es la misma habilidad que produce trabajo mantenible.

Tienen opiniones con razones detrás. "Usaría WordPress aquí, y esta es la razón por la que Webflow te complicaría la vida en el año dos" gana a "lo que tú prefieras".

Planean para después del lanzamiento. Copias de seguridad, actualizaciones, un vídeo de traspaso, a quién llamar cuando algo se rompe. Los desarrolladores que piensan más allá de la fecha de lanzamiento construyen distinto desde antes.

Qué debe llevar el acuerdo

No necesitas un documento legal de veinte páginas. Necesitas un registro escrito de lo que ambos creéis que está pasando, porque en tres meses lo recordaréis de forma distinta. Pon por escrito:

• Los entregables, desglosados — la lista de páginas y la funcionalidad, no "una página web".
• Rondas de revisión incluidas, y la tarifa por trabajo más allá de ellas.
• Calendario de pagos ligado a hitos.
• Cronograma, más qué pasa cuando alguna de las partes causa un retraso. El contenido que llega tarde también es un retraso.
• Propiedad del código, el diseño y el contenido con el pago final.
• Qué cuentas están a tu nombre.
• Una ventana de garantía para corregir errores tras el lanzamiento.
• Una cláusula de salida: cómo detiene cualquiera de las partes el proyecto, y qué se entrega si lo hace.

Un desarrollador que se resiste a poner los entregables por escrito acaba de responder tu pregunta más importante.

Trabajar bien una vez empieza

La mitad del resultado de un proyecto está de tu lado de la mesa, y es la mitad que la gente subestima.

Entrega el contenido de una sola vez, y pronto. Textos, imágenes, logos, accesos. El contenido que llega con cuentagotas es la causa número uno de retraso en todos los proyectos que he llevado, y es el retraso que además degrada la calidad — los diseños pensados alrededor de texto de relleno se reconstruyen alrededor del texto real.

Consolida los comentarios. Un solo documento con los comentarios de todos gana a nueve correos separados, y obliga a tu equipo a resolver sus desacuerdos antes de que lleguen al desarrollador convertidos en contradicciones.

Nombra a un solo responsable de decidir. El diseño por comité produce el promedio de las opiniones de todos, que nunca es la mejor idea de nadie.

Di qué está mal, no qué cambiar. "Esta sección no me hace querer reservar" es más útil que "pon el botón verde". Tú conoces a tus clientes; ellos conocen las soluciones.

Respeta el alcance, o paga por el cambio. Añadir una tienda a mitad de camino no es un favor pequeño, y los proyectos que salen mal suelen ser esos en los que una serie de pequeños favores duplicó el trabajo en silencio.

Preguntas frecuentes

¿Es mejor contratar a un freelance o a una agencia?

Un freelance te da contacto directo con la persona que hace el trabajo, decisiones más rápidas y menos gastos generales, lo que encaja con la mayoría de proyectos pequeños y medianos. Una agencia te da un equipo, redundancia si alguien se va, y capacidad para trabajo grande y multidisciplinar. La pregunta real no es freelance contra agencia — es si la persona con la que hablas es la persona que construye. En muchas agencias, no lo es.

¿Debería contratar a un desarrollador especializado en mi sector?

Ayuda, pero rara vez es decisivo. Importa más en sectores regulados como salud o legal, donde las restricciones son reales. Por debajo de eso, un desarrollador que ya ha resuelto tu tipo de problema — reservas, catálogo, multisede, multilingüe — es más útil que uno que resulta haber trabajado en tu sector.

¿Qué debe incluir un contrato de desarrollo web?

Entregables, rondas de revisión, calendario de pagos, cronograma con manejo de retrasos, propiedad del código y el diseño, a nombre de quién están el hosting y el dominio, y cómo sale cada parte del acuerdo. Consulta la sección de arriba para la lista completa.

¿Cómo sé si el portafolio de un desarrollador es realmente su trabajo?

Pregunta qué hizo exactamente en dos o tres proyectos. Alguien que construyó un sitio puede contarte qué fue difícil, qué cambió el cliente a mitad de camino, y qué haría distinto ahora. Alguien que no lo hizo se queda en lo vago. De paso, comprueba que los sitios sigan en línea.

La versión corta

Sabe cómo es el éxito antes de pedir precios. Escribe una página y envíasela a tres personas. Juzga los portafolios por evidencia, no por estética. Deja el alcance por escrito. Conserva tus propias cuentas. Entrega tu contenido pronto. Y decántate por la persona que te dijo algo que no querías oír — en ocho años, esa es la señal que mejor ha correlacionado con los proyectos que salieron bien.