Contratar un proyecto de desarrollo de software a medida es una decisión de alto impacto para cualquier empresa chilena. También es una decisión en la que los errores son caros y difíciles de revertir. En casi una década trabajando con empresas de distintas industrias, hemos visto los mismos cinco patrones repetirse. Conocerlos con anticipación puede ahorrarle a tu organización meses de trabajo perdido y presupuestos que se volatilizan antes de que el sistema llegue a producción.
Error 1: Elegir al proveedor por precio sin evaluar el encaje
El error más frecuente y el más caro. La lógica parece razonable: si tres empresas ofrecen “lo mismo”, elige la más barata. El problema es que en desarrollo de software a medida, ninguna empresa ofrece exactamente lo mismo, y las diferencias de precio casi siempre reflejan diferencias en metodología, experiencia y compromiso post-lanzamiento.
Un proveedor que cotiza 40% menos que los demás generalmente tiene una de tres razones: subestimó el alcance, no tiene experiencia con proyectos de esa complejidad, o planea recortar calidad en áreas no visibles. En los tres casos, el costo real del proyecto para tu empresa termina siendo mayor que si hubieras elegido la cotización más alta desde el inicio.
La ecuación correcta no es “precio bajo = ahorro”. Es “precio bajo sin justificación técnica = riesgo de rehacer el sistema”.
Lo que debes hacer en cambio: Evalúa al proveedor en cuatro dimensiones: experiencia demostrable en proyectos similares al tuyo, claridad de la metodología de trabajo, referencias verificables de clientes actuales y transparencia en lo que incluye y lo que no incluye la cotización.
Solicita siempre tres opciones de inversión: versión mínima viable, versión recomendada y versión completa. Una empresa seria puede articular esas tres opciones con sus diferencias técnicas. Una que no puede hacerlo probablemente no tiene suficiente claridad del alcance para ejecutar bien ninguna de ellas.
Error 2: Comenzar sin un alcance definido
“Queremos un sistema de gestión” es el punto de partida de la mayoría de los proyectos mal terminados. No es un alcance: es un objetivo vago que cada parte interpreta de forma distinta.
El alcance real incluye qué módulos y funcionalidades se desarrollan, qué integraciones con sistemas existentes se requieren, qué roles de usuario y permisos maneja el sistema, dónde se almacenan los datos y bajo qué política de acceso, y cuáles son los criterios de aceptación de cada entregable.
Cuando el alcance no está documentado antes de comenzar, cualquier interpretación es válida. El desarrollador interpreta lo mínimo necesario. El cliente espera lo máximo posible. La diferencia entre esas dos interpretaciones es lo que genera los famosos “eso no estaba incluido” que destruyen proyectos y relaciones comerciales.
Lo que debes hacer en cambio: Antes de firmar cualquier contrato, exige un documento de alcance o brief técnico donde queden registradas las funcionalidades por módulo, las integraciones requeridas, los criterios de aceptación por entregable y lo que explícitamente está fuera del alcance. Si el proveedor no puede producir ese documento antes del inicio, no te están ofreciendo desarrollo a medida: te están ofreciendo horas de trabajo sin dirección clara.
Un diagnóstico serio antes del desarrollo puede tomar entre 2 y 5 días de trabajo conjunto. Es tiempo bien invertido: reduce los cambios de alcance durante el desarrollo, que típicamente encarecen el proyecto entre un 20% y un 60% sobre la cotización original.
Error 3: No validar la capacidad técnica real del equipo
Los portafolios y las presentaciones comerciales de una empresa de desarrollo de software pueden ser muy distintos de lo que ocurre cuando empieza el proyecto real. Muchas empresas tienen un equipo de ventas sólido y un equipo técnico con brechas importantes, o tienen capacidad para ciertos tipos de proyectos pero no para el tuyo específicamente.
Hay señales que debes verificar antes de contratar:
- El equipo técnico que participó en el diagnóstico es el que va a desarrollar. Si en la reunión comercial estuvieron los “seniors” y luego el proyecto lo ejecutan juniors sin supervisión, el resultado será proporcional a esa diferencia.
- Han desarrollado proyectos con integraciones similares a las tuyas. Integrar con el SII, conectar con Transbank o con un ERP específico tiene curvas de aprendizaje reales. Cada hora que el equipo invierte aprendiendo sobre tu sistema específico la estás pagando tú.
- Tienen procesos documentados de control de calidad. Un equipo sin pruebas automatizadas o revisiones formales de código entrega más rápido en las primeras semanas y más lento —y con más bugs— en las últimas. Los bugs que no se detectan en desarrollo se detectan en producción, con tu operación corriendo.
Lo que debes hacer en cambio: Pide una sesión técnica de 30 minutos con el desarrollador o tech lead que va a trabajar en tu proyecto. No para evaluarlo como experto en tu industria, sino para ver si puede explicar con claridad cómo va a resolver los tres desafíos técnicos más complejos de tu sistema. Si no puede articularlo, el proyecto tiene un riesgo técnico no gestionado que saldrá a la luz durante el desarrollo.
Error 4: No pensar en el mantenimiento antes de contratar
Un sistema de software empresarial no es un producto que se entrega y se olvida. Es una plataforma viva que necesita actualizaciones de seguridad, corrección de bugs que aparecen en condiciones reales de uso, adaptaciones cuando tu negocio cambia y mejoras evolutivas a medida que el equipo gana experiencia operando el sistema.
La mayoría de las empresas descubre esto cuando ya es tarde: a los 3 o 6 meses del lanzamiento aparece un bug crítico, o necesitan agregar un módulo nuevo, y descubren que el proveedor cobró la mitad del mercado porque no incluía soporte post-lanzamiento. O que el código que entregaron es tan difícil de modificar que prácticamente necesitan rehacerlo para hacer cualquier cambio.
Lo que debes hacer en cambio: Antes de firmar, define explícitamente qué pasa después del lanzamiento. Cuatro preguntas mínimas:
- ¿Cuál es el tiempo de respuesta ante un bug crítico en producción?
- ¿Quién hace las actualizaciones de seguridad de dependencias y librerías?
- ¿Se entrega el código fuente completo y la documentación técnica al cierre del proyecto?
- ¿Cuánto cuesta agregar un módulo nuevo una vez que el proyecto inicial está terminado?
El mantenimiento evolutivo no es un gasto opcional en proyectos de software empresarial. Es parte del costo total de propiedad del sistema y debe estar en el presupuesto y en el contrato desde el inicio, no como una negociación posterior cuando ya hay urgencia.
Error 5: No definir cómo se va a medir el éxito
Si no tienes métricas acordadas antes de iniciar el proyecto, no podrás saber si el software funcionó. Y sin esa evaluación objetiva, las decisiones de inversión futura —agregar módulos, renovar el contrato, escalar el sistema— quedan sin base sólida. Peor aún: si el proyecto no entregó el valor esperado, no tendrás forma de saber si el problema fue el software, la adopción, la capacitación o las expectativas iniciales.
Las empresas que más valor extraen de sus proyectos de software son las que definen, antes del inicio, tres cosas: el problema a resolver expresado en números concretos, el objetivo del sistema en los mismos términos, y el mecanismo para medir el avance durante las primeras semanas de operación real.
Un ejemplo concreto: no “queremos mejorar la gestión de inventario”, sino “hoy tenemos una diferencia promedio del 8% entre el inventario físico y el sistema. El objetivo es reducirla al 1% en los primeros 60 días de operación.”
Con ese nivel de precisión, la evaluación del proyecto se vuelve objetiva y la empresa puede tomar decisiones fundamentadas.
Lo que debes hacer en cambio: Exige que los KPIs del proyecto sean parte del documento de alcance. Un proveedor que no quiere comprometerse con métricas de éxito es un proveedor que no está seguro de poder entregarte resultados medibles. Esa es información importante sobre cómo van a trabajar.
Señales de propuesta seria versus señales de alerta
La diferencia entre una propuesta que vale la pena analizar y una que esconde riesgos generalmente se puede identificar antes de tomar cualquier decisión:
| Dimensión | Propuesta seria | Señal de alerta |
|---|---|---|
| Cotización | Tres opciones: MVP, recomendada, completa | Precio único sin alternativas |
| Alcance | Documento técnico con criterios de aceptación | ”Lo definimos durante el desarrollo” |
| Equipo | Identifica quién desarrolla y con qué experiencia | Solo el equipo comercial es visible |
| Plazo | Cronograma con hitos y entregables parciales | Fecha final sin hitos intermedios |
| Post-lanzamiento | Esquema de soporte explícito en el contrato | ”El soporte lo vemos al terminar” |
| Métricas | KPIs de éxito acordados en la propuesta | No se menciona cómo se medirá el resultado |
Ninguna de estas señales por sí sola determina la calidad del proveedor. Pero si encuentras tres o más señales de alerta en una misma propuesta, el riesgo del proyecto es significativo.
Cómo hacer una selección de proveedores seria
Después de identificar los errores a evitar, el proceso de selección con mayor probabilidad de éxito tiene cuatro etapas concretas.
1. Define el problema antes de buscar proveedor
Redacta un documento interno de una o dos páginas que describa el problema que tienes, el impacto que tiene en tu operación (en números si es posible) y lo que esperas del software nuevo. Este documento es la base para evaluar si las propuestas que recibes realmente entienden tu contexto o si están dando respuestas genéricas.
2. Evalúa al menos tres proveedores en paralelo
No para elegir el más barato. Para tener un marco de comparación real sobre metodologías, plazos y formas de trabajo. Tres propuestas bien estructuradas revelan más sobre cada proveedor que diez reuniones comerciales. Si todos los proveedores dicen exactamente lo mismo, estás cotizando mal el problema.
3. Verifica referencias reales de proyectos similares
Pide el contacto directo de al menos dos clientes de proyectos comparables al tuyo. Una empresa que no puede proveer referencias directas o que pone obstáculos para que las contactes tiene algo que ocultar. Una referencia bien elegida no toma más de 20 minutos: pregunta qué salió bien, qué salió mal y si volvería a contratar con ese equipo.
4. Revisa el contrato antes de firmarlo
Los proyectos problemáticos casi siempre tienen contratos vagos. Verifica que el contrato especifique el alcance técnico acordado, los hitos de entrega, quién es el dueño del código fuente al término del proyecto, el esquema de soporte post-lanzamiento y el proceso formal para gestionar cambios de alcance. Sin estos elementos, cualquier desacuerdo posterior queda sin mecanismo de resolución claro.
Conclusión
Contratar bien un proyecto de software a medida en Chile requiere preparación antes de hablar con cualquier proveedor. Los cinco errores descritos en esta guía son prevenibles: con un alcance bien definido, una evaluación técnica rigurosa, expectativas claras sobre el post-lanzamiento y métricas acordadas desde el inicio.
Una empresa que invierte dos o tres días en preparar bien su proceso de selección tiene una probabilidad significativamente mayor de terminar con un sistema que funciona y que sigue mejorando con el tiempo. El costo de esa preparación es una fracción del costo de rehacerun proyecto mal contratado.
Si quieres una primera conversación para entender si tu proyecto encaja con nuestra forma de trabajo, contáctanos. El diagnóstico es gratuito y te entregamos una propuesta con opciones en menos de una semana.
Preguntas frecuentes
¿Cuántos proveedores debo cotizar antes de contratar?
Al menos tres. Menos de tres no te da perspectiva real del mercado; más de cinco aumenta la carga de evaluación sin mejorar proporcionalmente la calidad de la decisión. Tres propuestas bien analizadas son suficientes para identificar rangos de inversión razonables, diferencias metodológicas y señales de alerta claras en cada propuesta.
¿Qué pasa si el proveedor no quiere entregar el código fuente al término del proyecto?
Es una señal de alerta importante. El código de un sistema desarrollado a medida para tu empresa debe ser tuyo. Si el proveedor retiene el código fuente como mecanismo de retención, estás construyendo una dependencia permanente que te obligará a seguir pagando indefinidamente por cualquier cambio o corrección. Exige explícitamente en el contrato que el código fuente, la documentación técnica y los accesos a los repositorios sean entregados al cierre del proyecto.
¿Es normal que un proyecto de software cambie de precio durante el desarrollo?
Los cambios de precio son normales cuando el alcance cambia. Lo que no es normal es que el alcance cambie por ambigüedad en la propuesta original. Un contrato sólido incluye un proceso de gestión de cambios documentado: cualquier modificación al alcance original se evalúa por separado con su costo y plazo adicional. Si el proveedor sube el precio sin una solicitud de cambio formal documentada, es una señal de mala planificación inicial, no de un proyecto complejo.
¿Cómo sé si el proveedor tiene suficiente experiencia para mi tipo de proyecto?
Pide proyectos de referencia comparables al tuyo en tres dimensiones: mismo tipo de sistema (ERP, app móvil, automatización de procesos), nivel de complejidad similar (número de módulos, integraciones requeridas) y preferiblemente en tu misma industria o en una con procesos similares. No te quedes con el portafolio visual. Habla directamente con un cliente anterior y pregunta qué desafíos técnicos tuvo el proyecto y cómo los resolvió el equipo en tiempo real.
¿Cuánto tiempo toma un diagnóstico técnico antes de iniciar el desarrollo?
Un diagnóstico serio toma entre 2 y 5 días hábiles de trabajo conjunto entre tu equipo y el proveedor. Incluye levantamiento de requerimientos por módulo, revisión de sistemas existentes e integraciones necesarias, y definición del alcance técnico con criterios de aceptación. Cualquier empresa que cotice en menos de una hora sin haber revisado los detalles de tu operación está estimando por experiencia previa, no diagnosticando tu caso concreto.
¿Qué debe incluir un contrato de desarrollo de software a medida para ser sólido?
Como mínimo: descripción del alcance técnico acordado con criterios de aceptación, hitos de entrega con fechas, propiedad del código fuente al término del proyecto, esquema de soporte y garantía post-lanzamiento, proceso formal de gestión de cambios de alcance y condiciones de confidencialidad. Sin estos elementos, cualquier desacuerdo posterior queda sin mecanismo de resolución claro y la negociación se vuelve muy asimétrica.
¿Cuándo conviene pedir un MVP en lugar del sistema completo desde el inicio?
Cuando el problema a resolver está bien definido pero la solución técnica óptima todavía tiene incertidumbre. Un MVP de 6 a 10 semanas que llega a usuarios reales genera datos concretos que mejoran las decisiones de las fases siguientes. Si el problema ya está claro y la solución técnica también, un MVP puede ser innecesariamente restrictivo y generar retrabajo. La decisión correcta depende del nivel de incertidumbre sobre la solución, no del tamaño del presupuesto disponible.
