Cómo Elegir Proveedor Tecnológico sin Arruinarte

El 68% de los proyectos de software externalizados en España terminan costando más del doble de lo presupuestado. No porque la tecnología falle, sino porque la empresa eligió proveedor mirando una sola variable: el precio por hora. Es como elegir cirujano por el que cobra menos por minuto en quirófano. Suena lógico sobre el papel. En la práctica es una forma cara de arruinarse.

Llevamos años viendo el mismo patrón. Una empresa necesita digitalizar un proceso, pide tres presupuestos, elige el más barato y dieciocho meses después tiene un sistema a medio funcionar, un proveedor que ha rotado al equipo dos veces y una factura que supera con creces la del presupuesto "caro" que descartaron al principio.

El problema no es que no haya buenos proveedores en España. Los hay. El problema es que el proceso de selección que usan la mayoría de empresas está diseñado para elegir mal.

El mercado español del software: tres categorías que nadie te explica

Cuando una empresa busca un proveedor tecnológico en España, se encuentra con un mercado que parece homogéneo desde fuera pero que funciona de maneras muy distintas por dentro. Hay tres modelos operativos, y entenderlos cambia completamente la conversación.

Las consultoras de cesión de recursos. Son empresas que básicamente alquilan cuerpos. Tienen una base de datos de CVs, un departamento comercial agresivo y un margen que sale de la diferencia entre lo que te cobran por hora y lo que le pagan al desarrollador. El desarrollador no elige estar en tu proyecto. Le han asignado porque estaba libre. Si mañana sale otro proyecto que paga mejor, lo mueven y te ponen a otro. Tu proyecto es una línea en un Excel de ocupación. Estas empresas no venden resultados. Venden horas. Y cuantas más horas necesites, mejor les va. Piensa en eso un momento.

Las factorías de software. Un paso por encima. Aquí sí hay equipos más o menos estables, metodología de proyecto y un delivery manager que hace seguimiento. Te presupuestan un proyecto cerrado con alcance definido. El problema es el modelo de propiedad: construyen el software según las especificaciones que les des, te lo entregan y se van. Si las especificaciones estaban mal, el software está mal. Si el negocio cambia a los seis meses, el software no cambia con él. Es un modelo transaccional. Funciona para proyectos con requisitos estables y bien definidos. No funciona para casi nada que tenga que ver con la realidad de una empresa en movimiento.

Los partners de producto. Este es el modelo menos frecuente y el más difícil de encontrar. Son empresas que se implican en el resultado de negocio, no solo en la entrega técnica. Entienden tu operación, participan en definir qué hay que construir y se responsabilizan de que el software genere el impacto esperado. No te venden horas ni proyectos cerrados. Te venden capacidad de ejecución tecnológica integrada en tu empresa. Construyen activos que quedan como propiedad del cliente. En SAUCO lo llamamos el enfoque FDE, y es la razón por la que existe la empresa.

La mayoría de procesos de compra no distinguen entre estos tres modelos. Meten a los tres en la misma comparativa, piden precio por hora y eligen. Es como comparar un taxi, un autobús y un copiloto de rally usando solo el coste por kilómetro.

La trampa del precio/hora y por qué tu CFO debería odiarla

Vamos a hacer números. Es lo único que funciona para desmontar esta trampa.

Supón que necesitas construir un sistema de gestión de pedidos integrado con tu ERP. Pides presupuesto a dos proveedores.

Proveedor A: te ofrece un equipo de tres perfiles con poca experiencia a 32 €/hora cada uno. Estimación: 6 meses. Coste estimado: 3 personas × 32 €/h × 160 h/mes × 6 meses = 92.160 €.

Proveedor B: te ofrece un equipo senior con perfiles full-stack a una media de 72 €/hora. Estimación: 3,5 meses. Coste estimado: 72.800 €.

El CFO mira el precio por hora y ve 32 contra 72 de media. Elige A. Evidentemente.

Excepto que no. Porque los perfiles del Proveedor A necesitan supervisión que no tienen. A los dos meses hay que rehacer la arquitectura de datos porque no contemplaron concurrencia. A los cuatro meses rotan a uno de los tres porque "lo necesitan en otro proyecto". El sustituto tarda tres semanas en ponerse al día. El proyecto se alarga a nueve meses. Se añade un cuarto recurso para "acelerar". El coste real termina en 148.000 € y el sistema sale con defectos que requieren otros 20.000 € en correcciones durante el primer año.

El Proveedor B entregó en cuatro meses, ligeramente por encima de estimación. Coste final: 83.200 €. Sistema estable. Sin rehacer.

Diferencia real: 84.800 €. A favor del proveedor "caro".

Lo que más me sorprende cuando veo esto es que no es un caso extremo. Es el caso medio. Los datos de Standish Group llevan décadas mostrando que los proyectos con mayor seniority en el equipo tienen tasas de éxito significativamente mayores. Pero el proceso de compra sigue optimizando para la variable equivocada.

El precio por hora mide el coste del input. No mide el valor del output. Tu empresa no necesita comprar horas de programación. Necesita comprar capacidad de resolver problemas de negocio con tecnología.

Siete preguntas que tu proveedor actual no quiere que hagas

Si estás evaluando proveedores ahora mismo, o si quieres auditar al que ya tienes, estas siete preguntas separan a los que construyen activos de los que facturan tiempo. Hemos desarrollado una guía completa de criterios de selección con más detalle, pero estas son las que más incomodan.

1. ¿Puedo hablar con el equipo técnico que trabajará en mi proyecto antes de firmar? Si la respuesta es "todavía no hemos asignado el equipo", huye. Significa que tu proyecto es un slot en un calendario de recursos, no una decisión técnica.

2. ¿Quién es el propietario del código fuente desde el día uno? No al final del proyecto. No cuando se pague la última factura. Desde el primer commit. Si el contrato dice otra cosa, estás financiando un activo que no te pertenece.

3. ¿Cuál es el nivel de experiencia real del equipo propuesto? No el que pone en el CV. El verificable. Pide perfiles concretos con años de experiencia en proyectos comparables al tuyo. Un equipo donde solo hay un perfil experimentado rodeado de gente que está aprendiendo no es un equipo senior — es formación subvencionada por tu factura.

4. ¿Qué pasa cuando el proyecto se entrega? Esta pregunta revela más que cualquier otra. Si la respuesta es "firmamos un contrato de mantenimiento aparte", el proveedor no se hace responsable de lo que construye más allá de la entrega. El software no termina cuando se despliega. Empieza.

5. ¿Pueden darme tres referencias de proyectos similares al mío donde pueda hablar con el cliente directamente? No testimonios en la web. Llamadas reales con personas reales que confirmen alcance, plazo y resultado. Si no pueden o no quieren, ya tienes tu respuesta.

6. ¿Cómo gestionan el conocimiento cuando alguien del equipo se va? La rotación en el sector tech español es alta. Un buen proveedor tiene documentación, pair programming, code reviews y procesos que minimizan el impacto. Uno malo te dice "no se preocupe, eso no va a pasar".

7. ¿Habéis dicho que no a un proyecto en los últimos seis meses? Un proveedor que acepta todo no tiene criterio. Los buenos dicen que no cuando el proyecto no encaja con su capacidad o su modelo. Los que dicen sí a todo están vendiendo cuerpos, no soluciones.

El portfolio inflado: cómo detectar proyectos fantasma

Abres la web de un proveedor y ves logos de empresas conocidas. Telefónica. Repsol. Inditex. Impresiona. Hasta que te enteras de que su contribución a ese proyecto fue poner a un desarrollador durante dos meses dentro de un equipo de 40 personas gestionado por otra empresa.

Esto es más frecuente de lo que parece. Las consultoras de cesión, por definición, colocan personas en proyectos ajenos. Cada proyecto donde colocan a alguien se convierte en un "caso de éxito" en su portfolio. Técnicamente no mienten. Participaron. Pero la diferencia entre "participamos en el proyecto de transformación digital de [gran empresa]" y "lideramos y entregamos el sistema completo" es la diferencia entre ser extra en una película y ser el director.

Hay señales que delatan los portfolios inflados.

Ausencia de detalle técnico. Si la descripción del proyecto habla de "transformación digital" y "soluciones innovadoras" pero no menciona ni una tecnología, ni una métrica de resultado, ni un reto concreto que resolvieron, probablemente no resolvieron nada concreto.

Logos sin contexto. Mostrar el logo de una multinacional sin explicar qué hicieron exactamente, con cuántas personas y durante cuánto tiempo es marketing, no es portfolio.

Proyectos que no puedes verificar. Pide hablar con alguien del cliente. Si el proveedor pone excusas, el proyecto o no existió como lo cuentan o el cliente no quedó contento.

El mismo proyecto descrito de tres maneras distintas. Lo he visto: un mismo engagement aparece en la web como "desarrollo de plataforma", en la propuesta comercial como "consultoría estratégica" y en LinkedIn como "transformación end-to-end". Tres líneas en el portfolio que en realidad son una sola, y modesta.

Un portfolio real tiene proyectos con nombres, números y consecuencias. "Construimos el sistema de picking del almacén X. Reducimos el tiempo de preparación de pedido de 12 minutos a 4. Proyecto de 5 meses con equipo especializado." Eso es verificable. El resto es humo.

Como documentamos en Low-Code es Deuda Técnica con Interfaz Bonita, en el software lo que importa es qué queda cuando el proveedor se va. Si lo que queda es un activo tuyo que funciona, eligieron bien. Si lo que queda es una dependencia que no puedes cortar, eligieron mal.

Por qué "Forward Deployed" cambia la ecuación

Todo lo anterior describe un mercado roto. El modelo FDE existe precisamente porque ese mercado no resolvía el problema real.

La idea detrás del El Nacimiento del FDE es sencilla: en vez de que el cliente especifique lo que necesita y el proveedor lo construya en remoto, el ingeniero se integra en la operación del cliente. Ve el problema de primera mano. Entiende las restricciones reales, no las que alguien escribió en un documento de requisitos hace tres meses.

El ingeniero es responsable del resultado, no de la entrega. En una consultora de cesión, el éxito se mide en horas facturadas. En una factoría, en funcionalidades entregadas. En el modelo FDE, el éxito se mide en impacto operativo. ¿El almacén procesa más pedidos? ¿El equipo comercial cierra más rápido? ¿El proceso que antes tardaba dos días ahora tarda veinte minutos? Si no, el trabajo no está hecho, da igual cuántas líneas de código se hayan escrito.

No hay "toma de requisitos" separada de la construcción. El FDE observa, prototipa, valida con usuarios reales y ajusta. El ciclo entre "entender el problema" y "entregar la solución" se comprime de meses a días. Los requisitos no se recogen en una reunión; se descubren en la trinchera.

El código es tuyo desde el minuto uno. Todo se construye en los repositorios del cliente, con tecnologías estándar, documentado para que cualquier equipo pueda continuarlo. Si mañana quieren prescindir de nosotros y montar equipo interno, pueden hacerlo sin reescribir nada.

En SAUCO aplicamos este modelo porque hemos visto desde dentro lo que pasa con los otros. Hemos recogido proyectos abandonados a medio hacer por consultoras de cesión. Hemos migrado sistemas entregados por factorías que el cliente no podía mantener. Y en todos los casos, el coste de arreglar era mayor que el de haberlo hecho bien desde el principio.

No es el modelo más fácil de vender. Requiere ingenieros que sepan hablar con un director de operaciones y también escribir código en producción. Requiere decir que no a proyectos donde solo necesitan un cuerpo sentado. Pero es el modelo que genera activos reales para el cliente y relaciones que duran años, no meses.

¿Estás evaluando proveedores o quieres entender mejor cómo funciona el modelo FDE? Consulta nuestra guía completa de criterios de selección para una comparativa estructurada, o lee nuestro manifiesto para entender por qué construimos SAUCO de esta manera.