Cómo elegir un proveedor de desarrollo de software sin equivocarte

Ya decidiste que necesitás desarrollar un software. La pregunta ahora es distinta y, en muchos casos, más riesgosa: ¿con quién lo hacés?

Si todavía no tenés claro si tu empresa necesita un desarrollo propio, primero conviene revisar cómo saber si tu empresa realmente necesita un software a medida. Este artículo asume que ya pasaste esa etapa: sabés qué problema querés resolver, y ahora tenés que elegir con quién construirlo.

Elegir mal un proveedor de desarrollo no solo significa perder el presupuesto del proyecto. Significa perder meses de operación con un sistema a medias, un equipo interno frustrado, y en muchos casos, tener que empezar de cero con otro proveedor — pagando dos veces por el mismo problema.

Esta guía es el proceso que recomendamos seguir antes de firmar con cualquier proveedor, incluido nosotros.

Por qué elegir mal un proveedor sale tan caro

El costo de un mal proveedor casi nunca aparece en la cotización inicial. Aparece después:

• En el alcance que “se fue agrandando” sin que nadie lo autorizara formalmente.
• En los plazos que se duplican porque nadie estimó bien la complejidad real.
• En un sistema que funciona en la demo pero falla con datos reales de producción.
• En la documentación que no existe, así que solo el proveedor original puede tocar el código.
• En el soporte que desaparece apenas se firma el acta de cierre.

Ninguno de estos problemas se detecta en una primera reunión comercial. Se detectan evaluando cómo trabaja el proveedor, no solo qué promete.

Antes de buscar proveedor: definí esto primero

Un error común es salir a pedir cotizaciones antes de tener claridad interna. Sin esto, cualquier proveedor —bueno o malo— va a tener que adivinar, y adivinar sale caro.

• El problema de negocio, no la solución técnica. No es lo mismo pedir “un CRM” que explicar “necesitamos dejar de perder seguimiento de cotizaciones entre vendedores”.
• Quién es el responsable interno del proyecto. Alguien de tu equipo tiene que liderar el levantamiento y validar entregables — no puede ser 100% delegado al proveedor.
• Un presupuesto referencial. No necesitás el número exacto, pero sí un rango realista que evite cotizaciones completamente desalineadas con lo que podés invertir.
• Un plazo razonable. Si necesitás algo “para ayer”, ya estás negociando en desventaja.

Qué preguntar a un proveedor antes de contratar

Estas preguntas separan rápido a un proveedor serio de uno que solo quiere cerrar la venta:

• ¿Cómo levantan requerimientos? ¿Con qué documentos o artefactos queda registrado el alcance acordado?
• ¿Quién del equipo técnico va a trabajar realmente en mi proyecto, no solo quién lo vende?
• ¿Cómo manejan un cambio de alcance a mitad de proyecto?
• ¿Qué pasa si el proyecto se atrasa: quién asume el costo?
• ¿El código y la infraestructura quedan de mi propiedad al terminar?
• ¿Qué incluye el soporte post-lanzamiento, y por cuánto tiempo?
• ¿Puedo hablar con un cliente anterior con un proyecto de complejidad similar al mío?

Un proveedor con procesos maduros responde estas preguntas sin dudar, con ejemplos concretos. Las respuestas vagas o genéricas son la primera señal de alerta.

Cómo evaluar una propuesta técnica

No hace falta ser técnico para detectar una propuesta débil. Hay tres puntos que casi siempre revelan la calidad real del trabajo.

Alcance y supuestos

Una propuesta seria enumera explícitamente qué incluye y qué NO incluye. Si el documento solo dice “desarrollo de sistema de gestión” sin desglosar módulos, integraciones y exclusiones, el alcance real se va a definir recién cuando aparezcan los primeros desacuerdos — ya en medio del proyecto.

Metodología de trabajo

Preguntá cómo vas a ver avances: ¿entregas semanales, sprints demostrables, acceso a un ambiente de pruebas? Un proveedor que solo promete “reuniones de seguimiento” sin entregables intermedios tangibles hace que el riesgo de sorpresas al final del proyecto sea mucho más alto.

Estimación de tiempos y costos

Desconfía de estimaciones cerradas sin ningún rango ni supuestos declarados. El desarrollo de software rara vez es 100% predecible; una propuesta que reconoce esa incertidumbre (con rangos, hitos de revisión, o modalidades como “tiempo y materiales” para partes menos definidas) suele ser más honesta que una cifra fija sin matices.

Señales de alerta al elegir un proveedor

• Cotiza sin haber hecho ninguna pregunta sobre tu proceso real.
• El precio es notoriamente más bajo que el resto, sin explicación de por qué.
• No puede mostrar un proyecto anterior de complejidad comparable.
• Evita hablar de qué pasa si el proyecto se atrasa o cambia de alcance.
• La comunicación durante la venta es rápida y clara, pero se vuelve lenta apenas preguntás por contrato o condiciones.
• No menciona nada sobre propiedad del código ni documentación técnica.

Qué debe incluir el contrato o SOW

El documento de alcance (Statement of Work) es lo que te protege cuando algo no sale como se conversó verbalmente. Como mínimo, debería especificar:

• Alcance funcional detallado, módulo por módulo.
• Qué se considera fuera de alcance (evita el “scope creep” silencioso).
• Hitos de entrega y criterios de aceptación de cada uno.
• Proceso formal para solicitar y cotizar cambios de alcance.
• Propiedad intelectual del código y los datos al finalizar.
• Condiciones de soporte y garantía post-lanzamiento.
• Plan de salida: qué pasa si la relación con el proveedor termina antes de lo esperado.

Referencias: cómo verificarlas de verdad

Pedir referencias no sirve de mucho si solo preguntás “¿quedaron conformes?”. Preguntas más útiles para una llamada de referencia:

• ¿El proyecto se entregó en el plazo originalmente acordado? Si no, ¿por qué?
• ¿Cómo manejó el proveedor un cambio de alcance o un imprevisto técnico?
• ¿Cómo fue el soporte una vez que el sistema ya estaba en producción?
• ¿Volverían a trabajar con ellos en un proyecto nuevo?

La última pregunta suele ser la más honesta de todas.

Nuestra forma de trabajar en Digital Upgrade

En Digital Upgrade partimos todo proyecto con un levantamiento del proceso real, no de la solución que el cliente cree que necesita. Trabajamos con entregas demostrables por etapas, alcance documentado desde el inicio, y el código y la infraestructura quedan siempre en propiedad del cliente. Podés revisar el detalle de cómo trabajamos en desarrollo de software a medida, o ver proyectos que hemos desarrollado para empresas chilenas con distintos niveles de complejidad. También integramos estos desarrollos con sistemas ya existentes vía integración de sistemas cuando el proyecto lo requiere.

Checklist final antes de firmar

• ¿El alcance está documentado por escrito, módulo por módulo?
• ¿Sé quién del equipo técnico va a trabajar en mi proyecto?
• ¿Existe un proceso claro para cambios de alcance?
• ¿El contrato especifica propiedad del código y los datos?
• ¿Verifiqué al menos una referencia con preguntas específicas, no genéricas?
• ¿Entiendo qué incluye (y qué no incluye) el soporte post-lanzamiento?
• ¿La estimación de tiempos reconoce algún grado de incertidumbre, en vez de prometer una fecha cerrada sin matices?

Si podés responder que sí a la mayoría, estás en condiciones de avanzar con más tranquilidad. Si no, todavía es buen momento para pedir esas respuestas antes de firmar — no después.

¿Estás evaluando proveedores para tu próximo proyecto?

Si querés una segunda opinión sobre una propuesta que ya recibiste, o simplemente conversar sobre tu proyecto desde cero, en Digital Upgrade podemos ayudarte a evaluar el camino más adecuado.

Preguntas frecuentes