7 errores al contratar una agencia de desarrollo de software

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.

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é

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?
• ¿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. No es deal-breaker si no la tienen, pero deberías saber si vas a pagar por su curva de aprendizaje.

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)

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.
• 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”.
• No hacen preguntas incómodas sobre tu modelo de negocio o restricciones técnicas.

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?
• Deployment y hosting: ¿Configurarán infraestructura en TU cuenta cloud?
• Documentación: ¿Entregarán docs técnicas? ¿Architecture diagrams?

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?
• ¿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?

Expectativa realista para proyectos 20K€+:

• 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: 15-20% del costo inicial por año para hosting, updates, security patches, small fixes.
• No definir qué es “soporte” vs “nuevo desarrollo”.

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 (sitio caído, payment processing roto)
• Costo de retainer mensual si quieres soporte continuo (típico: 1.500€–4.000€/mes)
• Proceso para solicitar nuevas features

Cuándo NO contratar una agencia

• Si tu producto ES software y planeas escalar: eventualmente necesitarás equipo interno.
• Si no tienes claridad de qué construir: agencias no son consultoras de producto.
• Si esperas micro-management diario: las buenas agencias trabajan con autonomía.
• Si tu presupuesto es <10K€ para un producto custom: ese rango solo alcanza para MVPs muy acotados.

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: MVPs simples desde 12K€–25K€, productos medianos 30K€–80K€, plataformas complejas 100K€+. Si alguien te ofrece “plataforma completa por 5K€”, huye.

¿Puedo construir un MVP por 8.000€?

Técnicamente sí, pero con tradeoffs serios: freelancer junior, sin diseño custom, features ultra-reducidas, sin QA formal. Funciona para validar idea rápido, no para 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.

¿Cuánto cuesta agregar mobile apps después?

Si la web app tiene buena API: 20.000€–50.000€ por plataforma. React Native para ambas: 30.000€–60.000€. Progressive Web App: 6.000€–15.000€ adicionales.

¿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. Por eso milestone-based payments son críticos.