Siete criterios para evaluar consultoras y agencias en 2026, un checklist accionable y los errores de selección que más cuestan a los CTOs.
TL;DR
Elegir agencia de desarrollo se reduce a verificar siete cosas: quién va a tocar el código (no quién firma la propuesta), su trayectoria real verificable, alineación de stack con tu equipo interno, modelo de pricing (precio cerrado vs. T&M), ownership de IP y código, capacidad de operar SLA en producción, y cómo gestionan el handover. Las decisiones malas casi nunca son por precio: son por desalineación entre el comercial vendido y el equipo asignado. Esta guía te da el checklist y el scoring que usan los equipos de compras técnicos en España en 2026.
Por dónde se rompe
Comprar desarrollo de software es una de las decisiones más asimétricas que toma una empresa. El proveedor sabe exactamente cuánto sabe, qué riesgos hay y cómo presentarse. El comprador suele tener una sola comparación referencial (un freelancer, un equipo interno anterior, otra agencia mal) y mucho marketing genérico encima.
El resultado: agencias eligen por demo bonita, propuesta más completa o por contacto personal, y a los 4–6 meses descubren que el equipo asignado no era el de la presentación, que el stack "recomendado" era el que la agencia ya tenía, o que el código no es transferible sin un retainer interminable.
Esta guía propone siete criterios verificables antes de firmar. No son subjetivos: se pueden contestar con datos. Si el proveedor no te los puede responder con concreción, ya tienes una respuesta.
Los 7 criterios
Cada criterio resuelve un fallo concreto que vemos en compras técnicas. Aplica al evaluar Dribba o cualquier otra agencia.
Scoring
Puntúa cada criterio del 1 al 5 para cada proveedor. La que saca el peor 1, no la mejor media, suele ser la que predice mejor el resultado final.
| Criterio | Qué pedir | Señal de alarma | Señal positiva |
|---|---|---|---|
| Equipo asignado | Perfiles LinkedIn nominales + años de exp. | "Asignamos el equipo cuando arranquemos" | CV técnicos cerrados antes de firmar |
| Trayectoria verificable | 2–3 referencias contactables | Solo logos en web sin caso de detalle | Referencias hablan sin guion, citan plazos reales |
| Alineación de stack | Justificación técnica del stack propuesto | "Es lo que mejor escala" sin contexto | Compara 2–3 opciones y explica trade-offs |
| Modelo de pricing | Precio cerrado por sprint o entregable | Solo T&M para scope claro | Mixto: cerrado para scope conocido, T&M para incertidumbre real |
| Ownership IP | Cláusula de cesión total al cliente | "Framework propietario" sin acceso al fuente | 100% IP al cliente + acceso a repos cliente desde día 1 |
| Operación / SLA | SLOs por producto, guardia rotativa | "Soporte en horario laboral" | On-call 24/7 opcional, postmortems compartidos |
| Handover | Plan documentado, ejemplo previo | "Cuando llegue el momento lo organizamos" | Runbooks, ADRs, onboarding interno documentado |
Checklist accionable
Imprime esta lista (o cópiala a Notion) y pasa por ella en la reunión final. Si el proveedor no puede responder con concreción a 3 o más, descártalo.
Errores que cuestan caro
Una pregunta que filtra mucho
Pregunta: "¿Quién va a hacer la primera review de pull request de mi proyecto?" Si la respuesta es un nombre concreto con experiencia verificable, hay equipo real detrás. Si es "un tech lead asignado" sin más, estás comprando una caja negra.
Preguntas frecuentes
Hay tres ejes objetivos: (1) Seniority del equipo asignado: pide CV nominales antes de firmar y verifica con LinkedIn. (2) Operación, no solo construcción: pregunta cómo gestionan SLA, observabilidad y on-call — una agencia que solo construye no es comparable con una que opera. (3) Stack y trade-offs explicados: una agencia seria justifica por qué Go vs Node, no "depende". Si los tres ejes coinciden, la decisión final es de cultura y de química con el equipo.
Tres tendencias visibles en 2026 entre consultoras y empresas técnicas en España: (1) Migración de Node/Python a Go para servicios críticos donde el coste de Cloud Run y la latencia importan. (2) Adopción masiva de IA generativa en producto (no solo en herramientas internas): orquestación de LLMs vía Python o TS con observabilidad de tokens. (3) Plataformas internas (IDPs — Internal Developer Platforms) con Backstage o builds custom para acelerar el time-to-onboarding de ingenieros. En infraestructura, Cloud Run y AWS App Runner siguen ganando terreno a Kubernetes para el 80% de casos.
El precio/hora medio en España en 2026 se reparte así: agencias boutique especializadas (Dribba, Apiumhub, Codium, Plain Concepts) entre 75 y 130 €/h; software factories medianas entre 55 y 90 €/h; grandes integradoras (Indra, Accenture, NTT Data) entre 90 y 180 €/h por perfil consultor (pero con escala de juniors-seniors muy variable). Para proyectos de producto, las boutique son la opción más eficiente por euro invertido.
Pide referencias de clientes activos o recientes en el mismo sector, no solo logos en la web. Llama a una o dos: pregunta plazos reales (cumplidos vs. desviados), cómo gestionaron cambios de scope y si podrían cambiar de proveedor manteniendo el código. Si una agencia no te pasa referencias contactables del último año, asume que las suyas o no existen o no pueden recomendarla.
Si el contrato marco está bien firmado: el cliente conserva el 100% del código, la documentación, los repos en su cuenta y los entornos cloud en su cuenta. Cambiar de proveedor cuesta entonces 2–6 semanas de onboarding del nuevo equipo. Si el contrato no protege esto ("nuestro framework propietario", IP cedida tras pago final, repos en cuenta del proveedor), cambiar puede costar el 40–70% de un rewrite. Esta es la cláusula más cara de pasar por alto.
Una agencia boutique con equipo libre puede arrancar Sprint 0 en 1–2 semanas desde la firma. Una agencia mediana suele tardar 2–4 semanas si el perfil que necesitas no está libre. Las grandes integradoras pueden tardar 4–8 semanas en formar equipo. Si la agencia te promete arrancar "mañana" sin haber visto el scope, sospecha: significa que asigna a quien esté disponible, no a quien encaja.
Depende del tipo de proyecto. Para transformación empresarial con headcount > 50 personas, presupuesto > 1 M € y requisitos de compliance corporativo, las grandes integradoras tienen ventaja. Para producto digital, MVPs, modernización técnica o proyectos donde la calidad del código pesa más que el headcount, las boutique especializadas (entre 10 y 50 personas) ofrecen mejor relación coste/calidad y más ingenieros senior por euro.
¿Listo para empezar?