Cómo elegir proveedor de desarrollo de software: 12 preguntas

Contratar desarrollo de software tiene un problema estructural: quien compra normalmente no puede evaluar técnicamente lo que está comprando. No puedes revisar el código antes de que exista, y las tres propuestas que tienes sobre la mesa usan las mismas palabras.

La forma de compensar esa asimetría no es aprender a programar. Es hacer preguntas cuyas respuestas revelen cómo trabaja el proveedor, independientemente de lo técnico. Estas son las doce que importan, y qué deberías escuchar en cada una.

Sobre propiedad y salida

1. ¿De quién es el código fuente al terminar el proyecto?

La pregunta más importante de la lista, y la que menos se hace.

Lo que quieres oír: que el código es tuyo, que recibes el repositorio completo con su historial y la documentación técnica, y que eso está por escrito en el contrato.

Lo que debe preocuparte: respuestas vagas del tipo "nosotros lo administramos por ti" o "tienes acceso al sistema". Acceso al sistema no es propiedad del código. Si el proveedor retiene el código, cualquier cambio futuro tiene que pasar por él a su precio, y cambiar de proveedor significa empezar de cero.

Puede haber modelos donde eso sea aceptable y hasta conveniente. Lo que no es aceptable es descubrirlo dos años después.

2. Si en un año quiero llevarme el proyecto, ¿qué me entregas?

Es la versión práctica de la pregunta anterior. Un buen proveedor puede describir el paquete sin titubear: repositorio, documentación de arquitectura, credenciales de infraestructura, instrucciones de despliegue y respaldo de base de datos.

Señal de alarma: que la respuesta dependa de "hablarlo en su momento".

3. ¿Quién es dueño de las cuentas de infraestructura?

Los servicios de nube, el dominio y las cuentas de las tiendas de aplicaciones deberían estar a nombre de tu empresa, con el proveedor como colaborador. Cuando están a nombre del proveedor, tu producto vive en una casa que no es tuya.

Si ya es tarde y están a nombre del proveedor, pide la migración por escrito y con fecha.

Sobre cómo trabajan

4. ¿Cada cuánto voy a ver algo funcionando?

Lo que quieres oír: demos semanales o cada dos semanas con software que puedas usar, no capturas de pantalla ni presentaciones.

Lo que debe preocuparte: "te lo entregamos en tres meses". Eso significa que durante tres meses no tendrás forma de saber si el proyecto va bien, y que cuando por fin lo veas ya será demasiado caro corregir el rumbo. La mayoría de los proyectos de software que fracasan no fracasan por mala programación: fracasan porque nadie se dio cuenta a tiempo de que se estaba construyendo lo equivocado.

5. ¿Quién va a trabajar en mi proyecto y con quién hablo?

Necesitas un nombre y un canal directo. En proyectos vendidos por un comercial y ejecutados por un equipo que nunca hablas, la información se degrada en cada traspaso.

Pregunta también si el equipo es de planta o subcontratado. No es descalificante que sea subcontratado, pero cambia quién responde cuando hay un problema.

6. ¿Qué pasa si el proyecto se pasa del estimado?

La pregunta incómoda que más información da.

Lo que quieres oír: una respuesta concreta. Puede ser que el proveedor absorbe el sobrecosto si el alcance no cambió, o que hay un mecanismo acordado para cotizar lo que sí cambió. Ambas son respuestas profesionales.

Lo que debe preocuparte: que la pregunta se esquive, o un "eso no va a pasar". Sí pasa, en casi todos los proyectos. Lo que distingue a un buen proveedor es que ya pensó cómo se maneja.

7. ¿Cómo se manejan los cambios de alcance?

Todo proyecto cambia porque el cliente aprende cosas al ver el sistema funcionando. Un proveedor con proceso te describirá cómo se documenta, cotiza y aprueba un cambio. Uno sin proceso dirá "somos flexibles", que en la práctica significa fricción en cada solicitud.

Sobre el alcance y el dinero

8. ¿Me puedes dar el alcance desglosado por módulo?

Un total sin desglose no se puede comparar contra otra propuesta ni auditar durante el proyecto. Necesitas ver módulos, entregables por módulo y esfuerzo asociado.

Esto además te permite algo muy útil: recortar. Si el presupuesto no alcanza, con un desglose puedes decidir qué se posterga; con un número global sólo puedes decir sí o no.

9. ¿Cuáles son los costos recurrentes después de la entrega?

Hospedaje, dominio, licencias de terceros, servicios de IA si los usa, mantenimiento. Deben estar estimados por escrito desde la propuesta.

Señal de alarma: "eso es aparte, luego lo vemos". Un proyecto entregado que la empresa no puede costear operar es un proyecto perdido.

10. ¿Qué cubre la garantía y por cuánto tiempo?

Debe distinguir claramente dos cosas: los errores atribuibles al desarrollo, que se corrigen sin costo dentro del periodo acordado, y las funciones nuevas, que se cotizan aparte. Si la garantía no distingue, cualquier reporte tuyo puede ser clasificado como "función nueva".

Sobre experiencia real

11. ¿Puedo hablar con un cliente de un proyecto parecido?

Los portafolios muestran interfaces bonitas. Una llamada de quince minutos con un cliente anterior te dice cómo se comportó el proveedor cuando algo se complicó, que es la única información que realmente importa.

Lo que debe preocuparte: que no haya ninguna referencia disponible. Confidencialidad es una razón legítima para no dar nombres de todos los clientes, pero un proveedor con historia debería poder conseguir al menos una conversación.

Y una pregunta mejor que "¿quedaste satisfecho?": "¿qué salió mal y cómo lo resolvieron?" Todos los proyectos tienen un momento difícil; lo revelador es la conducta en ese momento.

12. ¿Han trabajado en mi industria o con mi tipo de integración?

No es indispensable, pero cambia el estimado. Un equipo que ya integró con el sistema de facturación que usas, o que conoce la regulación de tu sector, va a tardar menos y a equivocarse menos.

Si no tienen ese contexto, no es descalificante — pero el estimado debería incluir explícitamente el tiempo de aprendizaje, y no cargártelo como imprevisto después.

La bandera roja que resume todas

Si tuvieras que quedarte con una sola señal: desconfía de quien te cotiza sin hacerte preguntas.

Un proveedor que recibe un correo de dos párrafos y responde con un precio en firme no entendió tu problema — te está vendiendo un producto genérico con etiqueta de "a medida". Los proyectos de software se cotizan bien sólo después de entender quién usa el proceso hoy, qué sistemas hay de por medio y qué pasa cuando algo sale mal.

Una reunión de descubrimiento donde te preguntan más de lo que te presentan es la mejor señal temprana de que el proyecto va a salir bien.

Nuestras respuestas, para que las compares

Para que esta guía sea útil y no sólo una lista, aquí están nuestras respuestas en Appquantika:

• Código fuente: es del cliente. Se entrega el repositorio completo con documentación al cerrar el proyecto.
• Avances: demos semanales con software funcionando, desde el primer sprint.
• Alcance: propuesta desglosada por módulo, con plazos y pagos ligados a entregables.
• Costos recurrentes: estimados por escrito en la propuesta, no después.
• Soporte: post-lanzamiento incluido en todos los proyectos, con plan de mantenimiento continuo opcional.
• Confidencialidad: firmamos NDA cuando se requiere y no usamos el nombre de un cliente como referencia sin su autorización.
• Propuesta: en 48 a 72 horas hábiles después de la reunión de descubrimiento, que es gratuita.

Usa estas doce preguntas con nosotros y con quien más estés evaluando. Si al comparar las respuestas otro proveedor encaja mejor con tu caso, habrás tomado una buena decisión — que es de lo que se trata.

¿Quieres empezar por la reunión de descubrimiento? Escríbenos o revisa nuestras preguntas frecuentes si prefieres leer primero.