Casi todas las empresas que nos escriben llegan por el mismo camino: necesitan software que no existe en el mercado y no tienen (ni quieren montar todavía) un equipo técnico propio. A partir de ahí se preguntan «¿freelance o agencia?», y es la pregunta equivocada. La que decide si el proyecto sale bien es otra: cuando el programa falle un martes a las nueve de la mañana, ¿quién responde, con qué documentación y sobre qué código?
Esta guía es para quien va a contratar un equipo de desarrollo externo por primera vez: las cuatro formas de hacerlo, qué exigir por escrito y qué señales leer como un «no».
Las cuatro formas de contratar desarrollo externo
Lo que diferencia a los cuatro modelos del mercado español no es la calidad del código: es quién asume el riesgo, quién documenta y qué te queda al terminar.
- Freelance suelto. Su riesgo no es la calidad, es el bus factor: si cambia de cliente o se pone enfermo, el proyecto se queda sin su única memoria.
- Agencia o estudio. Varias personas y continuidad si alguien se va, pero suele haber una capa de gestión entre tú y quien programa, y ahí se pierden los matices de tu proceso.
- Factoría de software. Encargas unidades de trabajo (horas, sprints, tickets) y asignan a quien tenga libre: escala bien, pero el conocimiento de tu negocio no se acumula en nadie (lo explicamos en qué es una factoría de software).
- Equipo dedicado. Perfiles externos con tus herramientas y en tus reuniones: lo más parecido a tener plantilla sin contratarla. Funciona cuando ya hay alguien dentro que sabe qué construir; si no lo hay, ese hueco se cubre con CTO as a Service.
| Modelo | Encaja cuando… | Su riesgo principal |
|---|---|---|
| Freelance suelto | El alcance es pequeño y está bien definido | Una sola persona concentra todo el conocimiento |
| Agencia / estudio | Quieres producto terminado y un único responsable | Distancia entre quien decide y quien programa |
| Factoría de software | Tienes criterio técnico propio y mucho volumen | Se cobra por horas, no por problemas resueltos |
| Equipo dedicado | Hay producto a largo plazo y dirección técnica interna | Coste fijo alto y dependencia si no hay traspaso |
La pregunta que casi nadie hace: ¿dónde se queda el conocimiento?
Un proyecto de software a medida produce dos cosas. El código, que se puede copiar. Y el criterio: por qué los descuentos se calculan así, por qué existe ese estado del pedido, qué pasa con los albaranes de la delegación. Eso no está en el repositorio, está en la cabeza de quien programó.
Lo importante, entonces, no es el modelo, sino si al terminar ese criterio vive en algún sitio al que puedas acceder: documentación funcional en lenguaje de negocio, un proyecto que arranque de cero en un ordenador nuevo siguiendo un fichero de instrucciones y las decisiones raras explicadas por escrito. Si un proveedor te dice que «el código se documenta solo», está diciendo que el conocimiento se va con él.
Qué exigir por escrito antes de firmar
Esta es la parte que separa un proyecto que puedes retomar con otro equipo de uno del que eres rehén. Cualquier proveedor serio lo acepta sin discutir.
- Cesión expresa de los derechos de explotación, por escrito. Es lo que más sorpresas da en España. Con un trabajador en nómina se presumen cedidos a la empresa (art. 97.4 de la Ley de Propiedad Intelectual, salvo pacto distinto); con un proveedor externo no hay esa presunción: el autor los conserva salvo cesión, que debe constar por escrito y alcanza solo a lo pactado. Pagar la factura no te hace titular de nada. Pide cesión en exclusiva, sin límite de plazo ni territorio y con derecho a modificar la obra y a encargar su mantenimiento a terceros.
- El repositorio a tu nombre desde el primer commit, no al entregar: la cuenta de GitHub o GitLab es de tu empresa y el proveedor entra como colaborador. Es gratis y evita la mayoría de los divorcios feos.
- Alcance y criterio de aceptación. Qué pantallas, qué roles, qué integraciones y qué se considera «terminado»; sin eso no se puede discutir si algo entra en el presupuesto. Ahí ayuda nuestra guía sobre cómo pedir presupuesto de software.
- Precio cerrado o bolsa de horas, pero dicho claro. Los dos son legítimos; lo que no lo es es una estimación por horas presentada como precio. Si es bolsa, pregunta qué ocurre cuando se agote a mitad de camino.
- Titularidad de todas las cuentas: dominio, servidor, base de datos, App Store y Google Play, pasarela de pago, claves de IA. A nombre de tu empresa, con el proveedor como usuario. Que la ficha de tu app viva en la cuenta de la agencia es un problema que solo se descubre al querer cambiarla.
- Contrato de encargado del tratamiento si hay datos personales. Si el proveedor va a ver datos de tus clientes, pacientes o empleados, el artículo 28 del RGPD exige un contrato que regule ese tratamiento, y la responsabilidad es tuya.
- Garantía y mantenimiento evolutivo presupuestados aparte, con tiempos de respuesta y la opción de no contratarlos.
- Salida ordenada: si cualquiera de las partes se va, el proveedor entrega código, credenciales, documentación y una sesión de traspaso. Se firma al principio, que es cuando nadie se opone.
Señales de alarma que conviene leer como un «no»
- No te dejan hablar con la persona que va a programar, ni antes ni después de firmar.
- El software «se queda alojado en nuestra infraestructura» y no hay forma clara de llevárselo.
- Se subcontrata sin decírtelo: pregunta quién escribe el código y desde dónde.
- No hay nada que ver hasta el final. Sin demo cada una o dos semanas no se corrige el rumbo cuando aún es barato.
- El presupuesto no separa desarrollo, licencias de terceros y cuotas recurrentes, así que no sabes qué seguirás pagando el año que viene.
- Te dicen «sí» a todo en la primera reunión. Un buen proveedor te discute algo.
Cómo evaluar un equipo antes de comprometerte
La forma más fiable de saberlo no es pedir referencias: es trabajar con él una semana. Encarga un bloque pequeño, pagado y con entregable real —un módulo, una integración, un prototipo de las tres pantallas principales— y mira lo que no sale en el portfolio: cuánto tarda en contestar, si pregunta por tu negocio o solo por los requisitos, si avisa de los problemas antes o después de que ocurran, y si lo que entrega se ejecuta sin que él esté delante. Y pide ver un proyecto en producción, no capturas de pantalla.
Cómo lo hacemos nosotros
En FastIA trabajamos como un equipo pequeño con trato directo: hablas con quien programa tu software, sin capa intermedia. Presupuesto cerrado por escrito antes de empezar, demo funcionando cada semana y el código 100% de tu empresa, con el repositorio y los accesos a tu nombre y sin cuotas mensuales por usar tu propio programa. Es deliberado: para una herramienta interna —un CRM a medida, un portal de cliente, un programa que sustituye tres hojas de cálculo— una o dos personas con acceso directo a quien conoce el proceso van más rápido que una estructura grande. Si lo que necesitas es reforzar tu equipo, lo hacemos con desarrolladores freelance; si falta dirección técnica, con CTO as a Service; y si quieres el producto terminado, con desarrollo de software a medida. Sede en Madrid y trabajo con empresas de toda España.
Preguntas frecuentes
¿Cómo me aseguro de que el código es realmente mío?
Con dos cosas a la vez: cesión expresa de los derechos de explotación por escrito (en una contratación externa no se presume cedida) y control del repositorio y de las cuentas desde el primer día. Lo primero te da el derecho; lo segundo, la capacidad de ejercerlo sin pedir permiso.
¿Puedo cambiar de proveedor a mitad de proyecto?
Sí, y es más habitual de lo que parece. El coste lo determina lo que firmaste al principio: con el código en tu repositorio, un entorno que arranca siguiendo instrucciones y documentación mínima, el relevo es cuestión de días.
¿Qué pido en la primera reunión para distinguir a un buen proveedor?
Que te enseñe algo suyo en producción, que te diga quién va a escribir el código y que te explique con sus palabras cómo funciona tu proceso. La tercera es la que separa: quien ha entendido tu problema lo sabe contar sin repetir tu vocabulario de memoria.
Contratar desarrollo externo no es elegir entre freelance y agencia: es decidir con qué condiciones quieres quedarte cuando el proyecto termine. Con la cesión firmada, el repositorio a tu nombre, el alcance definido y una demo cada semana, cualquiera de los cuatro modelos funciona; sin eso, ninguno te protege. Si quieres una opinión sin compromiso sobre cuál te encaja, cuéntanos tu caso: te diremos también cuándo no hace falta desarrollar nada.