Errores comunes al contratar un programador web (y cómo evitarlos)

He visto cientos de proyectos web a lo largo de 33 años. Muchos exitosos, pero también muchos desastres evitables.

¿El patrón común en los fracasos? Errores al contratar al programador web.

En este artículo, compartiré los 12 errores más costosos que veo una y otra vez, por qué ocurren, y cómo puedes evitarlos para asegurar que tu proyecto sea un éxito.

Error #1: Elegir por precio, no por valor

El error

Contratar al programador web más barato disponible.

Caso real que he visto demasiadas veces:

Cliente contrata por 800€ una web corporativa. Recibe:

• Plantilla WordPress gratuita sin personalizar
• Código sin tests
• Sin documentación
• Bugs en formularios
• SEO inexistente
• Desarrollador desaparece después del pago

Dos meses después, me contactan. Necesitan rehacerla desde cero: 8.000-12.000€.

Coste total: 800€ + 10.000€ = 10.800€ Si hubieran contratado calidad desde inicio: 8.000€

Pérdida: 2.800€ + 2 meses de oportunidad perdida

Por qué ocurre

• Presupuesto limitado lleva a buscar lo más barato
• No entienden diferencias de calidad entre opciones
• Asumen que "programador = programador"
• Optimizan por coste inmediato, no coste total

Cómo evitarlo

Pregúntate:

• ¿Por qué este profesional cobra tan poco?
• ¿Qué garantías ofrece?
• ¿Tiene portfolio demostrable?
• ¿Referencias verificables?

Red flags de precio:

• Web completa profesional <2.000€
• Ecommerce completo <5.000€
• Plataforma SaaS <15.000€

Si parece demasiado barato para ser verdad, probablemente lo sea.

Mejor enfoque:

• Define presupuesto realista para tu proyecto
• Compara 3-5 opciones en ese rango
• Evalúa calidad, no solo precio
• Invierte en calidad desde el inicio

Como programador web senior con 33 años experiencia, mi tarifa de 400€/día no es la más barata. Pero mis clientes ahorran dinero a largo plazo con código de calidad, TDD obligatorio y garantía de por vida.

Error #2: No verificar portfolio y referencias

El error

Confiar solo en lo que el programador dice, sin validar trabajo previo.

Caso real:

Candidato afirma:

• "10 años de experiencia"
• "Experto en React y Next.js"
• "He desarrollado 50+ proyectos"

Cliente contrata sin pedir portfolio. Resultado:

• Código era jQuery de 2015, no React moderno
• No conocía Next.js en absoluto
• "Proyectos" eran tutoriales de YouTube

Dinero perdido: 6.000€ en 3 semanas de trabajo inservible.

Por qué ocurre

• Urgencia por empezar rápido
• Buenas habilidades de venta del candidato
• Cliente no técnico no sabe qué preguntar
• Incomodidad al pedir referencias

Cómo evitarlo

SIEMPRE solicita:

1. Portfolio con URLs reales

   • Proyectos en producción funcionando
   • No solo screenshots manipulables

2. Código visible (si es posible)

   • GitHub público
   • O muestras con NDAs respetadas

3. Referencias de 2-3 clientes anteriores

   • Con datos de contacto reales
   • Llama personalmente, no solo email

4. Casos de estudio

   • Problema → Solución → Resultados
   • Con métricas tangibles

Preguntas para referencias:

• ¿El proyecto se entregó a tiempo?
• ¿El presupuesto se respetó?
• ¿El código necesitó rehacer después?
• ¿Cómo fue la comunicación?
• ¿Lo contratarías de nuevo?
• ¿Qué mejorarías?

Red flags:

• "Todos mis proyectos son confidenciales"
• No puede mostrar ningún código
• Referencias vagas sin contacto
• Portafolio solo con diseños, no código

En mi caso, tengo portfolio visible con proyectos reales y referencias verificables de 33 años de carrera.

Error #3: Especificaciones vagas

El error

Iniciar proyecto sin requisitos claramente definidos.

Conversación típica:

• Cliente: "Quiero una web de ecommerce"
• Programador: "Ok, 15.000€"
• Cliente: "¡Perfecto, empecemos!"

3 meses después:

• Cliente esperaba integración con su ERP
• Programador desarrolló ecommerce estándar sin integraciones
• Ambos tienen razón según su interpretación
• Conflicto, dinero perdido, relación rota

Por qué ocurre

• Cliente asume que "ecommerce" significa lo mismo para todos
• No tiene experiencia especificando software
• Programador no hace preguntas suficientes
• Urgencia por empezar

Cómo evitarlo

Define ANTES de contratar:

1. Objetivo de negocio

   • ¿Qué problema resuelve la web?
   • ¿Qué métricas de éxito?

2. Funcionalidades específicas

   • Lista detallada de features
   • Prioritzadas (must-have vs nice-to-have)

3. Integraciones requeridas

   • Sistemas existentes
   • APIs de terceros
   • Pasarelas de pago

4. Volúmenes esperados

   • Usuarios concurrentes
   • Transacciones por día
   • Productos en catálogo

5. Usuarios objetivo

   • Perfiles
   • Dispositivos
   • Ubicaciones

Formato sugerido: User Stories

Como [rol]
Quiero [acción]
Para [beneficio]

Criterios de aceptación:
- [ ] Criterio 1
- [ ] Criterio 2

Ejemplo:

Como cliente del ecommerce
Quiero guardar productos en wishlist
Para comprarlos posteriormente

Criterios:
- [ ] Botón "Guardar para después" en cada producto
- [ ] Lista persistente entre sesiones
- [ ] Notificación si precio baja
- [ ] Límite de 50 productos en wishlist

Un buen programador web te ayudará a definir specs si no sabes hacerlo. Pero tú debes comunicar objetivos de negocio claramente.

Personalmente, dedico ~20% del tiempo inicial a discovery y especificación. Previene el 80% de conflictos posteriores.

Error #4: No requerir testing

El error

Aceptar "funciona en mi máquina" como suficiente.

Escenario típico:

Programador entrega web. Cliente prueba manualmente, parece funcionar. Lanza a producción.

2 días después:

• Formularios fallan en Safari
• Checkout roto en móviles
• Emails de confirmación no llegan
• Base de datos se corrompe con caracteres especiales

Programador: "Funcionaba en mi local" 🤷

Por qué ocurre

• Cliente no técnico no sabe pedir tests
• Programador junior no conoce TDD
• Presión por entregar rápido
• "Los tests son opcionales"

Cómo evitarlo

Haz testing OBLIGATORIO en el contrato:

Requisitos de calidad no negociables:

1. Cobertura de tests >80%
2. Tests unitarios para lógica de negocio
3. Tests de integración para APIs
4. Tests E2E para flujos críticos (checkout, registro)
5. CI/CD ejecutando tests automáticamente
6. Reporte de cobertura entregado con código

Preguntas al contratar:

• ¿Usas TDD?
• ¿Qué framework de testing?
• ¿Qué cobertura de tests garantizas?
• ¿Cómo validas que funciona en múltiples navegadores?

Si la respuesta es "no hago tests":

❌ DESCARTA INMEDIATAMENTE

No importa cuán barato, cuán rápido, o cuán "experimentado" diga ser. Código sin tests es deuda técnica desde día 1.

Costo real:

• Desarrollo con tests: +30% tiempo inicial
• Debugging sin tests: +200% tiempo en 6 meses

Los tests se pagan solos en semanas.

Mi política: TDD no negociable. No entrego código sin tests. Punto.

Error #5: Comunicación insuficiente

El error

No establecer expectativas claras de comunicación.

Escenario:

Cliente y programador acuerdan proyecto. Programador dice "lo tengo en 4 semanas".

Cliente espera. 4 semanas después:

• ¿El programador está trabajando?
• ¿Hay problemas?
• ¿Cómo va el progreso?

Cliente sin respuestas, programador sin entregar.

Por qué ocurre

• No se define frecuencia de updates
• Programador enfocado en código, olvida comunicar
• Cliente asume que "sin noticias es buenas noticias"
• Falta de herramientas de tracking

Cómo evitarlo

Define en el contrato:

1. Frecuencia de updates

   • Diario: mensaje de progreso (5min)
   • Semanal: reunión de 30min
   • Quincenal: demo de features completadas

2. Canales de comunicación

   • Email para temas formales
   • Slack/Telegram para día a día
   • Videollamadas para decisiones importantes

3. Horarios de disponibilidad

   • ¿9-18h? ¿Flexible?
   • ¿Fines de semana?
   • Tiempo de respuesta esperado (24h laborables)

4. Herramientas de tracking

   • GitHub Projects, Jira, Trello
   • Visibilidad de tareas en progreso
   • Burndown charts

Red flags de comunicación:

❌ "Te aviso cuando esté listo" ❌ Días sin responder ❌ Evasivo sobre problemas ❌ Sin herramientas de tracking

Mi workflow:

• Update diario vía Slack (2min)
• Reunión semanal 30min
• Demo cada 2 semanas
• GitHub Projects para transparencia total

Cliente siempre sabe en qué estoy trabajando, qué bloqueadores hay, y cuándo esperar cada entrega.

Error #6: Pagar 100% por adelantado

El error

Dar todo el dinero antes de ver resultados.

Escenario de pesadilla:

Cliente paga 10.000€ por adelantado. Programador:

• Trabaja 1 semana
• Desaparece con el dinero
• Cliente sin web, sin dinero, sin recurso legal efectivo

O variante menos dramática:

• Programador pierde motivación después del pago
• Entregables de baja calidad
• Cliente sin leverage para exigir mejor

Por qué ocurre

• Programador "necesita el dinero para empezar"
• Cliente inexperto acepta términos
• Sin contrato formal claro
• Sin hitos definidos

Cómo evitarlo

Estructura de pagos por hitos:

Proyecto de 20.000€:

30% inicio (6.000€) - Al firmar contrato
30% hito 1 (6.000€) - Al completar frontend
20% hito 2 (4.000€) - Al completar backend + APIs
15% hito 3 (3.000€) - Al completar testing + deployment
 5% final (1.000€) - 30 días después de lanzamiento

Principios:

1. Nunca >50% antes de ver código funcional
2. Pagos atados a entregables verificables
3. Retención final (5-10%) por 30-60 días post-launch
4. Hitos pequeños (~2-3 semanas de trabajo)

Red flags:

❌ Exige 100% adelantado ❌ "Confía en mí, llevo X años" ❌ Sin contrato formal ❌ Sin hitos definidos

Mi modelo estándar:

• 30% inicio
• 60% en hitos de 2 semanas
• 10% retención 30 días

Protege a ambas partes: cliente tiene leverage, yo tengo cashflow para trabajar.

Error #7: No considerar mantenimiento futuro

El error

Pensar que "entregar el proyecto" es el fin.

Realidad:

Software necesita mantenimiento continuo:

• Updates de seguridad
• Actualización de dependencias
• Servidor, dominio, SSL
• Backup y monitoring
• Nuevas features
• Bugs que aparecen con uso real

Cliente sorprendido 6 meses después:

• "WordPress necesita actualizar urgentemente (vulnerabilidad)"
• "El certificado SSL expiró"
• "El servidor se quedó sin espacio"
• "Los emails dejaron de funcionar"

Y el programador original no responde porque "el proyecto terminó".

Por qué ocurre

• Cliente asume que web "funciona para siempre"
• No budget para mantenimiento
• Sin acuerdo de soporte post-launch

Cómo evitarlo

Antes de contratar, pregunta:

1. ¿Qué mantenimiento requiere?

   • Actualizaciones (qué frecuencia)
   • Monitoreo necesario
   • Backups

2. ¿Qué incluye el proyecto?

   • Solo desarrollo
   • Hosting (cuánto tiempo)
   • Soporte post-launch (cuánto)

3. ¿Opciones de mantenimiento post-launch?

   • Retainer mensual (horas incluidas)
   • Pay-per-hour para incidencias
   • SLA para bugs críticos

Opciones típicas:

A) Retainer mensual

• 300-800€/mes
• Incluye: updates, monitoreo, 5-10h soporte
• Para negocios que necesitan tranquilidad

B) Pay-per-incident

• Solo pagas cuando necesitas algo
• Bueno para webs estables con poco cambio
• Riesgo: programador no disponible cuando urge

C) Traspaso completo

• Programador entrega código + documentación
• Cliente contrata equipo interno o otro proveedor
• Requiere documentación exhaustiva

Mi recomendación:

Para proyectos pequeños-medianos:

• 3 meses de soporte incluido
• Luego retainer opcional 300-500€/mes

Para proyectos grandes:

• 6 meses de soporte incluido
• Luego retainer 800-1500€/mes o contratación de equipo interno

Plus: Ofrezco garantía de por vida en mi código. Si algo se rompe por bug mío, lo arreglo gratis siempre.

Error #8: Ignorar escalabilidad desde inicio

El error

"Lo haremos scalable cuando tengamos más usuarios"

Caso real:

Startup construye MVP con programador junior barato. Stack:

• PHP puro sin framework
• MySQL con queries sin optimizar
• Archivos en disco local
• Sin cache

Lanza, éxito viral inesperado. Con 500 usuarios concurrentes:

• Servidor se cae constantemente
• Consultas tardan 30 segundos
• Imposible escalar fácilmente

Necesitan reescribir desde cero: 60.000€ + 4 meses de oportunidad perdida.

Si hubieran pensado en escalabilidad desde inicio:

• +5.000€ en desarrollo inicial
• Stack escalable (Docker, PostgreSQL, Redis)
• Listo para crecer sin refactor

Por qué ocurre

• "No vamos a tener muchos usuarios al inicio"
• Optimización prematura vista como mala
• Programador sin experiencia en escalabilidad

Cómo evitarlo

No es construir para millones desde día 1:

Es usar buenas prácticas que permiten escalar sin refactor:

✅ Stack moderno

• Docker (fácil de replicar)
• PostgreSQL (escala mejor que MySQL)
• Redis (cache desde inicio)
• CDN para assets estáticos

✅ Arquitectura desacoplada

• APIs REST
• Frontend separado de backend
• Microservicios cuando aplique

✅ Buenas prácticas

• Queries optimizadas con indexes
• Paginación en listados
• Lazy loading de imágenes
• Caching estratégico

Coste:

• Stack escalable vs no escalable: +15-20% inicial
• Reescribir después: +300-500% del coste original

Pregunta al programador:

• ¿Cómo manejas 10x usuarios del día 1?
• ¿Qué cuellos de botella anticipas?
• ¿Estrategia de caching?
• ¿Monitoreo de performance?

Si no tiene respuestas claras, red flag.

Personalmente uso stack moderno diseñado para escalar desde MVP hasta enterprise. No cuesta significativamente más, pero previene refactors costosos.

Error #9: No tener contrato formal

El error

"Somos amigos, no necesitamos contrato" "Es un proyecto pequeño, no vale la pena"

Desastre inevitable:

Sin contrato:

• ¿Quién es dueño del código?
• ¿Qué pasa si hay bugs después?
• ¿Qué cubre el presupuesto exactamente?
• ¿Cómo se resuelven disputas?

Cuando surge conflicto (siempre surge algo):

• Sin base legal clara
• Cada uno recuerda conversación diferente
• Imposible de resolver amigablemente
• Relación personal rota también

Por qué ocurre

• Incomodidad con "legalidades"
• "Los contratos son para desconfiar"
• Prisa por empezar
• "Son solo 2.000€, no vale la pena"

Cómo evitarlo

Contrato SIEMPRE, independiente del monto:

Elementos obligatorios:

1. Alcance (Scope)

   • Features incluidas
   • Entregables específicos
   • Qué NO está incluido

2. Cronograma

   • Hitos con fechas
   • Qué pasa si hay retrasos

3. Presupuesto

   • Monto total
   • Estructura de pagos
   • Qué incluye (hosting, dominio, etc.)

4. Propiedad intelectual

   • ¿Cliente dueño del código?
   • ¿Programador puede mostrar en portfolio?
   • Licencias de terceros

5. Garantía y mantenimiento

   • Período de garantía
   • Qué cubre
   • Soporte post-launch

6. Confidencialidad

   • NDA si información sensible
   • Protección de datos (GDPR)

7. Rescisión

   • Cómo terminar contrato
   • Qué pasa con pagos
   • Entrega de trabajo realizado

8. Resolución de disputas

   • Arbitraje o tribunales
   • Jurisdicción aplicable

Plantillas:

Busca "contrato desarrollo web" en Google. Adapta a tu caso.

Coste:

• Abogado revise contrato: 200-500€
• VALE CADA EURO

No negociables:

❌ Programador rechaza firmar contrato ❌ "Hagámoslo simple, sin papeles"

Protege a ambas partes. Yo siempre insisto en contrato formal, no importa el tamaño del proyecto.

Error #10: Stack tecnológico obsoleto

El error

Construir con tecnologías antiguas en 2026.

Ejemplos que veo regularmente:

• jQuery en lugar de React/Vue
• PHP 5.x sin framework
• MySQL 4.x
• Sin control de versiones (Git)
• Sin containerización (Docker)

Problema:

6 meses después necesitas añadir feature o corregir bug:

• Ningún programador moderno quiere tocar ese código
• Los que aceptan cobran prima "legacy"
• Difícil de mantener y escalar
• Seguridad comprometida (versiones sin updates)

Por qué ocurre

• Programador solo conoce tecnologías antiguas
• "Si funciona, no lo toques"
• Hosting compartido barato solo soporta PHP viejo
• Cliente no sabe diferencia

Cómo evitarlo

Stack mínimo moderno en 2026:

Frontend:

• React, Vue o Svelte (no jQuery)
• TypeScript (no JavaScript plano)
• Tailwind u otro CSS moderno (no CSS inline)

Backend:

• Node.js (Express/Fastify)
• Python (Django/FastAPI)
• PHP moderno (8.x con Symfony/Laravel)

Database:

• PostgreSQL o MySQL 8.x
• MongoDB si NoSQL hace sentido
• Redis para cache

DevOps:

• Git (GitHub, GitLab)
• Docker para desarrollo y producción
• CI/CD (GitHub Actions, GitLab CI)

Pregunta al programador:

• ¿Qué stack propones y por qué?
• ¿Qué versiones específicas?
• ¿Cómo se mantiene actualizado?
• ¿Qué tan fácil es encontrar otros developers para este stack?

Red flags:

❌ jQuery como framework principal ❌ PHP sin framework o versión <7.4 ❌ "No necesitamos Git, tengo backups" ❌ Sin Docker ni containerización ❌ Tecnologías que nadie usa ya

Personalmente solo uso stack moderno probado: Next.js, TypeScript, PostgreSQL, Docker. Es mantenible, escalable y cualquier programador moderno puede trabajar con él después de mí.

Error #11: No validar experiencia específica

El error

Asumir que "programador = puede hacer cualquier cosa"

Caso real:

Cliente necesita sistema RAG con IA. Contrata programador con "10 años de experiencia web".

Resultado:

• Programador nunca trabajó con LLMs
• No conoce LangChain ni vector databases
• Intenta "aprenderlo sobre la marcha"
• 2 meses perdidos, código inservible

Cliente recontrata especialista en IA. Proyecto se completa en 3 semanas.

Por qué ocurre

• Todos los programadores web parecen similares
• Cliente no sabe preguntar por especialización
• Programador acepta trabajo fuera de expertise (necesita dinero)

Cómo evitarlo

Match expertise con tipo de proyecto:

Preguntas específicas:

Para proyecto ecommerce:

• "¿Cuántos ecommerce has desarrollado?"
• "¿Qué pasarelas de pago has integrado?"
• "¿Cómo manejas inventario y stock?"
• "Muéstrame un ecommerce específico que hayas hecho"

Para proyecto con IA:

• "¿Experiencia con LLMs y LangChain?"
• "¿Has implementado sistemas RAG?"
• "¿Hosting de modelos y vectores?"
• "Muéstrame caso de uso de IA que hayas desarrollado"

Red flag: ❌ "Sí, puedo hacer cualquier cosa"

Good sign: ✅ "Sí, he hecho proyectos similares antes. Aquí están y aquí está el código"

Como programador web full-stack + AI engineer, me especializo en:

• Desarrollo web moderno (33 años)
• Ingeniería de IA (certificado y experiencia)
• Integraciones complejas

Si tu proyecto requiere expertise que no tengo, te lo diré honestamente y recomendaré a alguien mejor.

Error #12: No planificar para futuro

El error

Solo pensar en "lanzar versión 1"

Consecuencia:

6 meses después necesitas:

• Añadir funcionalidad
• Integrar con sistema nuevo
• Cambiar diseño
• Escalar a más usuarios

Pero el código fue escrito sin:

• Documentación
• Tests
• Arquitectura modular
• Patrones escalables

Resultado: Cada cambio es caro, lento y riesgoso.

Por qué ocurre

• Urgencia por lanzar rápido
• "Ya pensaremos en eso después"
• Programador optimiza para entregar rápido, no mantenibilidad

Cómo evitarlo

Piensa en:

1. ¿Qué features vendrán en v2?

   • Asegura arquitectura soporta extensión

2. ¿Quién mantendrá el código?

   • Documentación obligatoria
   • Código legible > código clever

3. ¿Crecimiento esperado1. ¿Crecimiento esperado?

   • Diseña para 10x usuarios desde día 1

4. ¿Integraciones futuras?

   • APIs modulares
   • Webhooks para extensibilidad

Principios de código sostenible:

✅ Tests (ya mencionado, crítico) ✅ Documentación (README, comentarios) ✅ Patrones estándar (no código "creativo") ✅ Monitoreo (logs, metrics desde v1) ✅ Modularidad (fácil añadir features)

Coste:

• Código sostenible: +20% tiempo inicial
• Mantenimiento después: -60% tiempo/coste

Inversión que se paga sola en 6-12 meses.

Personalmente, siempre desarrollo pensando "otro programador mantendrá esto en 2 años". Código limpio, tests comprensivos, docs claras. Garantía de por vida solo es posible con código mantenible.

Resumen: Checklist anti-errores

Antes de contratar tu programador web, valida:

✅ Evaluación del profesional

• Portfolio con proyectos reales funcionando
• Referencias verificables de 2-3 clientes
• Código visible (GitHub o muestras)
• Stack tecnológico moderno
• Testing como práctica estándar (no opcional)
• Experiencia específica en tu tipo de proyecto
• Comunicación clara y profesional

✅ Proyecto y contrato

• Especificaciones detalladas por escrito
• Funcionalidades prioritizadas (must-have vs nice-to-have)
• Presupuesto desglosado por fases
• Cronograma realista con hitos
• Contrato formal firmado
• Estructura de pagos por hitos (no 100% adelantado)
• Propiedad intelectual clara

✅ Calidad y futuro

• Tests obligatorios en contrato
• Cobertura mínima definida (>80%)
• Documentación incluida en entregables
• Plan de mantenimiento post-launch
• Garantía de bugs (mínimo 3-6 meses)
• Stack escalable desde inicio
• Arquitectura modular para crecimiento

✅ Comunicación y gestión

• Frecuencia de updates definida
• Canales de comunicación acordados
• Herramientas de tracking configuradas
• Proceso de feedback y cambios claro
• Disponibilidad y tiempos de respuesta definidos

Tu proyecto merece un profesional

Con esta guía, tienes todo para evitar los errores que arruinan el 80% de proyectos web.

Recuerda:

1. No optimices por precio, optimiza por valor
2. Valida experiencia SIEMPRE
3. Especifica claramente antes de empezar
4. Testing es no negociable
5. Comunica frecuentemente
6. Contratos formales siempre
7. Stack moderno y escalable
8. Planifica mantenimiento desde día 1

Un buen programador web no solo escribe código. Te guía para evitar estos errores, propone arquitectura sólida, comunica proactivamente, y construye pensando en futuro.

Con 33 años de experiencia, he cometido errores y he ayudado a clientes evitar desastres. Mi enfoque:

• ✅ Especificaciones claras antes de presupuesto
• ✅ Stack moderno y probado (Next.js, TypeScript, PostgreSQL)
• ✅ TDD obligatorio con cobertura >80%
• ✅ Comunicación frecuente (updates diarios, demos quincenales)
• ✅ Contrato formal que protege a ambas partes
• ✅ Garantía de por vida en mi código
• ✅ Arquitectura escalable desde MVP

¿Listo para hacer tu proyecto bien desde el inicio?

Cuéntame tu proyecto y recibe:

• Análisis de viabilidad
• Propuesta técnica detallada
• Presupuesto transparente por fases
• Cronograma realista
• Sin jerga técnica, solo claridad

Todo en menos de 24 horas. Sin compromiso.

Jordi Morillo - Programador Web | 33 años de experiencia | Evita errores costosos, trabaja conmigo