Agencia, freelance o equipo interno: qué conviene según la etapa de tu empresa
Los tres modelos para construir software tienen costos ocultos distintos. Criterios para elegir según etapa, volumen de proyectos y tolerancia al riesgo operativo.
Un freelance conviene para alcance cerrado y bajo riesgo operativo. Una agencia conviene cuando el proyecto cruza varias disciplinas y necesitas continuidad. Un equipo interno solo se paga si vas a construir software de forma continua durante años. La pregunta no es cuál es mejor, sino cuál corresponde a tu etapa.
La decisión entre freelance, agencia y equipo interno rara vez se toma con criterios claros. Se toma por presupuesto disponible, por una recomendación, o por lo que se hizo la vez pasada. El resultado es que muchas empresas contratan el modelo correcto en el momento equivocado — y lo caro no fue la tarifa, fue el retrabajo.
Los tres modelos funcionan. Lo que cambia entre ellos no es tanto la calidad como el tipo de riesgo que asumes y quién lo absorbe cuando algo sale distinto a lo planeado.
¿Qué estás comprando realmente en cada modelo?
Con un freelance compras horas de una disciplina. Con una agencia compras un resultado que cruza varias disciplinas. Con un equipo interno compras capacidad instalada y conocimiento acumulado de tu operación. Son tres cosas distintas y confundirlas es el origen de casi todos los proyectos que se caen.
| Freelance | Agencia | Equipo interno | |
|---|---|---|---|
| Compras | Horas de una disciplina | Un resultado multidisciplinario | Capacidad instalada |
| Arranque | Días | 2 a 4 semanas | 3 a 6 meses |
| Riesgo de continuidad | Alto: una persona | Medio: contrato y relevo | Bajo mientras no rote |
| Costo de coordinación | Lo absorbes tú | Lo absorbe el proveedor | Lo absorbes tú |
| Conviene cuando | Alcance cerrado y acotado | Proyecto con integraciones y varias disciplinas | Software continuo durante años |
¿Cuándo un freelance es la decisión correcta?
Cuando el alcance está cerrado, cabe en una sola disciplina y tú puedes especificarlo con precisión. Una landing, un módulo aislado, un rediseño de pantallas sobre un producto que ya existe. Si puedes escribir en una página qué se entrega y cómo se verifica que está bien, un freelance es la vía más eficiente.
Deja de serlo en el momento en que el proyecto necesita diseño, backend, QA e infraestructura al mismo tiempo. Ahí el freelance se convierte en varios freelances, y la coordinación entre ellos —que es trabajo real, especializado y de tiempo completo— cae sobre ti sin que la hayas presupuestado.
¿Cuándo conviene una agencia?
Cuando el valor del proyecto está en conectar cosas: un software a la medida que hable con el ERP, una app que dependa de APIs de terceros, una plataforma que tenga que sostener varios roles y perfiles de usuario. Ahí lo que compras no es programación, es la capacidad de que cinco especialidades lleguen coordinadas a la misma fecha.
También conviene cuando la continuidad importa más que el precio. Un proveedor con estructura puede reemplazar a una persona sin que el proyecto se detenga. Un freelance que se enferma, cambia de trabajo o simplemente deja de responder, detiene todo — y el conocimiento se va con él.
¿Cuándo se justifica un equipo interno?
Cuando el software deja de ser un proyecto y se vuelve una función permanente. La señal clara es el volumen: si vas a construir y mantener varios productos de forma continua durante años, contratar sale más barato que subcontratar. Si vas a hacer un producto y luego mantenerlo, no.
El error frecuente es contratar a un desarrollador senior para “tener a alguien de sistemas” y esperar que cubra diseño, arquitectura, QA y operación. Una persona no es un equipo. Ese arreglo produce dependencia total de un individuo, que es el peor riesgo de los tres modelos.
El modelo híbrido que sí funciona
En la práctica, las empresas medianas que mejor resuelven esto combinan: un responsable interno que entiende el negocio y es dueño del producto, y un proveedor externo que aporta la capacidad de ejecución. El interno decide qué y por qué; el externo resuelve el cómo.
Ese responsable interno no necesita ser técnico. Necesita conocer la operación a fondo, tener autoridad para decidir alcance, y disponer de tiempo real para el proyecto. Cuando ese rol no existe o está saturado, cualquiera de los tres modelos falla.
El proveedor correcto en la etapa equivocada cuesta más que el proveedor equivocado en la etapa correcta.
Cómo decidir sin sobrepensarlo
- ¿Puedes especificar el entregable en una página y verificarlo sin ayuda técnica? Freelance.
- ¿El proyecto necesita hablar con sistemas que ya operan? Agencia.
- ¿Vas a construir software de forma continua los próximos tres años? Equipo interno, y aun así con apoyo externo al inicio.
- ¿Hay alguien interno con tiempo real y autoridad para ser dueño del producto? Si no, resuélvelo antes de contratar a quien sea.
Puntos clave
- Freelance = horas de una disciplina. Agencia = resultado multidisciplinario. Interno = capacidad instalada.
- El costo de coordinar varios freelances suele exceder el ahorro en tarifa.
- Un equipo interno se paga solo si construyes software de forma continua durante años.
- Sin un dueño interno del producto con tiempo y autoridad, los tres modelos fallan igual.
Preguntas frecuentes
Respuestas directas para cotizar, decidir stack o validar si conviene construir.
En tarifa por hora, sí. En costo total del proyecto, frecuentemente no. Con varios freelances la coordinación, el QA y la integración quedan a cargo de tu equipo, y ese tiempo interno rara vez se presupuesta. En proyectos de una sola disciplina el freelance sí sale más barato.
Un equipo mínimo viable son cuatro perfiles: producto, diseño, desarrollo y QA. Contratar solo a un desarrollador senior no constituye un equipo y genera dependencia total de una persona, que es el riesgo operativo más alto de los tres modelos.
Sí, y es la ruta más común en empresas medianas. Para que funcione, la transferencia debe pactarse desde el contrato: documentación, acceso a repositorios, propiedad intelectual y un periodo de acompañamiento. Sin eso, internalizar significa empezar de cero.
Pierdes el avance no documentado y el conocimiento del proyecto. Se mitiga exigiendo desde el inicio que el código viva en un repositorio tuyo, con commits frecuentes y documentación mínima. Aun así, el reemplazo implica semanas de recuperación de contexto.
Si tiene usuarios con roles distintos, se conecta con algún sistema existente, maneja pagos o datos sensibles, o debe funcionar en móvil y escritorio, ya cruza varias disciplinas. Prácticamente cualquier proyecto que toque la operación real cae en esta categoría.
API, RPA o IoT en planta: cuándo cada uno
API vs RPA vs IoT en planta: cuándo cada capa, cómo conviven en un mismo flujo y qué se rompe si eliges mal. Criterios para México, sin demo de fábrica 4.0.
Automatización industrial en México: qué sí conviene digitalizar primero
Diferencia entre automatizar planta (OT/IoT) y digitalizar operación con ERP: criterios para priorizar el primer flujo con ROI visible.
Agente de IA empresarial vs chatbot: qué sí mueve operación
Cuándo un agente con datos y herramientas acotadas aporta ROI — y cuándo un chat genérico solo genera demos.