Cómo elegir una empresa de desarrollo de software cuando no sabes leer código

Una guía para founders no técnicos: las señales que de verdad predicen si tu proyecto va a salir, los criterios que parecen importantes y no lo son, y las cuatro preguntas que hacer antes de firmar nada.

Entraste a tres reuniones comerciales esta semana. Las tres empresas fueron cercanas, profesionales y seguras. Las tres dijeron que tu proyecto era totalmente viable. Las tres mandaron un deck con un muro de logos, una nota de cinco estrellas en Clutch y un portafolio de apps parecidas a la tuya. El viernes tenías tres propuestas sobre la mesa, dos de ellas con menos del 15% de diferencia de precio, y ninguna idea real de cómo elegir.

Esta es la parte difícil de elegir una empresa de desarrollo de software: los datos que puedes ver son los mismos que todo proveedor aprendió a pulir, y el dato que más importa, si van a entregar de verdad un software que funciona y que no tengas que estar cuidando, queda invisible hasta que ya pagaste. Así que la respuesta corta es esta. Eliges una empresa de desarrollo de software por cómo se comporta antes de que el dinero cambie de manos, no por lo que te muestra. Cómo define el alcance del trabajo, cómo discrepa de tus ideas, cómo habla de costo y de riesgo, y qué hace cuando le preguntas algo que no sabe responder con claridad. Esos cuatro comportamientos predicen la entrega. El portafolio no.

Podemos decirlo porque somos una empresa de desarrollo de software. Lo que sigue es la guía del comprador escrita desde dentro de la sala, incluidas las partes que nuestro propio sector preferiría no publicar, porque la mitad de lo que pasa por proceso comercial termina en la lista de señales de alarma.

La trampa en la que te mete cualquier otra guía

Busca esta pregunta y vas a encontrar una docena de artículos, casi todos escritos por empresas de software, que te dicen que evalúes tres cosas: portafolio, experiencia técnica y precio. Ese consejo no es tanto incorrecto como inútil, porque las tres son fáciles de maquillar y ninguna sobrevive al contacto con tu proyecto real.

Un portafolio muestra el trabajo del que la empresa está más orgullosa, capturado en su mejor momento, sin ninguna mención de qué proyectos llegaron seis meses tarde o fueron rehechos por el siguiente proveedor. “Experiencia técnica” es una lista de logos: React, AWS, Python, Kubernetes. Toda empresa de tu shortlist tiene la misma lista, y no tienes forma de saber si usan esas herramientas bien o solo saben deletrearlas. Y el precio, el único número que te sientes capaz de comparar, es el dato más engañoso de todos, por razones que ya veremos.

El problema de fondo es que este modelo te pide juzgar a la empresa por artefactos. Un founder no técnico no puede juzgar un artefacto de software de forma fiable. No lees el código, no distingues una arquitectura limpia de una frágil, y no sabes si esa app preciosa del portafolio es mantenible por debajo o está sujeta con cinta. Si tu método de elección exige evaluar cosas que no puedes ver, no tienes un método. Tienes un volado con pasos de más.

Así que deja de tratar de calificar el software. Califica el comportamiento. El comportamiento es algo que un founder no técnico lee muy bien, porque aparece en lenguaje claro, en reuniones, en cómo se responden las preguntas. Y el comportamiento antes del contrato es el mejor predictor disponible del comportamiento después de él.

Lo que de verdad predice si tu proyecto va a salir

Cuatro comportamientos, observables en las dos primeras conversaciones, dicen más que cualquier portafolio.

Cómo definen el alcance de tu proyecto. Entrega la misma idea suelta a dos empresas. Una vuelve con una cotización. La otra vuelve con preguntas: quién es el usuario, qué pasa en el camino que sale mal, con qué se conecta esto, cuál es la única funcionalidad que tiene que funcionar el día uno. La segunda empresa es más molesta de tratar en la primera semana y mucho más barata de trabajar en el sexto mes. Los requisitos vagos son donde mueren los proyectos de software, y el trabajo de definir el alcance antes de contratar a nadie es exactamente lo que una buena empresa exige. Un estudio que toma tu brief a medias y te pone un precio de inmediato te está avisando que va a construir lo que le digas y a cobrarte el retrabajo. La forma en que un estudio define el alcance es un anticipo de cómo va a llevar el proyecto. Uno bueno trata el alcance como el trabajo más importante, no como una formalidad antes del trabajo de verdad.

Cómo te llevan la contraria. Fíjate en lo que pasa cuando propones algo que es mala idea. Todo founder propone algunas. Pides una funcionalidad que duplica el plazo y no sirve a nadie, o describes una arquitectura que oíste en un podcast. Un proveedor que optimiza para la venta asiente y la agrega a la cotización. Un socio te dice que es mala idea y explica por qué, aunque discrepar de ti sea la jugada comercial más arriesgada. La disposición a perder un poco de simpatía para ahorrarte dinero es la señal más subestimada de esta lista. Una empresa que no te dice que no antes de que pagues nunca te dirá que no después, y un proyecto donde nadie dice que no es un proyecto que se infla. Esta es la diferencia entre un socio tecnológico y una caja negra: un socio discute contigo.

Cómo hablan de costo y de incertidumbre. Pregunta cuánto va a tardar y cuánto va a costar. La respuesta honesta incluye un rango, algunos supuestos y la admisión de que el número se va a mover a medida que aprendes cosas. La respuesta diseñada para ganar el contrato es una cifra única y segura, sin matices. Estimar software es genuinamente difícil, y una empresa que finge que es fácil o no tiene experiencia o te está mintiendo para cerrarte. Steve McConnell, autor de Code Complete, dedicó su carrera a un solo punto: las estimaciones tempranas cargan una incertidumbre enorme. Un estudio que respeta esa incertidumbre en voz alta va a manejar tu presupuesto con honestidad. Uno que la entierra va a descubrirla después, en tu factura.

Qué hacen cuando no saben. Haz una pregunta un poco fuera de su zona de confort. Fíjate si dicen “no sé, déjame revisar” o si generan una respuesta segura en el momento. La frase “no estoy seguro, lo averiguo” es una de las cosas más tranquilizadoras que un proveedor puede decir, porque muestra que distingue lo que sabe de lo que está adivinando, y esa distinción es todo el trabajo. Las personas que estás contratando van a pasar años tomando decisiones que no puedes verificar. No estás apostando a si tienen todas las respuestas. Estás apostando a si serán honestos sobre cuáles respuestas no tienen.

Los criterios que parecen importantes y no lo son

Algunos de los datos que te dijeron que pesaras mucho merecen casi ningún peso.

El muro de logos. Clientes de marca significan que una empresa puede conseguir clientes de marca. No te dice nada sobre si tu proyecto, que es más pequeño y menos prestigioso, va a recibir a sus seniors o a su banca. A veces el logo famoso es incluso una advertencia: vas a ser la cuenta que recibe al equipo junior mientras los cracks atienden a la marca grande.

Premios y sellos de directorio. Una nota alta en un directorio de proveedores depende de a cuántos clientes felices la empresa les pidió dejar reseña, más, en algunos casos, cuánto gasta con el propio directorio. Es una salida de marketing, no una medida de calidad. Trátala como tratarías un sello de “Lo mejor de” en la vitrina de un restaurante: débilmente positivo, fácil de manipular, y no una razón para elegir.

Tamaño del equipo. Una empresa de 200 personas no es más segura que un estudio de 12. Las casas más grandes te dan proceso y continuidad y, a menudo, más capas entre tú y quien de verdad escribe tu código. Las más pequeñas te dan acceso directo y atención senior y, a menudo, más riesgo de persona clave. Ninguno es la respuesta correcta. El tamaño correcto depende de tu proyecto, y una empresa que te dice que más grande siempre es más seguro está vendiendo su propia plantilla.

El pitch del stack. Si una empresa empieza por lo moderno y novedoso que es su stack, desconfía. Las herramientas aburridas y probadas suelen ser la elección correcta para un producto temprano, y un estudio que corre tras el framework más nuevo a veces está resolviendo el currículum de sus ingenieros, no tu mantenibilidad. Quieres una empresa que elige tecnología por tu problema, no por lo que está de moda. Ya escribimos sobre la diferencia entre tecnología emergente como herramienta y como religión en nuestra pieza sobre auditoría de código; el mismo test aplica al elegir quién construye.

El 80/20 de elegir una empresa de desarrollo de software

Hay una versión del principio de Pareto que encaja bien con esta decisión: una fracción pequeña de las señales carga la mayor parte del peso predictivo. Si solo tuvieras tiempo de evaluar dos cosas, evalúa estas.

Primero, cómo manejan la brecha entre lo que pediste y lo que de verdad necesitas. Las mejores empresas pasan la primera conversación estrechando tu proyecto, no inflándolo. Encuentran la versión de tu idea que cuesta la mitad y prueba el mismo riesgo. Un proveedor que solo agrega alcance está optimizando para su factura. Un socio que resta alcance está optimizando para tu resultado, y esa orientación, una vez que la ves, es difícil de fingir.

Segundo, cómo responde un cliente real suyo a una pregunta específica. No le preguntes a sus referencias si quedaron contentas. Todo el mundo dice que sí. Pregunta: “¿Qué salió mal, y cómo lo manejaron?” Todo proyecto real tiene una semana mala. La referencia que puede describir un problema y una recuperación está describiendo una empresa que dice la verdad bajo presión. La referencia que insiste en que nunca nada salió mal o nunca entregó nada difícil, o no está siendo sincera. Esa única pregunta hace más trabajo que el resto de la llamada junto.

Las cuatro preguntas que hacer en la primera reunión

Lleva estas a la primera conversación. Las respuestas, y la comodidad con que se dan, van a separar tu shortlist rápido.

“Cuéntame un proyecto que se salió de control y qué hicieron al respecto.” Estás probando honestidad y si han entregado algo lo bastante difícil como para salirse de control.

“Si tuvieras que cortar mi alcance a la mitad para entrar en el presupuesto, ¿qué cortarías y por qué?” Estás probando si entienden tu producto lo suficiente para tener opinión sobre su núcleo, y si van a pensar en trade-offs en vez de solo venderte todo.

“¿Quién específicamente va a trabajar en esto, y qué pasa si esa persona se va?” Estás probando el riesgo de persona clave y si recibes el equipo del pitch o uno distinto, más barato, después de firmar. Depender de un único desarrollador es un costo real, y una empresa seria tiene respuesta para eso.

“¿Cómo voy a saber si el proyecto está fuera de rumbo antes de que sea tarde para arreglarlo?” Estás probando si van a hacer el trabajo visible para un dueño no técnico, o si vas a estar a ciegas hasta que un plazo se caiga. La respuesta debería incluir algo que de verdad puedas ver cada semana, no un color de estado en una herramienta que no abres.

Una empresa que responde estas cuatro con limpieza, sin erizarse, probablemente ya tuvo estas conversaciones antes y sobrevivió a ellas. Eso es la mayor parte de lo que estás buscando.

Más barato es una señal, no un ahorro

La cotización que llega un 40% por debajo de las otras no es un descuento. Es información. O esa empresa definió tu alcance de forma más superficial que las demás, y la diferencia va a reaparecer como órdenes de cambio una vez que estés amarrado, o piensa poner en tu construcción a gente más barata y con menos experiencia, o todavía no entiende el trabajo lo suficiente para ponerle precio. De vez en cuando una cotización baja refleja eficiencia genuina. Más a menudo refleja un malentendido que vas a pagar por corregir.

La cotización cara tampoco está automáticamente en lo correcto. Pero cuando los precios divergen mucho, la reacción correcta no es tomar el barato. Es pedirle a cada empresa que explique su número, porque la explicación te dice quién entendió de verdad el proyecto. El precio es más útil como pregunta, menos útil como respuesta. Detallamos la versión más profunda de esto en nuestra pieza sobre cómo se ponen precio los proyectos subcontratados y dónde se esconden las sorpresas.

Cómo verificar lo que no puedes leer por ti mismo

Sigues sin poder leer el código. Así que incorpora la verificación al contrato en vez de tratar de hacerla en el proceso comercial.

Empieza con una pieza pequeña, pagada y acotada de trabajo real antes de comprometerte con la construcción completa. Un sprint de discovery, una primera funcionalidad, una rebanada funcional del producto de verdad. Un mes de colaboración real enseña más sobre una empresa que diez horas de llamadas, y es un seguro barato contra un error de seis meses. Cómo se comportan dentro de esa pequeña tarea, si se comunican, si entregan lo que dijeron que entregarían, si el software funcionando coincide con la demo, es lo más parecido a una garantía que vas a obtener.

Después, antes de escalar o en cualquier hito grande, puedes tener a alguien independiente mirando lo que se construyó. No necesitas leer código para encargar una auditoría de código y obtener una lectura en lenguaje claro de si el cimiento es sólido. Una empresa segura recibe bien esa segunda opinión. Una nerviosa se resiste, y la resistencia es su propia respuesta.

Elegir una empresa de desarrollo de software nunca va a ser una apuesta segura, porque estás comprando algo que no puedes inspeccionar del todo a alguien que acabas de conocer. Pero puedes dejar de tratar de calificar el software y empezar a calificar a las personas, a la luz del día, antes de gastar un peso. La empresa que define el alcance con cuidado, discute contigo, pone precio con honestidad y admite lo que no sabe es la que entrega. Todo lo demás es muro de logos.

Preguntas frecuentes

¿Cómo eliges la empresa de desarrollo de software correcta si no eres técnico?
Juzga el comportamiento, no los artefactos. No puedes evaluar código, arquitectura ni un portafolio pulido, pero sí puedes evaluar cómo una empresa define el alcance de tu proyecto, si discrepa de las malas ideas, con qué honestidad habla de costo e incertidumbre, y qué hace cuando no sabe una respuesta. Esos comportamientos aparecen en conversación clara y predicen la entrega mejor que cualquier credencial técnica. Luego reduce el riesgo empezando con una tarea pequeña y pagada antes de comprometerte con la construcción completa.

¿Cuál es la regla del 80/20 al elegir una empresa de software?
Un conjunto pequeño de señales carga la mayor parte del peso predictivo. Las dos que más importan: si la empresa estrecha tu alcance (optimizando para tu resultado) o solo lo infla (optimizando para su factura), y cómo responde una referencia real a “qué salió mal y cómo lo manejaron”. Esas dos preguntas dicen más que portafolios, premios y precio juntos.

¿Qué preguntas debo hacerle a una empresa de desarrollo de software antes de contratar?
Cuatro: cuéntame un proyecto que se salió de control y qué hicieron; si tuvieras que cortar mi alcance a la mitad, qué cortarías y por qué; quién específicamente va a trabajar en esto y qué pasa si se va; y cómo voy a saber que el proyecto está fuera de rumbo antes de que sea tarde. Estás probando honestidad, comprensión del núcleo de tu producto, riesgo de persona clave, y si el trabajo será visible para ti.

¿Una cotización más barata significa menor calidad?
No siempre, pero una cotización muy por debajo de las otras es información, no un ahorro. Suele significar un alcance más superficial, personal más barato o un malentendido del trabajo, y la diferencia tiende a reaparecer después como órdenes de cambio. Cuando los precios divergen mucho, pídele a cada empresa que explique su número. La explicación revela quién entendió de verdad el proyecto.

¿Con cuántas empresas de desarrollo de software debería hablar?
Las suficientes para triangular, normalmente de tres a cinco. Una no te da referencia. Una docena hace perder el tiempo a todos y tiende a convertirse en comparación de precios, que es el eje menos útil. De tres a cinco te deja comparar cuán distinto define cada una el mismo brief, que es la comparación que importa.

¿Debo elegir una agencia grande o un estudio pequeño?
Ninguno es más seguro por defecto. Las casas más grandes ofrecen proceso y continuidad pero más distancia de quien escribe tu código; los estudios más pequeños ofrecen atención senior y acceso directo pero más riesgo de persona clave. El tamaño correcto depende de la complejidad de tu proyecto y de cuánto acompañamiento necesitas. Desconfía de cualquier empresa que te diga que su propio tamaño es automáticamente la opción segura.