Cómo elegir una empresa de desarrollo de software

Elegir empresa de desarrollo es una decisión incómoda porque tienes que juzgar un trabajo que no sabes hacer. Tres propuestas encima de la mesa, con precios que se diferencian en un factor de tres, y ninguna forma evidente de saber cuál te va a dejar tirado en el mes cuatro.

La buena noticia es que no hace falta ser técnico para hacerlo bien. Hacen falta las preguntas correctas y saber qué respuestas son señales de alarma. Esto es lo que preguntaríamos nosotros si tuviéramos que contratar a alguien como nosotros.

Antes de las preguntas: con quién vas a hablar realmente

Empieza por aquí, porque condiciona todo lo demás.

En muchas propuestas la persona que te encanta en la reunión comercial no es la que va a construir tu software, y a veces ni siquiera va a hablar con quien lo construya. Entre tú y el código hay un comercial, un jefe de proyecto y a lo mejor un equipo subcontratado en otro huso horario.

Cada capa que añades entre tu problema y quien lo resuelve es una capa donde se pierde información. Y en software, la información que se pierde es exactamente la que te habría ahorrado el rehacer.

Pregunta directa: "En la semana tres del proyecto, si tengo una duda sobre cómo se ha resuelto algo, ¿con quién hablo?". Si la respuesta es un nombre y ese nombre está en la reunión, buena señal.

Las doce preguntas

Sobre el alcance y el precio

1. ¿Cómo llegáis al presupuesto? Lo que buscas es que haya un trabajo previo de definición y no una estimación hecha de oído. Un precio dado en la primera reunión, sin haber hablado con quien va a usar la herramienta, es un número inventado. Puede salir bien; es una apuesta.

2. ¿El precio es cerrado y qué lo puede mover? "Cerrado" solo significa algo si está claro qué incluye. Pide que se distinga entre lo que ya está presupuestado y lo que sería un cambio de alcance, y que exista un procedimiento escrito para lo segundo.

3. ¿Qué pasa si la estimación se os queda corta? Es la pregunta reveladora. Si el riesgo de estimación lo asume quien estima, el incentivo está bien puesto. Si te lo pasan a ti en forma de "horas adicionales", estás firmando un cheque en blanco con formato de presupuesto.

4. ¿Qué no incluye la propuesta? Casi mejor que preguntar qué incluye. Migración de datos, formación del equipo, puesta en producción y acompañamiento inicial son trabajo real. Si no aparecen, o no están o los vas a pagar aparte.

Sobre cómo se trabaja

5. ¿Cuándo veré algo funcionando por primera vez? Si la respuesta es "al final", huye. Un proyecto sano entrega versiones usables cada dos o tres semanas, y no como cortesía: es lo que hace que un cambio de opinión en la semana cuatro sea barato en lugar de catastrófico.

6. ¿Qué necesitáis de mi equipo y cuánto tiempo? Una respuesta honesta incluye horas concretas de gente concreta. Quien te dice que no necesita nada de ti está construyendo lo que él imagina, no lo que tú necesitas.

7. ¿Cómo gestionáis los cambios de opinión? Vas a cambiar de opinión. Lo que distingue a un buen proveedor no es que lo impida, sino que tenga un mecanismo: qué se decide, cuándo, quién lo aprueba y qué implica en plazo y precio.

8. ¿Qué pasa cuando algo se rompe en producción a las once de la noche? Pide el compromiso concreto: quién responde, en cuánto tiempo, y si eso está incluido o es un contrato aparte. Que exista respuesta ya te dice mucho.

Sobre la propiedad y la dependencia

9. ¿De quién es el código? Tiene que ser tuyo, por escrito, en el contrato. Y "tuyo" quiere decir el repositorio con todo su historial, la base de datos y la documentación técnica. No "una copia del software funcionando".

10. ¿Sobre qué está construido? No necesitas entender la respuesta técnica, pero sí necesitas que exista y sea reconocible. Tecnologías estándar y ampliamente usadas significan que otra empresa podrá continuar el trabajo. Un framework propietario del proveedor significa que solo ellos pueden mantenerlo, para siempre.

11. ¿Dónde se aloja y a nombre de quién están las cuentas? Servidores, dominio, certificados y servicios de terceros deberían estar a nombre de tu empresa, aunque los gestione el proveedor. Si están a nombre de ellos, cambiar de proveedor deja de ser una decisión técnica y pasa a ser una negociación.

12. ¿Qué me lleváis si mañana dejamos de trabajar juntos? La pregunta incómoda, y por eso la más útil. Un buen proveedor la contesta sin ponerse tenso, porque su plan para retenerte es hacerlo bien, no que no puedas irte.

Cinco señales de alarma

Te dan precio sin haber preguntado casi nada. O han hecho este proyecto veinte veces —posible, pregúntalo— o van a descubrir el alcance real cuando ya estés dentro.

Todo es "sí, sin problema". Un proyecto de software está lleno de decisiones con contrapartidas. Quien dice que sí a todo, o no ha entendido lo que le pides, o piensa renegociarlo más tarde.

No te preguntan por quién va a usar la herramienta. El software se rompe en las manos de quien lo usa a diario, no en las de quien lo compra. Un proveedor que no quiere hablar con los usuarios está construyendo a ciegas.

El presupuesto es la mitad que los demás. Casi nunca es un descubrimiento de eficiencia. Suele ser un proyecto más pequeño entendido por error, o un precio de entrada que sube en cuanto estás comprometido.

Enseñan muchos logos y ningún detalle. "Hemos trabajado con estas veinte marcas" no dice nada. "En este proyecto había este problema, lo resolvimos así y esto es lo que aprendimos" lo dice todo. Pide una referencia con la que puedas hablar por teléfono.

Qué debería enseñarte antes de que firmes

Las preguntas son la mitad. La otra mitad es qué te enseñan por iniciativa propia.

Algo funcionando, no un catálogo de capturas. Pide ver una aplicación real en uso, aunque sea con datos de demostración. Cinco minutos navegando por algo que existe dicen más que cuarenta diapositivas. Si todo lo que han hecho está bajo acuerdo de confidencialidad —pasa, y es legítimo—, que te enseñen al menos cómo trabajan sobre un proyecto propio.

Una referencia con la que puedas hablar. No un logo: un teléfono. Y cuando llames, la pregunta útil no es "¿estás contento?" sino "¿qué salió mal y cómo lo resolvieron?". En todos los proyectos sale algo mal. Lo que distingue a un buen proveedor es lo que hizo ese día.

El documento de alcance de otro proyecto. Anonimizado, claro. Es la mejor forma de saber si trabajan con definiciones concretas o con listas de funcionalidades vagas, que es lo que acaba determinando si el precio cerrado te protege o te ata las manos.

Una opinión que no te guste. Un proveedor que en la primera reunión te dice "esto que pides no lo haríamos así" o "esta parte no la necesitas todavía" está renunciando a facturar para que el proyecto salga bien. Es la señal más fiable que existe, y la más rara.

Cómo comparar tres presupuestos que no se parecen en nada

Es el problema práctico: te llegan tres documentos con estructuras distintas y no hay forma de ponerlos en la misma tabla. Nuestra recomendación es reducirlos a cinco columnas.

Qué comparar	Qué buscas
Alcance de la primera versión	Que las tres propuestas hablen del mismo producto
Riesgo de estimación	Quién paga si la estimación falla
Puesta en producción	Si migración, formación y acompañamiento están dentro
Propiedad y tecnología	Código tuyo, tecnologías estándar, cuentas a tu nombre
Coste anual después	Mantenimiento e infraestructura del año 2 en adelante

Si al rellenar la tabla descubres que las tres propuestas describen productos distintos —y suele pasar—, el problema no son las propuestas: es que el alcance no estaba lo bastante definido cuando pediste precio. La solución es escribirlo tú y volver a pedir.

El caso especial: rescatar un proyecto que empezó otro

Es una situación más común de lo que parece y merece reglas propias.

Desconfía de quien te comprometa plazos sobre código que aún no ha leído. Nadie puede saber qué hay dentro de un proyecto ajeno hasta que lo abre, y el que dice que sí, está adivinando. Lo razonable es una auditoría corta y de precio cerrado: dos o tres semanas para revisar el código, la infraestructura y los datos, y salir con un informe que diga qué se aprovecha, qué se tira y cuánto cuesta cada camino.

Ese informe es tuyo, se contrata por separado y no te obliga a seguir con quien lo hizo. Si un proveedor no quiere trabajar así, te está pidiendo fe en lugar de datos.

Qué respondemos nosotros a estas preguntas

Por coherencia, las nuestras en corto: hablas con quien programa, sin capas intermedias. No damos precio sin una fase de definición previa, y el precio que sale de ahí es cerrado, con el riesgo de estimación de nuestro lado. Entregamos cada dos semanas algo que puedes abrir y usar. El código, la base de datos y la documentación son tuyos desde el primer día, sobre tecnologías estándar —React, Node, Python, PostgreSQL— que cualquier equipo competente puede continuar.

Y si algún día decides irte, te llevas todo sin tener que pedirlo. Puedes ver el detalle en cómo trabajamos.

Si estás comparando propuestas ahora mismo y quieres una tercera opinión —incluso si al final eliges otra—, cuéntanoslo. Leer un presupuesto ajeno con ojos técnicos es rápido y suele ahorrar disgustos.