¿Es mejor desarrollar el software internamente o contratar a un externo?
Conviene hacerlo dentro cuando el desarrollo está en el centro de tu propuesta de valor y puedes asumirlo en dinero y en tiempo sin frenar tu operación. Conviene un equipo externo para experimentar, para desarrollos acotados, cuando tiene más experiencia que tu equipo en lo que quieres construir o cuando no puedes parar tu día a día. En los dos casos, el mayor riesgo suele ser empezar sin una buena definición.
Somos un equipo externo, así que empezamos por los casos en los que recomendamos hacerlo dentro.
Cuándo hacerlo dentro
- Cuando está en el centro de tu propuesta de valor. Si tienes que dominar la solución de principio a fin y tiene muchas ramificaciones en tu negocio, un equipo externo aumenta el riesgo de que algo no encaje.
- Cuando puedes asumirlo. Si reasignar personas y tiempo a este proyecto no te impide seguir generando ingresos.
- Cuando no encuentras un proveedor que documente bien. Sin documentación, quien retome el proyecto depende del equipo que lo hizo.
Cuándo contratar un equipo externo
- Para experimentar o para desarrollos acotados.
- Cuando no puedes parar tu operación. Un tercero analiza y propone mejoras mientras tu equipo sigue con su día a día.
- Cuando tiene más experiencia que tu equipo en lo que quieres construir, o puede hacerlo más rápido y mejor.
- Cuando da garantías sobre lo que entrega. En cómo elegir una empresa de desarrollo de IA explicamos qué pedir.
La opción mixta
Una situación habitual: tienes un problema, pero no puedes parar tu operación. Un equipo externo desarrolla una segunda versión y después forma a tu equipo para usarla y mantenerla. Para que funcione, el externo tiene que dejar el contexto y las decisiones documentados, de forma que tu equipo pueda seguir sin depender de él.
Costes y riesgos que no se ven al principio
En nuestra experiencia, el mayor coste suele venir de una mala definición. Antes de programar hace falta una fase de discovery que deje claro qué se quiere y para qué. Si se empieza a desarrollar lo que pide cada stakeholder, sin esa fase, el coste aparece después: mal alcance, retrasos, sobrecostes, trabajo rehecho y bugs.
Otros riesgos, en cualquiera de las dos opciones:
- No documentar, lo que crea dependencia del equipo que lo hizo.
- No incorporar pruebas en el proceso de desarrollo.
- No medir el antes y el después, lo que impide demostrar el impacto.
Interno o externo, en una tabla
| Situación | Mejor opción |
|---|---|
| Es el centro de tu propuesta de valor y puedes asumirlo | Interno |
| No encuentras un proveedor que documente bien | Interno |
| Quieres experimentar o es un desarrollo acotado | Externo |
| No puedes parar tu operación | Externo, o mixta con traspaso |
| El externo tiene más experiencia en lo que quieres construir | Externo |
| Necesitas una segunda versión y quedarte con ella | Mixta: el externo desarrolla y forma a tu equipo |
Un ejemplo
En TIFIN, una fintech de EE. UU. con varios productos de wealth management, el equipo de Criterian se integró en el del cliente durante una fase de crecimiento en la que la plataforma tenía que escalar con alta disponibilidad. Hicimos una migración progresiva de monolito a microservicios: la latencia de la API bajó de 320 ms a 112 ms y el coste de infraestructura se redujo un 40 %. Es un ejemplo de equipo externo integrado en el del cliente para aportar experiencia en arquitectura.
¿Dudas entre hacerlo dentro o fuera?
Cuéntanos qué quieres construir y te decimos qué opción vemos más adecuada, aunque sea hacerlo con tu equipo.
Hablemos