Cuando alguien me pregunta cómo elegir un desarrollador web, lo que en realidad está preguntando es: ¿cómo sé si esta persona va a entregar algo que funcione de verdad, o solo va a parecer que sí hasta que sea demasiado tarde para rectificar?
Llevo años en este sector, primero como cliente que contrató mal, después como desarrollador. Y lo que más me ha enseñado no son los proyectos que salieron bien, sino los que empezaron con todas las señales de alarma ignoradas.
Estas siete preguntas no son un test de conocimientos técnicos. Son criterios para evaluar si alguien entiende tu negocio, trabaja con rigor y puede mantenerse como interlocutor válido a lo largo del tiempo.
¿Tiene proyectos similares al mío en su portfolio?
El portfolio no es una galería de diseños bonitos. Es evidencia de que alguien ha resuelto antes el tipo de problema que tú tienes ahora.
Un desarrollador que ha hecho veinte webs corporativas sencillas no tiene la misma experiencia que alguien que ha construido tiendas con gestión de stock, membresías con acceso por niveles o escuelas online con seguimiento de progreso. Son tipos de proyecto distintos, con complejidades distintas.
Lo que tienes que buscar:
- URLs activas, no solo capturas de pantalla. Un proyecto real en producción es verificable. Una captura no lo es.
- Proyectos de tipo similar al tuyo. Si necesitas una tienda, el portfolio debería incluir tiendas. Si necesitas una membresía, busca membresías.
- Proyectos recientes. El stack tecnológico cambia. Alguien que solo muestra proyectos de hace cinco años puede estar trabajando con herramientas o enfoques obsoletos.
Si el portfolio no tiene nada parecido a lo que necesitas, no es una señal automática de descarte, pero sí requiere que la conversación incluya cómo tiene previsto abordar los aspectos que no ha resuelto antes.
¿Cómo es su proceso de trabajo?
Esta pregunta revela mucho más que las respuestas técnicas. Un desarrollador que trabaja con rigor tiene un proceso claro: cómo recoge los requisitos, cómo gestiona los cambios durante el proyecto, cómo entrega y qué pasa después.
Señales de que el proceso está pensado:
- Hay una fase de análisis antes de empezar a diseñar o desarrollar.
- Los cambios de alcance tienen un procedimiento definido (no se acumulan sin control).
- La entrega incluye formación básica sobre el CMS o el panel de administración.
- Existe documentación mínima sobre qué hay instalado, qué licencias se usan y cómo funciona el mantenimiento.
Señales de que no:
- El proceso se reduce a "me dices lo que quieres y te lo hago".
- No hay ninguna mención a cómo se gestionan los imprevistos o los cambios de requisitos.
- La entrega es simplemente "te mando el acceso cuando esté listo".
Un buen proceso no garantiza un buen resultado, pero la ausencia de proceso casi siempre garantiza problemas.
¿Qué resultados de rendimiento tienen sus proyectos?
Velocidad de carga, Core Web Vitals, comportamiento en móvil. Esto no es un capricho técnico: Google lo usa como factor de posicionamiento y los usuarios abandonan páginas que tardan más de tres segundos en cargar.
Pide que te enseñe los resultados de PageSpeed Insights de algún proyecto suyo en producción. No hace falta que sean perfectos, pero deberían estar por encima de 80 en Performance en móvil como mínimo razonable. Por debajo de 60 es una señal seria de que no se está priorizando la calidad técnica.
Si el desarrollador no sabe qué es PageSpeed Insights, o lo conoce pero no tiene datos de sus proyectos, eso también te dice algo importante.
El rendimiento no se añade al final del proyecto. Se construye desde el principio: eligiendo bien el stack, no cargando librerías innecesarias, optimizando imágenes, usando caché correctamente. Un desarrollador que piensa en rendimiento lo hace por defecto, no como extra.
¿El código será mío y podré cambiarlo si necesito?
Esta pregunta tiene implicaciones prácticas muy concretas. Hay situaciones en las que el cliente recibe una web que técnicamente funciona, pero que en la práctica está atada al desarrollador que la hizo:
- Licencias de plugins o temas que están a nombre del desarrollador y no son transferibles.
- Plantillas o constructores propietarios que hacen imposible que otro profesional continúe el trabajo.
- Código personalizado sin documentar que nadie más puede mantener.
- Accesos al hosting o al dominio que el desarrollador retiene como forma de retener al cliente.
Lo que debes exigir al finalizar un proyecto:
- Acceso completo al panel de hosting, al panel de administración del CMS y al registro de dominio.
- Licencias de herramientas premium a tu nombre o transferibles.
- Código fuente si se ha desarrollado algo personalizado.
- Documentación básica de qué hay instalado y por qué.
Si hay resistencia a cualquiera de estos puntos antes de empezar el proyecto, es mejor saberlo ahora.
¿Qué pasa con la web después de la entrega?
Una web no es un producto que se entrega y se olvida. WordPress actualiza su core, los plugins actualizan sus versiones, aparecen vulnerabilidades de seguridad, el servidor puede tener problemas. Si nadie está mirando, los problemas se acumulan en silencio hasta que algo falla de forma visible.
Pregunta específicamente:
- ¿Ofrece algún plan de mantenimiento mensual o puedo contratarlo con otra empresa sin problemas?
- ¿Qué incluye el período de garantía después de la entrega y cuánto dura?
- Si después de seis meses necesito un cambio puntual, ¿cómo lo gestionamos y a qué coste?
Un desarrollador que piensa en el largo plazo tiene respuestas a estas preguntas. Alguien que solo piensa en cerrar el proyecto las esquiva o las deja en el aire.
¿Cómo vas a comunicarte conmigo durante el proyecto?
Los proyectos que salen mal casi siempre tienen un problema de comunicación en su raíz. No es que el desarrollador fuera incompetente, es que el cliente no sabía en qué punto estaba el proyecto, los cambios de requisitos no se gestionaron bien o los problemas se comunicaron demasiado tarde.
Lo que conviene establecer antes de empezar:
- Frecuencia de actualizaciones. ¿Cada cuánto tiempo recibirás información sobre el estado del proyecto?
- Canal de comunicación. ¿Email, mensajería, videollamada? ¿Cuál es el tiempo de respuesta esperado?
- Gestión de cambios. Si durante el proyecto decides añadir algo que no estaba en el presupuesto inicial, ¿cómo se documenta y se presupuesta ese cambio?
- Acceso a avances. ¿Puedes ver el proyecto en un entorno de staging antes de la entrega final?
Un entorno de staging, donde puedes revisar el trabajo en progreso sin que afecte a la web en producción, es una práctica estándar en proyectos profesionales. Si el desarrollador no trabaja con staging, es una señal de que el proceso de entrega puede ser más arriesgado de lo necesario.
¿Puedo hablar con algún cliente anterior?
Las referencias son la única forma de verificar que lo que cuenta un desarrollador sobre sí mismo coincide con la experiencia real de trabajar con él.
No se trata de hacer una investigación policial. Es una conversación de diez minutos con alguien que ha pasado por el proceso que tú vas a iniciar. Las cosas que vale la pena preguntar a esa persona:
- ¿Se cumplieron los plazos acordados?
- ¿Hubo sorpresas en el presupuesto final respecto al inicial?
- ¿Cómo fue la comunicación durante el proyecto?
- Si tuvieras que repetir el proceso, ¿volvería a contratar a esta persona?
Un desarrollador que trabaja bien no tiene problema en facilitar estas referencias. Quien las esquiva o pone obstáculos para conseguirlas probablemente tiene algo que ocultar o simplemente no tiene clientes que puedan hablar bien de él.
Señales de alarma que no deberías ignorar
Más allá de las siete preguntas, hay actitudes y situaciones que en mi experiencia suelen preceder a proyectos problemáticos:
- Presupuesto sin desglose. Un precio global sin especificar qué incluye y qué no es una invitación a malentendidos futuros.
- Promesas de entrega muy ajustadas sin justificación. Una web corporativa completa en una semana es técnicamente posible con plantilla. No lo es si el trabajo es real.
- Resistencia a firmar un contrato. Trabajar sin documento escrito protege al desarrollador, no a ti.
- No hacer preguntas sobre tu negocio. Si el desarrollador no te pregunta qué haces, quién es tu cliente o cuál es el objetivo de la web, está construyendo algo genérico, no algo para ti.
- Precio significativamente por debajo del mercado. Puede ser plantilla, puede ser trabajo delegado a terceros, puede ser experiencia insuficiente. Casi nunca es simplemente eficiencia.
La pregunta que más importa, en realidad
Después de todo lo anterior, hay una pregunta que engloba a las demás: ¿esta persona entiende lo que quiero conseguir con esta web, o solo entiende lo que quiero que la web tenga?
Un desarrollador que piensa en objetivos de negocio, no solo en funcionalidades, va a tomar mejores decisiones a lo largo de todo el proyecto. Cuando hay que elegir entre dos formas de implementar algo, quien conoce tu contexto elegirá la que tiene más sentido para ti. Quien no lo conoce elegirá la más rápida o la más familiar.
Esta diferencia no se ve en el presupuesto inicial. Se ve en el resultado.
Si estás evaluando opciones: puedo contarte cómo trabajo, qué tipo de proyectos he resuelto antes y qué incluye exactamente cada presupuesto. Sin compromiso y sin argumentos de venta.
Escríbeme directamente o revisa primero cómo enfoco el desarrollo web.
Preguntas frecuentes
Depende del proyecto y de cómo quieres trabajar. Un freelance especializado suele ofrecer más implicación directa, comunicación más ágil y mejor relación calidad-precio para proyectos de tamaño medio. Una agencia tiene más recursos para proyectos grandes o con múltiples disciplinas simultáneas (diseño, copy, desarrollo, campañas), pero también más capas de gestión y costes estructurales que se trasladan al presupuesto. La clave es que quien gestiona tu proyecto también sepa desarrollar, o al menos entienda lo que está coordinando.
No hay un número mínimo, pero sí criterios cualitativos. Busca 3-5 proyectos que sean similares al tuyo en tipo y complejidad. Si contratas para una tienda online, el portfolio debería incluir al menos una tienda en funcionamiento. Si es para una escuela online o una membresía, busca proyectos con área de clientes o gestión de accesos. El número importa menos que la relevancia y que los proyectos sean verificables (con URL activa, no solo capturas).
No es imprescindible que sea especialista, pero sí que entienda los fundamentos técnicos: estructura de URLs, velocidad de carga, etiquetas semánticas, datos estructurados básicos. Un desarrollador que entrega una web con tiempos de carga de 6 segundos en móvil o sin jerarquía de encabezados te está poniendo en desventaja desde el primer día. La optimización de contenidos es otra disciplina, pero la base técnica es responsabilidad del desarrollo.
Es un riesgo real, especialmente con freelances sin trayectoria verificable. Para mitigarlo: asegúrate de que el contrato incluya la entrega de accesos completos (hosting, dominio, panel de administración), que el código sea tuyo y no dependa de licencias personales del desarrollador, y que la documentación básica esté incluida. Pregunta también si trabaja con algún plan de mantenimiento posterior: alguien que piensa en el largo plazo suele ser más riguroso en la entrega.
El precio por sí solo no dice nada. Lo que necesitas evaluar es qué incluye: horas estimadas de trabajo, qué herramientas se usan, qué queda fuera del presupuesto (hosting, licencias, copywriting), y cuál es el proceso de revisiones y cambios. Un presupuesto bajo puede ser una señal de plantilla, trabajo delegado o deuda técnica que pagarás después. Un presupuesto alto sin desglose claro tampoco es garantía de nada. Para tener una referencia de rangos reales, puedes leer cuánto cuesta una web profesional.