Cómo elegir partner de desarrollo de software a medida: red flags, qué preguntar y cómo evaluar propuestas

La pregunta que más nos llega por referido no tiene nada que ver con tecnología. Es esta: cómo sé que el proveedor que voy a contratar es el adecuado. La hace alguien que nunca ha contratado desarrollo a medida, que tiene tres presupuestos sobre la mesa con variaciones del 400% entre el más barato y el más caro, y que no sabe a qué se debe esa diferencia. El miedo es razonable: pagar 30.000 € y quedarse con un sistema que no funciona es perfectamente posible, y nadie quiere ser quien lo firmó.

Este post no intenta convencerte de contratar a VisibleSoft. Intenta darte herramientas para descartar a quien no debas contratar, sea quien sea. Las decisiones malas se evitan con preguntas, no con instinto. Si después de leerlo decides que prefieres a un competidor nuestro porque encaja mejor con tu caso, este texto habrá hecho su trabajo.

La asimetría de información, el problema de fondo

La razón por la que estas contrataciones salen mal con tanta frecuencia es estructural: el cliente no sabe lo suficiente del oficio como para evaluar lo que le venden, y el proveedor sabe demasiado bien cómo presentarlo. El cliente compara precios. El proveedor cuenta meses-persona, perfiles, riesgos. Cuando los dos lados hablan idiomas distintos, gana el que mejor vende, que no siempre es el que mejor ejecuta.

La única forma de equilibrarlo es entrar a la negociación con preguntas que el proveedor no esperaba que hicieras. No tienen que ser técnicas: tienen que ser específicas sobre cómo trabaja, qué garantiza, y qué pasa cuando algo se tuerce.

Las 7 red flags que descartan a un proveedor en la primera reunión

Si en la primera conversación detectas cualquiera de estas señales, descarta. No te debates sobre matices, no te quedes con dudas, no preguntes una segunda vez. Cada una se ha repetido lo suficiente en proyectos fracasados como para considerarla criterio de salida.

1. Te dan un presupuesto cerrado en la primera llamada. Es imposible cotizar honestamente un proyecto de software sin entender primero el problema. Quien lo hace, o está pegando un precio estándar que no se ajusta a tu caso, o está poniendo una cifra baja para entrar y subirla después por cambios de scope. Un partner serio empieza con un discovery pagado (corto, acotado, con entregable concreto) y solo después presenta una propuesta.

2. Comprometen tecnología antes de entender el problema. “Te lo hacemos en Angular y .NET”, o “te lo montamos con Laravel y MySQL”, dicho en la primera reunión cuando todavía no saben qué tienes que hacer ni cómo está montada tu infraestructura. Significa que la tecnología la eligen porque es la que dominan, no porque es la que tu caso requiere.

3. La propuesta es larga en marketing y corta en técnica. 30 páginas con metodologías propias, fotos de equipos sonrientes, sellos de calidad y diagramas de “nuestro proceso ágil”. Cero detalle sobre el equipo concreto que asignarán, las fases reales del proyecto y los entregables semanales. La hojarasca disimula que no han pensado el proyecto.

4. No queda claro quién va a desarrollar de verdad. “Tenemos un equipo senior”, “asignaremos perfiles cualificados”. Si pides nombres y perfiles concretos y no te los dan, casi siempre es porque el comercial que te atiende no es el que va a programar, y el que va a programar todavía no sabe que va a tocarle. En proyectos pequeños y medianos, esto suele acabar con tu cuenta cubierta por juniors mientras los seniors atienden a clientes más grandes.

5. No tienen portfolio verificable. Sin webs reales que puedas visitar, sin nombres de clientes que puedas contactar, sin casos de éxito con resultados medibles. Los proveedores serios tienen contratos de confidencialidad con algunos clientes, sí, pero no con todos. Si la respuesta es “no podemos enseñarte nada por confidencialidad”, desconfía: hay un punto medio entre exponer todo y no tener nada que mostrar.

6. No te dejan hablar con clientes anteriores. Variante de la anterior, más grave. Un partner que ha entregado bien proyectos en los últimos años tiene clientes dispuestos a dedicar 20 minutos a contártelo por teléfono. Si te dan excusas para evitar esa llamada, hay algo que no quieren que sepas.

7. Insisten en que el código vive en sus servidores y ellos te lo mantienen. Esto es lock-in puro. Quieren que dependas de ellos a perpetuidad, no porque den mejor servicio, sino porque salir cueste más que aguantar. El código debe ser tuyo desde el día uno, en un Git que tú controlas, con documentación suficiente para que cualquier otro equipo pueda continuar el trabajo si quisieras cambiar.

Las señales verdes: cómo se reconoce a un partner serio

El reverso de lo anterior, pero merece sacarlo a la luz porque los buenos partners no siempre brillan en una primera reunión. A veces son más callados, hacen más preguntas, y al cliente le parecen menos vendedores que la competencia. Eso suele ser buena señal.

• Te hace más preguntas que respuestas en la primera reunión. Una conversación con un partner serio termina contigo agotado de explicar tu negocio, no con tu cabeza llena de promesas técnicas.
• Documenta lo que entendió y te lo manda escrito. En las 48-72 horas siguientes, te llega un resumen de lo conversado, con tu problema reformulado en sus palabras. Si ves que entendió mal algo, hay tiempo de corregirlo antes de hacer ninguna propuesta.
• Te dice “esto no, porque…” con cosas concretas. No todo cliente es buen cliente para todo proveedor. Si encajas en lo que hacen, te lo dirá. Si no, también. Esa franqueza ahorra meses de fricción.
• Plantea fases con entregas, no un único hito final. Cada 2-4 semanas hay algo concreto que ver y validar. Te permite parar el proyecto en cualquier momento sin perder todo lo invertido.
• Habla de propiedad del código sin que tengas que sacarlo tú. El tema del código y del repositorio aparece en la propuesta, no toca arrancárselo en la negociación.
• Reconoce lo que no sabe. “Esto no lo hemos hecho antes, te lo cotizamos con un margen de incertidumbre del 20% y lo afinamos en el primer sprint”. Mucho mejor que un “sí, eso lo hacemos” que después se traduce en bugs y prórrogas.

Tipos de partner según tu necesidad

No todos los proveedores sirven para lo mismo. Antes de buscar, conviene saber qué tipo encaja con tu proyecto. Esta tabla es honesta sobre los matices, incluyendo dónde encaja un perfil como el nuestro:

Tipo	Cuándo conviene	Cuándo NO conviene
Freelance / solo dev	Proyectos pequeños (menos de 3 meses), tareas muy acotadas, MVPs validables rápido. Cuesta menos por hora.	Proyectos largos con riesgo de baja por enfermedad o de pérdida del contacto. Sistemas críticos para el negocio.
Agencia grande (50-200 empleados)	Proyectos grandes (más de 200.000 €), múltiples equipos en paralelo, necesidad de cobertura 24/7. Cuando el cliente es una corporate.	PYMEs con presupuesto medio. Te dejan en la cola y te asignan los perfiles que sobran de cuentas grandes.
Boutique / estudio pequeño (5-15 personas)	PYMEs con proyectos medianos (30.000-200.000 €), interlocución directa con quien decide y quien ejecuta. Compromiso real con el resultado.	Cuando necesitas cobertura 24/7 garantizada, equipos enormes en paralelo, o stacks tecnológicos que el estudio no maneje.
Equipo interno propio	Cuando el software es tu core business o cuando el volumen justifica 3+ ingenieros a tiempo completo durante años.	Cuando el proyecto es puntual o no tienes capacidad de retener talento técnico contra grandes empresas.

El error más típico de la PYME española es contratar a una agencia grande pensando que “más empleados = más garantía” y acabar siendo el cliente C del comercial. El segundo error es contratar al freelance más barato porque encajaba en presupuesto, y descubrir 4 meses después que se ha quedado sin tiempo para tu proyecto.

Las 8 preguntas que conviene hacer en la primera reunión

Para descartar perfiles malos antes de pedir propuesta formal:

1. ¿Quién va a escribir el código? Dame nombres y perfiles concretos. Si no pueden, no han pensado el proyecto.
2. ¿Qué pasa si esa persona se va de la empresa a mitad del proyecto? Cómo gestionan el knowledge transfer. Si no tienen respuesta, asume que será problema tuyo.
3. ¿Puedo hablar con dos clientes vuestros que hayan terminado un proyecto similar al mío? La respuesta debe ser sí, y los contactos deben llegar en una semana.
4. ¿Cómo gestionáis los cambios de scope durante el proyecto? Cualquier proyecto serio tiene cambios. Lo que distingue al buen partner es cómo los maneja: con un proceso claro de change request, no con sorpresas en factura.
5. ¿Cómo se cierra el proyecto si decidimos parar antes de tiempo? Esto se llama cláusula de salida. Si no tienen redactada una, escríbela tú. El contrato no debe atarte a continuar contra tu voluntad.
6. ¿De quién es el código y cómo me lo entregáis al final? Tuyo, en un Git que tú controlas, con README y guía de despliegue. Cualquier otra respuesta es un problema.
7. ¿Es obligatorio contrataros el mantenimiento al terminar? No debe serlo. Te ofrecen mantenimiento como opción, no como condición.
8. ¿Qué tipo de proyectos rechazáis? Quien dice que sí a todo, miente o está desesperado. Un partner serio tiene criterios para no aceptar ciertos clientes.

Cómo evaluar una propuesta de verdad

Cuando ya tengas las propuestas formales encima de la mesa, mira más allá del precio. Compara estos seis bloques en cada una:

Claridad de scope. ¿La propuesta describe el problema con tus palabras, o con palabras genéricas? ¿Hay una lista concreta de funcionalidades y de qué queda fuera? Las propuestas vagas se traducen en facturas inesperadas.

Fases y entregas. Debe haber al menos 3-4 hitos con fecha y entregable. Si solo hay “inicio - desarrollo - entrega final”, no han desglosado el riesgo.

Equipo asignado. Nombres, perfiles, dedicación (a tiempo completo, a tiempo parcial). Si pone “se asignarán los perfiles adecuados”, asume que aún no lo han pensado.

Propiedad del código y entrega. Cláusula explícita de cesión de propiedad intelectual y de entrega del repositorio. Si no aparece, exige que se añada antes de firmar.

Plan de mantenimiento opcional. Detallado, con precio independiente, con SLA si aplica. Y, como decíamos, opcional. No condicionado.

Salida del proyecto. Qué pasa si decides parar al hito 2 de 5. Qué pasa si quieres cambiar de proveedor. Qué documentación recibes y en qué formato.

Si dos propuestas tienen precios muy distintos pero cubren igual estos seis bloques, la diferencia suele estar en el equipo asignado. Pregunta. Es legítimo pedir explicación del precio cuando ya tienes propuesta formal.

La fase de selección: cómo decidir entre 2-3 finalistas

Cuando tengas finalistas, lo que mejor funciona es una prueba pequeña pagada. No una propuesta gratuita (que se cobra de otro lado), sino una mini-fase real con presupuesto acotado: 4.000-8.000 €, 2-3 semanas, con entregable verificable. Puede ser una auditoría del sistema actual, un POC de un módulo crítico, una propuesta de arquitectura escrita y defendida.

En esa fase ves cosas que no se ven en reuniones: cómo se comunican, si cumplen plazos pequeños, si la calidad del entregable es la que prometieron. Quien apruebe esa fase es a quien contratas el proyecto grande. Quien falle, lo descartas habiendo perdido 4.000 € en lugar de los 40.000 € que habrías perdido eligiéndolo a ciegas.

La pregunta paralela que conviene tomar antes de seleccionar a nadie es si tu caso justifica una aplicación a medida o si un SaaS específico lo cubre. La cubrimos en Software a medida vs SaaS: cuándo elegir cada uno. Si lo que necesitas es modernizar un sistema heredado, también hay matices propios que afectan al perfil de partner que te conviene: Modernizar un ERP legacy: cuándo conviene migrar y cuándo no. Y si tu punto de partida es un Excel central, aquí cubrimos cómo planteamos la migración.

Si quieres una conversación honesta

Si has llegado hasta aquí y crees que VisibleSoft puede encajar con tu caso, hablamos sin compromiso. Si no, también: el post sigue sirviendo para evaluar a quien decidas contratar. Una buena decisión de partner suele ahorrar más dinero que negociar un descuento del 10% con el equivocado.

Recursos

• Software a medida vs SaaS: cuándo elegir cada uno: la decisión previa a buscar partner.
• Modernizar un ERP legacy: cuándo conviene migrar y cuándo no: si tu caso es modernización, no construcción desde cero.
• Migrar de Excel a una aplicación a medida: si partes de Excel y no sabes por dónde empezar.
• Servicios de VisibleSoft: qué tipo de proyectos asumimos y bajo qué condiciones trabajamos.
• Reserva un diagnóstico gratuito