Cuando un proyecto de software a medida acaba mal, rara vez es por mala suerte. Suele ser por una decisión tomada antes de escribir la primera línea de código: se eligió por precio, no se exigió el código en propiedad, se fue a la reunión con la idea en la cabeza en vez de sobre el papel. Estos son los nueve errores al contratar desarrollo de software a medida que más caro salen, y la pregunta concreta que evita cada uno antes de firmar.
Por qué importa equivocarse aquí más que en otras compras
Un software a medida no se compra, se contrae. Vive años, se mete en el centro de tu operación y el día que quieres cambiar de proveedor descubres cuánto pesaban las decisiones que tomaste al principio. Por eso los errores de contratación no se notan en la primera factura: se notan a los seis, doce o veinticuatro meses, cuando ya es caro arreglarlos. La buena noticia es que casi todos se evitan con preguntas hechas a tiempo.
Los nueve errores que más se repiten
1. Elegir por el precio más bajo
Ante tres presupuestos, la tentación es ir al menor. El problema es que en software el precio bajo casi nunca es eficiencia: es un recorte que aún no ves. O han entendido un proyecto más pequeño que el real y la diferencia aparecerá como "extras" a mitad de obra, o recortan en lo que no se ve — tests, documentación, seguridad — y el sistema funciona en la demo y se rompe en producción.
Lo que importa no es la primera factura, sino el coste total de propiedad: desarrollo, más mantenimiento, más lo que cuesta cambiar de proveedor el día que haga falta. Pregunta al proveedor: "¿Qué incluye este precio en tests, documentación y seguridad, y qué queda fuera?". Si el más barato lo es porque omite todo eso, no es más barato: es más caro a plazos.
2. No pedir el código en propiedad
Este es el error que más caro sale y el que menos gente comprueba antes de firmar. Si el contrato no dice de forma explícita que el código fuente es tuyo, puede que estés pagando por usar algo que no posees. El resultado es el clásico vendor lock-in: código que solo ellos entienden, alojado donde no controlas, imposible de mover sin empezar de cero.
En Plantekia lo decimos sin matices: sin caja negra, sin vendor lock-in. El código es del cliente, documentado y portable. Pregunta al proveedor: "¿El código fuente es de mi propiedad, está en un repositorio al que yo accedo, y puedo llevármelo a otro equipo si un día quiero?". Que conste por escrito.
3. Llegar con requisitos vagos
"Queremos algo para gestionar los pedidos" no es un requisito, es un deseo. Cuanto más vago llegues, más imagina cada proveedor algo distinto, más infla unos y más recortan otros, y menos comparables son los presupuestos. La ambigüedad no desaparece: se paga después, como cambios de alcance a mitad de proyecto.
No hace falta una especificación técnica perfecta — eso es trabajo del equipo —, pero sí saber qué problema resuelves, para quién y cómo sabrás que está resuelto. Pregunta a ti mismo antes de la reunión: "¿Puedo describir en cinco frases qué hace el sistema y a quién le quita un dolor concreto?". Si no puedes, el primer entregable no es código: es un diagnóstico.
4. No exigir documentación ni tests
La documentación y los tests son lo primero que se recorta cuando alguien quiere bajar el precio, y lo que más echarás de menos después. Sin tests, cada cambio es una ruleta: arreglas algo y rompes otra cosa sin enterarte. Sin documentación, el conocimiento vive en la cabeza de una persona — y el día que esa persona no está, vuelves a depender de quien lo construyó.
Código que puedes entender, auditar y mantener no es un lujo: es la diferencia entre tener un activo y tener una dependencia. Pregunta al proveedor: "¿Qué cobertura de tests entregáis y qué documentación me queda para que otro equipo pueda continuar sin vosotros?".
5. Pagar todo por adelantado sin hitos
Pagar el cien por cien por adelantado elimina tu único punto de control. Y pagar contra un único hito final, al revés, deja todo el riesgo del lado equivocado. Lo sano es pagar por hitos: tramos asociados a entregables concretos que puedes ver, probar y aprobar antes de soltar el siguiente pago.
Eso alinea incentivos: el proveedor cobra cuando demuestra avance real, y tú mantienes capacidad de frenar si algo no encaja. Pregunta al proveedor: "¿Cómo se estructuran los pagos por hitos, qué entregable concreto corresponde a cada uno y qué pasa si un hito no cumple lo acordado?".
6. No diagnosticar antes de construir
Pedir presupuesto de software sin diagnóstico previo es como pedir presupuesto de obra sin planos: cada proveedor imagina algo distinto y los números no son comparables. Peor aún, a veces el problema real no se resuelve con el software que ibas a encargar — se resuelve ordenando un proceso o integrando dos sistemas que ya tienes.
Por eso nosotros diagnosticamos antes de proponer. Un diagnóstico breve pone sobre la mesa el mapa operativo, dónde está la fricción y qué tiene retorno real. Pregunta al proveedor: "¿Hacéis un diagnóstico antes de presupuestar, o me dais un número directamente?". Un número por teléfono, sin preguntar nada, es una bandera roja.
7. Confundir una demo bonita con un producto sólido
Una demo está diseñada para impresionar en diez minutos con datos de mentira y el camino feliz. Un producto en producción tiene que aguantar datos reales, usuarios despistados, picos de carga, errores y el paso del tiempo. Son cosas distintas, y lo que se ve en la demo es justo lo que más fácil es de falsear.
Lo que sostiene un producto está debajo de la interfaz: arquitectura, manejo de errores, seguridad, observabilidad. Pregunta al proveedor: "¿Qué pasa cuando esto recibe datos mal formados, mil usuarios a la vez o un fallo de un servicio externo? Enséñame algo en funcionamiento real, no solo el prototipo".
8. No definir cómo se mide el éxito
Si nadie acuerda al principio qué significa que el proyecto haya salido bien, al final cada parte tendrá su propia versión y la conversación acabará en quién prometió qué. "Que funcione" no es un criterio. "Que el equipo de operaciones procese los pedidos en la mitad de tiempo" o "que reduzca los errores de facturación a menos del 1%" sí lo son.
Definir el éxito en términos medibles ordena las prioridades y convierte la entrega en algo objetivo. Pregunta conjunta al arrancar: "¿Qué métrica concreta tiene que moverse para que esto haya valido la pena, y cómo la mediremos?". Sin promesas mágicas: una métrica real, acordada por escrito.
9. No preguntar quién mantiene el sistema después
El proyecto no termina cuando se entrega: ahí empieza a vivir. Habrá errores que corregir, dependencias que actualizar, cambios que pedir. Si no acuerdas desde el principio quién mantiene el sistema, en qué condiciones y a qué coste, te arriesgas a quedarte con un software vivo y sin nadie que lo cuide — o atado a quien lo hizo en condiciones que no negociaste.
Pregunta al proveedor: "Una vez entregado, ¿cómo es el mantenimiento, qué cuesta, qué tiempos de respuesta tenéis y qué pasa si decido mantenerlo con otro equipo o internamente?". La respuesta te dice si construyen para que dependas de ellos o para que seas autónomo.
Una lista corta para llevar a la primera reunión
Si solo te quedas con una cosa, que sea esta tanda de preguntas. Hazlas al proveedor antes de firmar y el ruido se separa de la señal muy rápido:
- Propiedad: ¿el código es mío, accesible y portable, por escrito?
- Calidad: ¿qué tests y qué documentación me entregáis?
- Pagos: ¿cómo son los hitos y qué entregable corresponde a cada uno?
- Diagnóstico: ¿hay un análisis previo o me dais un número sin más?
- Realidad: ¿puedo ver algo en producción, no solo una demo?
- Éxito: ¿qué métrica concreta mide que esto ha funcionado?
- Después: ¿cómo, cuánto cuesta y con quién es el mantenimiento?
Ninguna de estas preguntas es agresiva ni técnica. Son las que haría cualquiera que entiende que está contratando algo que vivirá años dentro de su operación. Un buen proveedor las agradece, porque le ahorran malentendidos. Al que le incomodan, te está dando información valiosa.
El antídoto: diagnosticar antes de proponer
Casi todos estos errores comparten la misma raíz: tomar decisiones grandes con información pequeña. Se elige proveedor sin saber qué se quiere, se firma sin saber qué se posee, se construye sin saber cómo se mide el éxito. El antídoto no es técnico, es de método: poner las cosas sobre la mesa antes de comprometerse.
Es exactamente como arrancamos cualquier proyecto de desarrollo de software a medida: diagnosticamos antes de proponer, sin caja negra y sin vendor lock-in, con código que puedes entender, auditar y mantener. Si estás valorando contratar y quieres evitar estos errores desde el principio, hablemos de tu operación y empezamos por un diagnóstico honesto de lo que de verdad necesitas — y de lo que no.