Hemos visto empresas perder 40K€+ y 6 meses de calendario por contratar la agencia equivocada. No porque la agencia fuera incompetente, sino porque ambas partes no alinearon expectativas desde el inicio.
Este artículo cubre los 7 errores más comunes que vemos cuando empresas contratan agencias de desarrollo de software, basados en conversaciones con founders que "ya lo intentaron antes" y nos contactan para rescatar proyectos.
1. Elegir solo por precio
El error número uno: comparar presupuestos sin contexto de qué incluyen.
Ejemplo real: Un cliente recibió tres propuestas para su plataforma SaaS:
- Agencia A: 18K€ — desarrollo básico, sin diseño custom, hosting no incluido
- Agencia B: 35K€ — incluye UX/UI, testing, 3 meses de mantenimiento
- Freelancer C: 9K€ — "full stack development", sin más detalles
Eligió la opción C. Tres meses después, el freelancer desapareció con el proyecto 60% terminado, sin documentación, y con código que nadie más pudo continuar sin reescribir casi todo.
Por qué pasa: Los presupuestos bajos suelen omitir etapas críticas (discovery, testing, deployment) o asumen que el cliente proveerá diseños, infraestructura, o project management.
Cómo evitarlo:
- Pide desglose detallado de qué incluye cada presupuesto
- Pregunta explícitamente qué NO está incluido
- Compara manzanas con manzanas: ¿incluyen diseño? ¿testing? ¿deployment? ¿soporte post-lanzamiento?
- Si un presupuesto es 50%+ más barato que otros, pregunta por qué
Si una agencia da un presupuesto "final" en la primera llamada sin hacer preguntas sobre tu negocio, arquitectura existente, o usuarios, es imposible que sea preciso.
2. No verificar el portfolio con contexto
Ver screenshots bonitos no dice nada sobre si la agencia puede ejecutar tu proyecto.
Preguntas que casi nadie hace:
- ¿Cuál fue tu rol específico en este proyecto? (diseño, backend, todo)
- ¿El proyecto sigue activo? ¿Puedo hablar con el cliente?
- ¿Qué problemas técnicos encontraron y cómo los resolvieron?
- ¿Hubo cambios de scope? ¿Cómo los manejaron?
- ¿Cuánto tiempo tomó de planificación a producción?
Si la agencia solo muestra proyectos "genéricos" (e-commerce, landing pages), pregunta si tienen experiencia en tu industria o tipo de producto. No es deal-breaker si no la tienen, pero deberías saber si vas a pagar por su curva de aprendizaje.
Trade-off: Agencias especializadas en tu vertical suelen ser más caras pero ejecutan más rápido. Agencias generalistas pueden ser buena opción si tu producto no tiene complejidad técnica específica de industria.
3. Firmar contratos vagos sobre entregables
Contratos que dicen "desarrollo de plataforma web" sin especificar funcionalidades concretas son recetas para scope creep y discusiones.
Lo que debe estar en el contrato:
- Lista específica de features con prioridad (must-have vs nice-to-have)
- Entregables por milestone con criterios de aceptación
- Proceso de change requests (cómo se aprueban, cómo afectan precio/timeline)
- Propiedad de código, diseños, licencias de terceros
- Qué pasa si alguna parte quiere terminar el contrato early
- Soporte post-lanzamiento (duración, tipo de issues cubiertos)
Ejemplo de cláusula vaga vs clara:
Vago: "Sistema de autenticación de usuarios"
Claro: "Sistema de autenticación que incluye: registro por email/password, login, recuperación de contraseña, email verification, roles de usuario (admin/user), OAuth con Google y Facebook"
La versión vaga te puede dejar sin OAuth, sin roles, sin email verification. Cuando los pides después, la agencia dirá "eso está fuera de scope".
4. Ignorar red flags en comunicación
Cómo se comunican durante el sales process es exactamente cómo se comunicarán durante desarrollo.
Red flags que vemos constantemente:
- Tardan 48+ horas en responder antes de firmar contrato. Después será peor.
- Solo hablas con sales, nunca con el tech lead que trabajará tu proyecto. Señal de que el equipo real no tiene capacidad de comunicación o no existe todavía.
- Respuestas genéricas tipo "usaremos las mejores prácticas" sin explicar qué significa eso para tu caso específico.
- Te presionan para firmar rápido con "oferta especial válida esta semana". Las buenas agencias tienen pipeline lleno, no necesitan presión de ventas.
- No hacen preguntas incómodas sobre tu modelo de negocio, competencia, o restricciones técnicas. Si solo asienten a todo, no están pensando en tu problema.
Lo que sí quieres ver:
- Te hacen preguntas que demuestran que entendieron tu negocio
- Te dicen qué NO deberías construir en v1
- Te explican trade-offs de decisiones técnicas en lenguaje claro
- Tienen proceso definido de check-ins, reporting, y feedback loops
5. No clarificar ownership y derechos
Hemos visto casos donde la empresa no puede tocar el código sin pagar fees adicionales a la agencia. O peor: la agencia reutiliza módulos propietarios y la empresa no puede migrar sin reescribir partes críticas.
Qué debe quedar claro antes de firmar:
- Ownership del código: ¿Es 100% tuyo? ¿Hay componentes que la agencia retiene?
- Acceso al código: ¿Entregarán repo con historial completo? ¿O solo un zip al final?
- Licencias de terceros: Si usan APIs o librerías pagas, ¿quién las contrata? ¿Quedan a tu nombre?
- Deployment y hosting: ¿Configurarán infraestructura en TU cuenta cloud? ¿O en la suya?
- Documentación: ¿Entregarán docs técnicas? ¿Setup instructions? ¿Architecture diagrams?
Escenario común: La agencia configura todo en su cuenta AWS "para facilitar el setup inicial". Después, cuando quieres tomar control, te cobran por "migration" o peor, no tienen tiempo para hacerlo y tu proyecto queda atrapado en su infraestructura.
Solución: Exige que infraestructura se configure en cuentas a tu nombre desde día uno. Sí, es más trabajo inicial, pero evita dependencias futuras.
6. No preguntar sobre el proceso de desarrollo
Muchas empresas asumen que todas las agencias trabajan igual. No es así.
Preguntas que deberías hacer:
- ¿Hacen discovery/planning antes de escribir código? ¿Está incluido en el presupuesto?
- ¿Usan metodología ágil? ¿Qué significa eso en la práctica para ti como cliente?
- ¿Cuál es la frecuencia de updates? ¿Tendrás acceso a staging environment para probar?
- ¿Cómo manejan bugs encontrados durante desarrollo vs post-lanzamiento?
- ¿Quién es el point of contact? ¿Hablarás con developers o solo con PM?
- ¿Hacen code reviews? ¿Testing automatizado?
Por qué importa: Si esperabas updates semanales y check-ins frecuentes, pero la agencia trabaja en sprints de 4 semanas con una sola review al final, habrá fricción. O peor: sorpresas costosas cuando veas el resultado después de un mes de trabajo.
Expectativa realista: Para proyectos 20K€+, deberías tener:
- Kick-off meeting con tech team, no solo sales
- Updates cada 1-2 semanas (demo de progreso, no solo status report)
- Acceso a ambiente de staging para probar antes de deployment final
- Documentación de decisiones técnicas importantes
7. Olvidar el plan post-lanzamiento
Lanzar el producto es 50% del trabajo. Mantenerlo, fixear bugs, y añadir features basadas en feedback real de usuarios es la otra mitad.
Errores comunes:
- Asumir que "lanzamiento" significa "terminado": Siempre hay bugs que solo aparecen con tráfico real.
- No presupuestar para mantenimiento: Regla general: 15-20% del costo inicial por año para hosting, updates, security patches, small fixes.
- No definir qué es "soporte" vs "nuevo desarrollo": ¿Fixear un bug de login es soporte? ¿Y añadir un nuevo campo al formulario?
Qué negociar antes de firmar:
- X semanas/meses de bug fixes post-lanzamiento incluidos (típico: 30-90 días)
- SLA para respuesta a issues críticos (e.g., sitio caído, payment processing roto)
- Costo de retainer mensual si quieres soporte continuo (típico en España: 1,500€–4,000€/mes dependiendo de disponibilidad)
- Proceso para solicitar nuevas features (hourly rate vs mini-proyectos vs roadmap trimestral)
Trade-off: Retainers mensuales dan prioridad, pero si solo necesitas updates esporádicos, pay-per-project puede ser más económico. Depende de tu roadmap.
Cuándo NO contratar una agencia
Outsourcing a una agencia no siempre es la mejor opción. Situaciones donde probablemente no tenga sentido:
- Si tu producto ES software y planeas escalar: Eventualmente necesitarás equipo interno. Empezar con agencia puede darte MVP rápido, pero no deberías depender de terceros para tu core product a largo plazo.
- Si no tienes claridad de qué construir: Agencias no son consultoras de producto. Si todavía estás descubriendo qué problema resolver, contrata un product advisor primero.
- Si esperas micro-management diario: Las buenas agencias trabajan con autonomía. Si necesitas aprobar cada decisión de diseño o línea de código, contrata in-house.
- Si tu presupuesto es <10K€ para un producto custom: Ese rango solo alcanza para MVPs muy acotados o landing pages. No para "el próximo Airbnb".
Cuándo SÍ tiene sentido:
- Necesitas lanzar rápido y no tienes equipo técnico interno
- Proyecto tiene scope definido y timeline claro
- No es tu core product, sino herramientas internas o complementarias
- Quieres validar una idea sin commitment de contratar equipo full-time
Preguntas frecuentes
¿Cuánto debería costar un proyecto de desarrollo custom?
Depende del scope, pero en España: MVPs simples desde 12K€–25K€, productos medianos 30K€–80K€, plataformas complejas 100K€+. Si alguien te ofrece "plataforma completa por 5K€", huye. Ese presupuesto solo alcanza para templates con customización mínima.
¿Puedo construir un MVP por 8,000€?
Técnicamente sí, pero con tradeoffs serios: freelancer junior, sin diseño custom, features ultra-reducidas, probablemente sin QA formal. Funciona para validar idea rápido, no para algo que mostrarás a clientes enterprise o usarás en producción seria.
¿Fixed price o time & materials?
Fixed price funciona si scope está perfectamente definido (raro). Time & materials con cap mensual es más realista—pagas por horas trabajadas pero con límite máximo. Evita sorpresas pero permite ajustar scope según aprendes.
¿Cuánto cuesta agregar mobile apps después?
Si la web app tiene buena API: 20,000€–50,000€ por plataforma (iOS o Android) para app nativa básica. React Native para ambas: 30,000€–60,000€. Progressive Web App (PWA): 6,000€–15,000€ adicionales sobre web existente.
¿Qué pasa si me quedo sin presupuesto a mitad del proyecto?
Buen dev shop entrega en fases funcionales. Si el presupuesto se agota, deberías tener algo usable aunque incompleto. Mal dev shop entrega nada hasta el final. Por eso milestone-based payments son críticos.