Contratar una agencia de desarrollo web siendo el cliente no técnico es una posición incómoda. No sabes si lo que te están entregando es bueno o mediocre, no entiendes los argumentos técnicos cuando hay retrasos y no tienes forma de verificar si el precio que pagas es razonable.
La buena noticia es que supervisar un proyecto de desarrollo web no requiere saber programar. Requiere saber qué preguntar, cuándo preguntar y qué señales indican que algo va mal.
Por qué el cliente también tiene responsabilidad en los proyectos fallidos
Es fácil culpar a la agencia cuando un proyecto sale mal. A veces la culpa es suya, pero con más frecuencia de lo que parece, el problema viene del lado del cliente.
Los errores más comunes del lado del cliente:
- Briefing incompleto o cambiante. Pedir una cosa, aprobar el diseño y luego cambiar de idea a mitad del desarrollo es la causa más frecuente de retrasos y sobrecostes.
- No tener interlocutor dedicado. Si la agencia tiene que hablar con tres personas distintas para cualquier aprobación, el proyecto se para constantemente.
- Aprobar sin revisar. Firmar cada entregable sin revisarlo de verdad y luego reclamar cambios cuando ya está terminado.
- No proporcionar el contenido a tiempo. Textos, imágenes, logos, datos... la agencia no puede avanzar si no tiene los materiales del cliente.
Antes de empezar: qué debe incluir un buen briefing técnico
El briefing es el documento que define qué se va a construir. Cuanto más completo sea, menos margen hay para malentendidos y sorpresas.
Un briefing técnico para desarrollo web debe incluir como mínimo:
Sobre el proyecto:
- Objetivo claro del sitio o aplicación: para qué sirve, quién lo va a usar y qué acción quieres que realice el usuario
- Funcionalidades obligatorias (las que deben estar en el lanzamiento) vs. deseables (las que pueden esperar)
- Referencias visuales: ejemplos de otros sitios que te gusten y, sobre todo, que no te gusten
Sobre los requisitos técnicos:
- ¿Necesitas integración con algún sistema existente? CRM, ERP, pasarela de pago, herramienta de email marketing...
- ¿Quién va a mantener el sitio después del lanzamiento? Si no hay perfil técnico interno, el CMS elegido importa mucho.
- ¿Tienes requisitos de seguridad o privacidad específicos? Sector sanitario, financiero, datos de menores...
Sobre la entrega:
- Fecha de lanzamiento objetivo y si hay algún evento o campaña asociada
- Presupuesto disponible (un rango real, no un "dinos tú cuánto cuesta")
- Qué ocurre con el código al terminar: ¿queda en un repositorio de tu propiedad?
Durante el proyecto: las preguntas que deberías hacer en cada reunión
No hace falta entender el código para hacer las preguntas correctas. En cada reunión de seguimiento, estas preguntas te dan información real sobre el estado del proyecto:
Sobre el avance:
- "¿Qué estaba previsto terminar esta semana y qué se ha terminado realmente?". Si la respuesta siempre difiere de lo previsto, hay un problema de planificación o de ejecución.
- "¿Hay algo que necesitáis de nuestra parte para poder avanzar?". Elimina los bloqueos del lado del cliente antes de que se conviertan en retrasos.
Sobre decisiones técnicas:
- "¿Se ha tomado alguna decisión técnica esta semana que afecte al presupuesto o al plazo?". Las agencias a veces toman decisiones que tienen impacto en el coste sin comunicarlo de forma proactiva.
- "¿Podemos ver lo que está desarrollado hasta ahora en un entorno de pruebas?". Todo proyecto profesional debe tener un entorno de preproducción accesible al cliente en todo momento, no solo al final.
Sobre riesgos:
- "¿Hay algo que os preocupe que pueda afectar al plazo de entrega?". Preguntarlo directamente es más efectivo que esperar a que lo digan por iniciativa propia.
Al recibir el trabajo: qué revisar antes de dar el visto bueno
Dar el visto bueno final sin una revisión seria es uno de los errores más comunes. Una vez que se cierra el contrato, cualquier cambio es trabajo extra de pago.
Lista de verificación básica para un proyecto web:
Funcional:
- Prueba cada funcionalidad en los dispositivos y navegadores principales (Chrome, Safari, Firefox; escritorio y móvil)
- Completa los formularios de principio a fin y verifica que los datos llegan donde deben
- Simula el proceso completo que hará un usuario real: desde la página de inicio hasta la conversión
Técnico (aunque no seas técnico):
- Ejecuta el sitio en PageSpeed Insights: una puntuación por debajo de 70 en móvil es una señal de alerta
- Comprueba que el sitio tiene HTTPS activo y el certificado SSL configurado correctamente
- Verifica que el sitio aparece correctamente en Google Search Console y que no hay errores de indexación
Entregables:
- Credenciales de acceso a todos los sistemas: hosting, dominio, CMS, herramientas de analytics
- Acceso al repositorio de código
- Documentación básica de cómo realizar las tareas más comunes (publicar una entrada, actualizar un precio, añadir una imagen)
Las señales de alarma que indican que algo va mal
Reconocer estas señales a tiempo puede ahorrarte meses de frustración y miles de euros:
- Las demos siempre son "en local" y nunca hay un entorno accesible para el cliente. Si no puedes ver el avance en tiempo real, algo se está ocultando.
- Los plazos se mueven sin explicación clara. Un retraso puede ser inevitable; un patrón de retrasos sin causa identificada es un problema de gestión o de capacidad.
- Las preguntas técnicas generan respuestas evasivas. Una agencia profesional puede explicar sus decisiones técnicas en términos comprensibles para el cliente.
- Cambios de interlocutor frecuentes. Si cada mes hablas con una persona diferente de la agencia, hay un problema de organización interna que afectará a la continuidad del proyecto.
- Resistencia a entregar las credenciales y el código. El código y el dominio son tuyos. Cualquier reticencia a transferirlos es inaceptable.
Qué hacer si el proyecto ya va mal
Si estás a mitad de proyecto y reconoces varias señales de alarma, estos son los pasos que funcionan antes de romper la relación con la agencia:
- Pide una reunión formal con acta. Plantea todas las preocupaciones por escrito. Muchas agencias reaccionan bien cuando ven que el cliente está tomando notas y que hay trazabilidad.
- Solicita acceso completo al repositorio de código, hosting y dominio si aún no lo tienes. Es un derecho y una garantía.
- Contrata una segunda opinión técnica. Una consultoría puntual de 500-2.000 € puede auditar el estado real del proyecto y darte munición objetiva para las siguientes conversaciones.
- Plantea un cierre por fases. Si la relación es insalvable, evita el "borrón y cuenta nueva". Acuerda un paquete mínimo viable que se pueda entregar y cerrar, y la transición del código a otro proveedor.
- Documenta todo. Emails, decisiones, plazos prometidos. Si hay que ir a una reclamación o un procedimiento, la documentación es lo que decide.
Preguntas de clientes sin perfil técnico
¿Cuánto debería durar un proyecto de desarrollo web para una PYME?
Depende del alcance. Una web corporativa estándar: 6-12 semanas. Un ecommerce con catálogo medio: 3-5 meses. Una aplicación a medida: desde 3 meses hasta un año según complejidad. Si la agencia te promete una web corporativa en 2 semanas, probablemente están usando una plantilla sin personalización real.
¿Qué presupuesto es razonable para una web corporativa?
Para una PYME española en 2026: 3.000-8.000 € una web corporativa simple, 8.000-20.000 € con funcionalidades personalizadas, 20.000-60.000 € un ecommerce completo. Presupuestos muy por debajo de esos rangos suelen indicar plantilla sin personalización o partidas ocultas que aparecen después.
¿Quién tiene la propiedad del código cuando el proyecto termina?
Por defecto, el cliente. Salvo que el contrato diga otra cosa (y si lo dice, no deberías firmarlo). Asegúrate de que el contrato incluye explícitamente la cesión de derechos de propiedad intelectual del código desarrollado a medida.
¿Debería pagar por adelantado?
Un 30-50 % al inicio es estándar. Pagar el 100 % por adelantado es mala idea casi siempre. Acuerda pagos por hitos: inicio, entrega de diseño aprobado, entrega de desarrollo, cierre.
¿Qué pasa si la agencia me entrega WordPress y yo quería algo a medida?
Depende de qué dice el contrato. WordPress puede ser perfectamente válido para muchos proyectos corporativos. El problema aparece cuando el cliente espera un desarrollo a medida y la agencia entrega una plantilla con ajustes. Por eso el briefing técnico inicial es tan importante.
¿Cómo sé si el precio que me están cobrando es justo?
Pidiendo al menos tres presupuestos con el mismo briefing. Si uno está muy por encima de los otros dos, que justifique el porqué. Si uno está muy por debajo, desconfía. Un CTO externalizado puede evaluar ofertas sin sesgos comerciales en menos de una semana.
¿Necesito un contrato o basta con un presupuesto firmado?
Necesitas un contrato. El presupuesto describe el alcance y el precio; el contrato regula plazos, incumplimientos, propiedad del código, confidencialidad y qué pasa si alguna de las partes quiere cancelar. Sin contrato, cada conflicto se resuelve por buena voluntad.
¿Puedo hacer una web yo mismo y evitarme la agencia?
Para negocios muy simples o fases muy iniciales, con herramientas como Webflow, Framer o WordPress + constructor visual, sí. Pero contar horas: si tardas 80 horas de tu tiempo (a 40-60 €/h reales) en hacer una web que una agencia te cobra 4.000 €, probablemente no has ganado. La pregunta no es si puedes, sino si es el mejor uso de tu tiempo.
Gestionar un proyecto de desarrollo web con una agencia externa no requiere saber programar, pero sí método y claridad sobre qué exigir en cada momento. Si estás a punto de arrancar o llevas tiempo perdido en uno en curso, asesoría técnica actúa como tu representante técnico independiente: alguien que habla el mismo idioma que la agencia y defiende tus intereses en las reuniones clave. Para ampliar, CTO externalizado: qué es y cuándo lo necesita tu empresa explica el rol, y cuándo tiene sentido externalizar la tecnología ayuda a decidir si el modelo encaja con tu caso.