Cómo elegir una empresa de desarrollo de software a la medida
Elegir quién construirá el software de un negocio es una decisión que se vive durante años. El sistema resultante tocará clientes, datos y operación diaria, y la relación con quien lo construye suele durar más que el primer proyecto. Cuando el software además incorpora inteligencia artificial, la elección pesa el doble: el mercado está lleno de firmas que agregaron la sigla a su sitio en el último año.
El contexto ayuda a entender la prisa. Según McKinsey, el 78 por ciento de las organizaciones ya usa inteligencia artificial en al menos una función, y el AI Index de Stanford muestra que la adopción empresarial casi se duplicó en un año. Esa demanda atrajo oferta de toda calidad. Gartner, por su parte, anticipa que una parte considerable de los proyectos con agentes se cancelará antes de madurar, en buena medida por decisiones de implementación tomadas con prisa y con el proveedor equivocado.
La buena noticia: evaluar una empresa de desarrollo a la medida tiene método. Seis frentes, revisados con calma antes de firmar, separan a las firmas sólidas de las que solo saben vender.
El primer filtro es el trabajo ya entregado. Conviene pedir tres casos concretos y revisar cada uno con la misma pregunta: ¿este sistema sigue operando?
Un portafolio sólido muestra sistemas en producción con usuarios reales, describe el problema de negocio que resolvieron y explica qué midieron después del lanzamiento. Un portafolio débil muestra diseños, prototipos y pantallas bonitas que jamás enfrentaron un lunes con carga real.
Dos verificaciones elevan la señal. La primera: pedir hablar con un cliente de cada caso. Una conversación de veinte minutos con quien operó el sistema revela cómo responde la firma cuando algo se complica, cómo maneja los cambios de alcance y cómo se porta después del último pago del proyecto inicial. La segunda: revisar la antigüedad de los casos. Una firma cuyo mejor ejemplo tiene cuatro años vive de su pasado; una que muestra entregas recientes demuestra práctica vigente.
Cuando el proyecto incluye inteligencia artificial, la pregunta se afina: ¿qué han puesto en producción con modelos de lenguaje, visión o automatización de decisiones, y con qué resultados medidos? Muchas firmas cuentan experimentos; pocas cuentan sistemas que siguen operando meses después con una métrica de negocio atada.
Quien compra software rara vez puede juzgar código. Aun así, la capacidad técnica deja huellas observables.
**Preguntas que hacen.** Un equipo capaz pregunta por la operación, los datos y las restricciones del negocio antes de hablar de tecnología. Un equipo débil propone el stack en la primera reunión, antes de entender el problema.
**Cómo explican las decisiones.** Pedir que expliquen una decisión técnica de un caso anterior, en lenguaje de negocio, muestra si dominan lo que hicieron. La explicación clara es señal de dominio; la jerga defensiva, de lo contrario.
**Proceso de calidad.** Conviene preguntar cómo prueban lo que construyen: revisiones de código, pruebas automatizadas, ambientes de ensayo, manejo de versiones. Las respuestas concretas y rutinarias indican disciplina; las respuestas vagas indican improvisación que el cliente pagará después.
**Evaluación de sistemas de IA.** En proyectos con inteligencia artificial, la firma seria habla de evaluación con datos propios del cliente, líneas base medibles y monitoreo posterior al lanzamiento. La que solo promete el modelo más nuevo suele estar vendiendo la herramienta, en lugar del resultado.
Las firmas presentan a sus mejores personas en la venta. La pregunta que importa es quién trabajará en el proyecto después de la firma.
Conviene pedir los nombres y perfiles del equipo asignado: quién dirige técnicamente, quién desarrolla, quién prueba, cuánto tiempo lleva cada quien en la empresa. Y conviene dejarlo por escrito en el contrato, con un mecanismo para revisar sustituciones.
La rotación es el indicador silencioso. Una firma con alta rotación pierde contexto del proyecto cada pocos meses, y el cliente paga el reaprendizaje. Preguntar cuánto tiempo lleva el equipo medio en la empresa incomoda a quien tiene algo que ocultar y tranquiliza cuando la respuesta es sólida.
También importa la mezcla de seniority. Un proyecto dirigido por personas con experiencia y ejecutado con apoyo de perfiles junior bien supervisados funciona bien. Un proyecto entregado por completo a perfiles junior, con la supervisión prometida en abstracto, suele terminar en reescrituras.
Tres preguntas de propiedad deben quedar claras antes de firmar, por escrito.
**¿De quién es el código?** Lo sano: el código, la documentación y las configuraciones pertenecen al cliente desde el primer pago, almacenados en repositorios a los que el cliente tiene acceso permanente. Una firma que aloja el código en sus propias cuentas y lo entrega "al final" convierte la entrega en moneda de negociación.
**¿Qué pasa con los datos?** Conviene saber qué datos se usarán, dónde se almacenarán, quién podrá verlos y qué ocurrirá con ellos al terminar la relación. Si el proyecto usa modelos de terceros, la pregunta se extiende: ¿qué datos salen hacia esos servicios y bajo qué términos?
**¿Cómo se sale de la relación?** Una firma segura de su trabajo facilita la salida: documentación al día, accesos ordenados, transición pactada. Las cláusulas que dificultan irse revelan dependencia como estrategia comercial.
El proyecto se construye dos veces: una en el código y otra en la comunicación. La segunda sostiene a la primera.
Las señales útiles: un canal de comunicación definido con tiempos de respuesta, una reunión de seguimiento con agenda y acuerdos por escrito, demostraciones de avance sobre el sistema real cada una o dos semanas, y una bitácora de decisiones que el cliente pueda consultar.
La demostración periódica merece énfasis. Ver el sistema funcionando cada dos semanas permite corregir el rumbo cuando corregir cuesta poco. Los proyectos que se muestran por primera vez al final de un largo silencio suelen mostrar, precisamente, lo que nadie pidió.
También conviene observar cómo se comunica la firma durante la propia venta. La puntualidad, la claridad y la calidad de las preguntas en la etapa comercial son la mejor predicción disponible de la comunicación durante el proyecto.
Los dos modelos dominantes reparten la incertidumbre de formas distintas.
**Precio fijo.** El costo se acuerda por adelantado para un alcance definido. Protege el presupuesto cuando el alcance está claro y es estable; genera fricción cuando el alcance cambia, porque cada ajuste se renegocia. Funciona bien para proyectos acotados con requisitos maduros.
**Tiempo y materiales.** Se paga por el tiempo del equipo. Ofrece flexibilidad para ajustar el rumbo; exige disciplina de seguimiento, porque el costo final depende de la ejecución. Funciona bien para productos que evolucionan, siempre que haya visibilidad semanal del avance contra lo gastado.
Sea cual sea el modelo, tres prácticas protegen al cliente: pagos ligados a entregas verificables en lugar de fechas de calendario, un contrato que separe diagnóstico, construcción y operación como partidas distinguibles, y la posibilidad de detener el proyecto al cierre de cada fase quedándose con lo construido.
Para entrar a esa conversación con criterio, conviene revisar antes qué incluye una consultoría de IA, conocer la estructura de entregables y precio y tener a la mano las preguntas que conviene hacer. La mayoría de los desacuerdos posteriores nace de supuestos que pudieron aclararse en una tarde.
Algunas conductas predicen problemas con suficiente fiabilidad como para tomarlas en serio:
- Propuestas que prometen resultados de inteligencia artificial con fechas cerradas antes de ver los datos del cliente.
- Precios muy por debajo del mercado, financiados después con cambios de alcance o con una operación opaca.
- Resistencia a compartir referencias, a firmar la propiedad del código o a mostrar al equipo asignado.
- Presentaciones centradas en la tecnología de moda, con poca curiosidad por la operación del negocio.
- Contratos que hacen difícil salir, con el código, los datos o la documentación como rehenes.
Ninguna señal por sí sola condena a una firma. Dos o tres juntas suelen bastar para seguir buscando.
**¿Conviene una empresa local, nacional o en el extranjero?** Lo decisivo es la calidad del equipo asignado y la comunicación, en ese orden. La cercanía geográfica facilita algunas cosas y la diferencia de costo otras tantas; ambas pesan menos que trabajar con gente capaz que responde.
**¿Cuánto debe durar el proceso de selección?** Para un proyecto mediano, dos a cuatro semanas permiten comparar tres propuestas con calma: revisar casos, hablar con referencias y discutir el planteamiento técnico. Menos suele ser prisa; más suele ser indecisión.
**¿Hace falta saber de tecnología para elegir bien?** Hace falta método, en lugar de conocimiento técnico profundo: verificar producción real, hablar con clientes anteriores, asegurar la propiedad del código y exigir demostraciones periódicas. Cuando el proyecto es grande, un asesor técnico independiente por unas horas rinde mucho.
**¿Qué papel juega el tamaño de la firma?** Firmas grandes aportan procesos maduros y capacidad de escala; firmas pequeñas aportan atención directa y velocidad. Para una empresa pequeña, una firma mediana con casos verificables suele ofrecer el mejor equilibrio.
Elegir una empresa de desarrollo de software a la medida se reduce a verificar seis cosas: producción real en el portafolio, capacidad técnica observable, el equipo que trabajará de verdad, propiedad clara del código y los datos, comunicación con demostraciones periódicas y un contrato que reparta la incertidumbre de forma honesta. Cada una se puede comprobar antes de firmar.
La firma correcta es la que permite verificar más, en lugar de la que promete más. Quien construye bien muestra las referencias con gusto, presenta a su equipo, firma la propiedad del código y demuestra avances cada dos semanas. Esa transparencia, sostenida en el tiempo, es la mejor predicción de un sistema que seguirá funcionando años después del lanzamiento.
Fuentes
¿Te fue útil este artículo?