Cómo elegir una empresa de desarrollo de software
Qué preguntar antes de contratar, qué señales indican que el proyecto va a salir mal y qué cláusulas conviene dejar cerradas antes de empezar.
6 de julio de 2026 · Diego Osvaldo Díaz · 2 min de lectura · Actualizado el
Elegir una empresa de desarrollo es evaluar tres cosas: si entienden tu problema antes de proponer una solución, si pueden mostrar trabajos comparables, y si dejan por escrito el alcance, la propiedad del código y qué pasa después de la entrega.
La primera señal está en la primera reunión
Un buen proveedor dedica la primera conversación a preguntar: cómo funciona el proceso hoy, qué sistemas usás, quién lo opera, dónde se traba. Uno que llega con la solución armada antes de escuchar el problema está vendiendo lo que ya tiene hecho.
Si en la primera reunión te dieron un precio cerrado sin relevar nada, ese número va a cambiar. La única pregunta es cuándo.
Qué preguntar
- ¿Hicieron algo parecido antes? ¿Puedo ver el caso o hablar con ese cliente?
- ¿Quién va a trabajar en mi proyecto y con qué dedicación?
- ¿Cómo manejan los cambios de alcance durante el desarrollo?
- ¿Cada cuánto voy a ver algo funcionando?
- ¿Qué pasa si el proyecto se atrasa?
- ¿El código queda a nombre de mi empresa?
- ¿Qué incluye la garantía y por cuánto tiempo?
- ¿Cómo es el soporte después de la entrega y cuánto cuesta?
Señales de alerta
| Criterio | Señal | Qué suele indicar |
|---|---|---|
| Precio cerrado sin relevamiento | Alerta | El presupuesto se va a corregir hacia arriba |
| No muestran trabajos anteriores | Alerta | No hay experiencia comparable o no hubo permiso |
| Prometen plazos sin condiciones | Alerta | No contemplan la validación de tu equipo |
| Evitan hablar del mantenimiento | Alerta | El costo real está diferido |
| No definen quién es dueño del código | Alerta grave | Dependencia futura del proveedor |
Local, remoto o mixto
La cercanía física importa menos que la disponibilidad y el idioma del negocio. Un equipo remoto que entiende tu industria y responde en tu huso horario suele funcionar mejor que uno cercano que no conoce el rubro. Lo que sí conviene verificar es que exista una persona identificable como responsable del proyecto, no una casilla de correo.
Qué tiene que quedar por escrito
- El alcance detallado, con lo que está incluido y lo que queda afuera.
- El mecanismo para pedir y cotizar cambios.
- La propiedad intelectual del código y la entrega de accesos y documentación.
- El plazo, con las dependencias de tu lado explicitadas.
- La garantía: qué cubre, por cuánto tiempo y con qué tiempos de respuesta.
- Las condiciones de salida: qué se entrega si el proyecto se interrumpe.
La última es la que nadie quiere discutir al principio y la que más se agradece si hace falta usarla.
En resumen
Elegí por cómo relevan tu problema, no por la presentación. Pedí trabajos comparables, preguntá quién va a estar en el proyecto y dejá por escrito alcance, propiedad del código, garantía y condiciones de salida. Un precio cerrado dado sin relevamiento es la señal de alerta más confiable.
Preguntas frecuentes
¿Conviene un freelance o una empresa?
Un freelance puede ser adecuado para un alcance chico y acotado. Para sistemas que la empresa va a usar durante años pesa más la capacidad de sostenerlo: continuidad, documentación y que no dependa de una sola persona.
¿Cómo verifico la experiencia de un proveedor?
Pedí casos comparables al tuyo y, si es posible, hablar con esos clientes. Un caso publicado con problema, solución y resultado dice más que un listado de tecnologías.
¿El código tiene que quedar a nombre de mi empresa?
Es lo recomendable, junto con la documentación y los accesos. Sin eso, cambiar de proveedor más adelante se vuelve caro y lento.
¿Qué hago si recibo presupuestos muy distintos?
Llevalos a una grilla de ítems equivalentes. La diferencia casi siempre está en lo que uno incluye y el otro no: migración de datos, integraciones, capacitación o soporte.