Tienes tres propuestas encima de la mesa. Las tres prometen metodología ágil, equipo senior y comunicación fluida. Los precios difieren en un 40% y los dossieres son indistinguibles: mismas palabras, mismos logos de tecnologías, mismos testimonios sonrientes. ¿Cómo eliges sin saber programar?
La respuesta corta: no comparando dossieres, sino haciendo preguntas cuyas respuestas no se pueden maquillar. Esta guía reúne las preguntas que un decisor no técnico puede hacer perfectamente, las respuestas que delatan el humo y la prueba definitiva que cuesta menos que equivocarse.
Por Qué Es Tan Difícil Comparar Propuestas
Comprar desarrollo de software es comprar algo que no existe todavía y que no puedes inspeccionar antes de pagar. Es el mercado de la información asimétrica: el proveedor sabe exactamente lo que puede entregar; tú solo puedes leer lo que promete. Por eso los dossieres convergen — todos copian el lenguaje del que mejor vende — y por eso el precio no ordena: el más caro no garantiza calidad y el más barato esconde el coste en otra parte (juniors, rotación, alcance recortado).
La estrategia correcta no es intentar valorar la tecnología — no puedes, y no hace falta — sino valorar cómo trabaja quien la aplica. Los procesos sí son inspeccionables desde fuera.
Las Preguntas que Desenmascaran el Humo
Nueve preguntas que no requieren saber de tecnología, ordenadas de menor a mayor poder de desenmascaramiento:
- «¿Quién va a programar exactamente, y puedo conocerlos?» El humo se detecta cuando la respuesta es «asignaremos los recursos adecuados». Si no hay nombres, hay bolsa de interinos. Pregunta también cuántos proyectos simultáneos lleva cada uno: la respuesta honesta suele ser dos; la sospechosa, «los que hagan falta».
- «¿Cómo veré el progreso semana a semana?» La única respuesta buena implica software funcionando que puedes tocar: una demo cada una o dos semanas, un entorno accesible. «Os enviaremos informes de avance» significa que lo verás todo al final, cuando corregir sea caro.
- «¿Qué pasa si la persona clave se va a mitad del proyecto?» Todo proveedor serio ha vivido esto y tiene respuesta: documentación, código revisado por más de una persona, conocimiento repartido. El silencio incómodo aquí es una bandera roja del tamaño de una vela de barco.
- «¿Quién es dueño del código y cuándo?» La respuesta correcta: tú, desde el primer día, en un repositorio al que tienes acceso. Si el código «se entrega al final», lo que estás comprando es un rehén.
- «¿Cómo gestionáis los cambios de alcance?» El alcance cambiará; la pregunta es cómo se cobra y cómo se comunica. Un proceso claro de cambios (estimación, aprobación, impacto en fecha) es señal de oficio. «Somos flexibles, ya lo veremos» significa que la factura lo decidirá el otro.
- «¿Qué incluye el precio y qué no?» Tests, despliegue, documentación, formación, mantenimiento del primer año. Muchas propuestas baratas son caras con el IVA invisible de todo lo que excluyen.
- «¿Puedo hablar con dos clientes cuyo proyecto salió mal?» Nadie enseña los fracasos; la forma de hablar de ellos lo dice todo. Un proveedor que puede explicar qué falló y qué cambió después es más fiable que el que «nunca ha tenido un proyecto problemático».
- «¿Qué necesitáis de mi equipo para que esto funcione?» La respuesta madura incluye tu tiempo: decisiones semanales, alguien con autoridad para priorizar, acceso a quien conoce el negocio. El proveedor que «no necesita nada de ti» está firmando para construir lo que imagina, no lo que necesitas.
- «¿Cómo medís que el proyecto va bien?» Si la métrica es «horas trabajadas», estás comprando esfuerzo, no resultado. Las buenas respuestas hablan de funcionalidad entregada, de incidencias abiertas y cerradas, de ritmo sostenido.
Banderas Verdes y Banderas Rojas
El patrón que hay detrás es simple: las banderas verdes son todas formas de transparencia; las rojas, todas formas de opacidad. Un buen proveedor te acerca al trabajo real — el código, la demo, el equipo — porque su trabajo aguanta la mirada. El malo interpone documentos bonitos entre tú y la realidad porque la realidad no aguanta la mirada.
El Precio: Lo que Esconde el Presupuesto Cerrado
El precio cerrado total transmite seguridad, pero conviene entender qué compras: el proveedor estima, añade un colchón de riesgo (legítimo) y, cuando el alcance se mueve — que se mueve siempre — el colchón se agota y empiezan los extras o los recortes silenciosos de calidad. La alternativa profesional no es el cheque en blanco: es el precio cerrado por fases cortas, donde cada fase entrega algo usable y la siguiente se estima con lo aprendido. Si quieres entender cómo se construye una cifra honesta, lo desarrollamos en cuánto cuesta el software a medida.
Y una nota sobre el descuento agresivo: un 30% de rebaja sin cambio de alcance no es eficiencia, es la confesión de que la primera cifra era inflada — o de que el proyecto se pagará con juniors.
La Prueba Definitiva: el Proyecto Piloto
Todo lo anterior filtra, pero solo una cosa verifica: trabajar juntos en pequeño antes de firmar en grande. Un piloto pagado de dos a cuatro semanas — una pieza pequeña pero real del proyecto, no un ejercicio artificial — te muestra cómo comunica el equipo, qué calidad entrega, cómo reacciona al primer cambio de criterio (pídelo: es el momento de probarlo) y si las demos eran representativas.
El proveedor que rechaza el piloto o lo convierte en batalla comercial te está diciendo algo importante: prefiere que firmes sin información. El que lo acepta de buen grado sabe que es su mejor argumento de venta. El coste del piloto es una fracción del coste de descubrir el error seis meses dentro.
Errores Comunes del Comprador
- Pedir tres presupuestos del mismo documento de una página. Con un brief vago, cada propuesta responde a un proyecto imaginado distinto y las cifras no son comparables. Invierte una semana en el brief: es la pieza con más retorno de todo el proceso.
- Elegir por precio cuando la información es simétrica en lo malo. Si las tres propuestas son igual de opacas, el barato solo es el más barato de los opacos. Filtra primero por transparencia, compara precio después.
- Firmar el proyecto completo de una vez. Sin piloto y sin fases, tu única palanca es el contrato, y los contratos se litigan, no se ejecutan. La palanca real es poder no renovar la siguiente fase.
- No reservar tiempo propio. El proyecto necesita a alguien de tu lado con horas y autoridad semanales. Si nadie tiene ese hueco, el problema no es el proveedor.
- Confundir química con capacidad. El comercial simpático no programa. Pide hablar con quien dirigirá técnicamente tu proyecto y hazle las nueve preguntas a él.
En Resumen
No puedes inspeccionar el software antes de comprarlo, pero sí el proceso de quien lo construye: quién programa, cómo se ve el progreso, de quién es el código, qué pasa cuando algo se tuerce. Las banderas verdes son transparencia y las rojas, opacidad. Y por encima de cualquier dossier, un piloto pagado de pocas semanas te dice más que todas las referencias juntas. El proveedor que resiste estas preguntas sin incomodidad es probablemente el que buscas; el que las esquiva te ha ahorrado un disgusto.
Si estás comparando propuestas y quieres una segunda lectura sin conflicto de interés — o directamente una propuesta que aguante las nueve preguntas — hablemos →
Sigue leyendo: Software a medida vs SaaS: cuándo construir y cuándo comprar.