Guías

    ¿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.

    , CPO & AI StrategyPublicado el 3 min lectura

    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ónMejor opción
    Es el centro de tu propuesta de valor y puedes asumirloInterno
    No encuentras un proveedor que documente bienInterno
    Quieres experimentar o es un desarrollo acotadoExterno
    No puedes parar tu operaciónExterno, o mixta con traspaso
    El externo tiene más experiencia en lo que quieres construirExterno
    Necesitas una segunda versión y quedarte con ellaMixta: 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