Freelance o agencia: a quién contratar para tu app, web o IA
Cómo decidir entre un desarrollador freelance o una agencia: comparativa, cómo hacer el brief, señales de alarma, hitos, propiedad del código y mantenimiento.
Si necesitas que te desarrollen una app, una web o una automatización, la decisión entre freelance o agencia depende sobre todo de tres cosas: el tamaño del proyecto, cuántas disciplinas hacen falta a la vez y quién lo va a mantener cuando esté en marcha. Un freelance encaja bien en proyectos acotados donde quieres hablar directamente con quien construye; una agencia, cuando necesitas varios perfiles trabajando en paralelo o un equipo que absorba bajas y picos.
Lo digo siendo consultor y desarrollador autónomo, y después de más de siete años creando productos propios, así que tenlo en cuenta. He intentado escribir la guía que me gustaría que leyeran mis clientes antes de llamar a nadie, incluida a mí.
Freelance o agencia: la respuesta corta
- Elige un freelance si el proyecto lo puede llevar una persona (o una persona con algún apoyo puntual), quieres trato directo y velocidad, y el alcance está razonablemente claro.
- Elige una agencia si necesitas a la vez diseño, desarrollo de varias plataformas, marketing y gestión de proyecto, si el plazo es muy agresivo o si tu organización exige un proveedor con estructura (contratación pública, departamentos de compras exigentes).
- Una opción intermedia que funciona bien: un freelance sénior que lidera la parte técnica y coordina a uno o dos especialistas cuando hace falta.
Cuándo encaja un desarrollador freelance
Un freelance suele ser la mejor opción cuando:
- El problema es concreto. Automatizar un proceso, integrar dos sistemas, lanzar una primera versión de una app o una web con funcionalidades a medida.
- Quieres hablar con quien escribe el código. Sin intermediarios, las decisiones técnicas se toman en una conversación y no en tres reuniones.
- Valoras la continuidad de una persona. La misma persona que lo construyó lo conoce a fondo cuando hay que tocarlo un año después.
- Necesitas criterio técnico, no solo manos. Un buen freelance te dice qué no hacer, qué servicio ya existe y qué parte se puede dejar para la segunda versión.
Un freelance con trayectoria también puede cubrir más de lo que parece. En mi caso he trabajado en bots a gran escala como CactusFire, que está en más de 295.000 servidores de Discord; en la app Buscamot, un juego diario en catalán; en una plataforma de IA corporativa como elXat; y en la tienda solidaria Closcaverda para la Fundació CRAM. No lo cuento para venderte nada, sino para que, cuando valores a un freelance, mires la variedad de lo que ha llevado a producción y no solo su lista de tecnologías.
Cuándo encaja mejor una agencia
Una agencia tiene sentido cuando:
- El proyecto necesita muchos perfiles a la vez. Diseño de marca, UX, desarrollo web, app nativa para iOS y Android, contenidos, campañas.
- El plazo no permite trabajar en serie. Si todo tiene que avanzar en paralelo, una persona sola no llega.
- Necesitas redundancia. Si una persona se pone enferma, la agencia pone a otra. Con un freelance, depende de cómo se haya organizado.
- Tu organización necesita un proveedor con estructura. Algunas empresas y administraciones exigen solvencia, seguros o certificaciones que un autónomo puede no tener.
El riesgo de la agencia es el contrario: que quien te vendió el proyecto no sea quien lo hace, que cambien las personas a mitad de camino y que cada ajuste pase por una cadena de gestión.
Comparativa: freelance vs agencia
| Freelance | Agencia | |
|---|---|---|
| Estructura de coste | Pagas sobre todo horas de trabajo técnico | Pagas también gestión, comercial y estructura |
| Velocidad de arranque | Rápida si tiene hueco; depende de su agenda | Más lenta al inicio, más capacidad después |
| Continuidad | Alta si la persona sigue disponible; riesgo si desaparece | Equipo que absorbe bajas, pero con rotación de personas |
| Amplitud de perfiles | Limitada a lo que domina esa persona y su red | Amplia: diseño, desarrollo, marketing, gestión |
| Comunicación | Directa con quien construye | A través de un gestor de cuenta o de proyecto |
| Riesgo principal | Dependencia de una sola persona | Sobrecoste y pérdida de contexto entre capas |
Cómo escribir un buen brief para un proyecto digital
Un buen brief te ahorra presupuestos inflados por incertidumbre. No necesitas lenguaje técnico. Necesitas responder a esto:
- Qué problema de negocio resuelve. No «quiero una app», sino «nuestros técnicos pierden una hora al día pasando partes a mano».
- Quién lo va a usar. Clientes, empleados, voluntarios. Cuántos, aproximadamente, y desde qué dispositivos.
- Qué existe ya. Web actual, CRM, ERP, hojas de cálculo, servicios contratados. Las integraciones suelen ser la parte más difícil.
- Qué es imprescindible en la primera versión y qué puede esperar. Separa el «tiene que» del «estaría bien».
- Restricciones. Fecha límite real (y por qué), rango de presupuesto, requisitos de protección de datos o de accesibilidad.
- Quién decide. Una persona de contacto que pueda aprobar entregas sin esperar a un comité.
- Cómo sabrás que ha funcionado. Menos tiempo en una tarea, más pedidos, menos llamadas al soporte.
Si el proyecto incluye inteligencia artificial y datos de personas, añade un apartado sobre eso. Te explico lo básico en ChatGPT en la empresa y RGPD, y si la idea es que la IA responda con tus documentos, en qué es RAG.
Preguntas que hacer antes de contratar a un desarrollador
- ¿Qué proyectos parecidos tienes en producción y puedo verlos funcionando?
- ¿Quién va a escribir el código exactamente?
- ¿Cómo vas a dividir el proyecto en entregas y qué veré en cada una?
- ¿Dónde estará el código y a nombre de quién estarán las cuentas?
- ¿Qué tecnologías propones y por qué esas? ¿Será fácil encontrar a otra persona que las mantenga?
- ¿Qué pasa después del lanzamiento: quién actualiza, quién responde si algo falla y en cuánto tiempo?
- ¿Qué parte de lo que pido no harías, o harías de otra forma?
La última pregunta es la que más dice. Quien solo dice que sí a todo, o no ha entendido el proyecto, o no le importa.
Señales de alarma al contratar un freelance o una agencia
- Presupuesto cerrado sin preguntas. Si te dan precio sin entender el problema, el precio está mal (por arriba o por abajo).
- Nada en producción que enseñar. Capturas y maquetas no bastan.
- Las cuentas a su nombre. Dominio, hosting o repositorio registrados por el proveedor «para simplificar».
- Pago íntegro por adelantado en un proyecto de varios meses.
- Sin entregas intermedias. Desaparecer semanas y volver con todo «terminado».
- Tecnología exótica o propietaria que solo esa persona o empresa puede mantener.
- Nadie habla de mantenimiento. Ningún software en producción se mantiene solo.
Hitos, propiedad del código y cuentas a tu nombre
Esta es la parte que más problemas evita y la que menos gente negocia.
Divide el proyecto en hitos
Cada hito debería tener un entregable que puedas ver y probar, unos criterios de aceptación claros y un pago asociado. Por ejemplo: prototipo navegable, primera versión con las funciones imprescindibles, versión publicada. Si un hito no se cumple, sabes pronto que algo va mal y no has pagado todo.
Todo a nombre de tu organización
Desde el primer día, a tu nombre y con acceso para quien desarrolla:
- Dominio y DNS.
- Repositorio de código (por ejemplo, una organización de GitHub o GitLab tuya).
- Cuenta de la nube o del hosting, con la facturación a tu nombre.
- Cuentas de desarrollador en App Store y Google Play si hay app móvil.
- Claves de servicios externos: pagos, correo transaccional, modelos de IA, analítica.
Si el proveedor desaparece, puedes dar acceso a otra persona en una tarde. Si todo está a su nombre, puedes tardar semanas, o no recuperarlo.
Derechos sobre el código
El contrato debería decir que los derechos de explotación del código desarrollado para ti se te ceden al pagar, y qué partes no (librerías de código abierto, componentes que el proveedor reutiliza en otros proyectos). No soy abogado: pide a tu asesor que revise esta cláusula.
Mantenimiento después del lanzamiento
El lanzamiento es el principio. Después hay que actualizar dependencias, aplicar parches de seguridad, renovar certificados, vigilar que los servidores no se llenen, hacer copias de seguridad y adaptarse cuando un servicio externo cambia su API.
Cuanto más crece un proyecto, más pesa esta parte. Lo he vivido con CactusFire: llevar un bot de Discord de unos pocos servidores a cientos de miles obliga a rediseñar piezas que al principio funcionaban sin problemas. Lo cuento en cómo escalar un bot de Discord con sharding.
Antes de firmar, acuerda:
- Qué incluye el mantenimiento: actualizaciones, monitorización, copias de seguridad, pequeños cambios.
- Tiempos de respuesta según la gravedad: no es lo mismo una caída que un texto mal escrito.
- Cómo se piden y presupuestan los cambios nuevos, que no son mantenimiento.
- Documentación mínima: cómo se despliega, dónde están las cosas y qué servicios externos se usan.
Mi recomendación, sea quien sea el que contrates: elige a quien te hable de esto sin que se lo preguntes. Si quieres comentar un proyecto concreto, puedes escribirme desde contacto.
Preguntas frecuentes
¿Es más barato contratar un freelance que una agencia?
Normalmente un freelance tiene menos estructura que repercutir en el precio, así que por la misma tarea suele costar menos. Pero el coste real depende del alcance, de cuántos perfiles necesita el proyecto y del mantenimiento posterior. Compara presupuestos con el mismo brief y el mismo nivel de detalle.
¿Quién debe ser el propietario del código, el dominio y las cuentas?
Tú. El dominio, el repositorio, la cuenta de la nube, las tiendas de aplicaciones y las claves de los servicios externos deberían estar a nombre de tu organización desde el primer día, con acceso para quien desarrolla. El contrato debería dejar claro que los derechos sobre el código pasan a ti al pagar.
¿Qué pasa si el freelance deja de estar disponible?
Es el riesgo principal de trabajar con una sola persona. Se mitiga con el código en tu repositorio, documentación básica de cómo desplegar, credenciales en tu poder y un acuerdo de mantenimiento con plazos de respuesta. Así otra persona puede retomar el proyecto.
¿Cómo sé si un desarrollador freelance es fiable?
Pide ver proyectos reales en producción, no solo capturas, y habla con alguien para quien haya trabajado. Fíjate en si hace preguntas sobre tu negocio, si te propone empezar por algo pequeño y si te explica qué pasará después del lanzamiento.