Freelance o agencia de desarrollo: cómo elegir y qué preguntar antes de contratar

Respuesta corta: depende del tamaño y del riesgo de tu proyecto

Soy desarrollador freelance, así que conviene decirlo desde el principio: tengo un interés en esta respuesta. Por eso voy a intentar ser concreto sobre cuándo un freelance es la mejor opción y cuándo no lo es, incluido cuándo te recomendaría buscar una agencia.

La diferencia de fondo no es el precio ni la calidad —hay freelancers excelentes y agencias deficientes, y al revés—, sino cuántas personas trabajan en tu proyecto, quién responde si algo sale mal y cuánta continuidad necesitas.

¿Qué ventajas tiene contratar a un freelance?

La principal es que hablas directamente con quien diseña, programa y prueba tu sistema. No hay un ejecutivo de cuenta que traduce tus necesidades a otra persona, así que los malentendidos se reducen y las decisiones se toman rápido.

• Comunicación directa: la persona que escucha tu problema es la que lo resuelve.
• Menos estructura que pagar: no cubres oficinas, ventas ni gerencia de proyecto.
• Arranque rápido: suele poder empezar en días, sin un proceso largo de incorporación.
• Flexibilidad: es más sencillo ajustar el alcance o trabajar por etapas pequeñas.
• Continuidad de criterio: quien construyó el sistema conoce cada decisión que tomó.

¿Cuáles son los riesgos de trabajar con una sola persona?

Son reales y es mejor hablarlos antes de empezar. El más evidente es la dependencia: si el freelance se enferma, toma otro proyecto urgente o deja de responder, tu proyecto se detiene. También hay un límite de capacidad: una sola persona no puede diseñar, desarrollar frontend y backend, probar y desplegar a la velocidad de un equipo de cinco.

La forma de mitigarlos no es evitar freelancers, sino exigir lo mismo que exigirías a cualquier proveedor: el código en un repositorio a tu nombre desde el primer día, documentación suficiente para que otra persona pueda continuar, entregas pequeñas y frecuentes, y acceso tuyo a todos los servicios (dominio, hosting, base de datos). Con eso, la dependencia deja de ser un riesgo crítico: si algo pasa, otro desarrollador puede retomar el trabajo.

¿Cuándo conviene más una agencia?

Hay proyectos en los que recomendaría una agencia aunque me lo propusieran a mí. Estos son los casos más claros:

• Necesitas diseño, desarrollo, QA y gestión de proyecto trabajando en paralelo y con un plazo corto.
• El proyecto es grande y crítico desde el primer día (por ejemplo, una plataforma con miles de usuarios activos al lanzar).
• Tu empresa exige procesos formales: fianzas, pólizas de cumplimiento, varios niveles de aprobación o soporte con horarios comprometidos por contrato.
• Requieres soporte 24/7 con tiempos de respuesta comprometidos.

Freelance vs. agencia: comparación rápida

Esta tabla resume las diferencias típicas. Son tendencias, no reglas: cada proveedor concreto puede ser la excepción.

Preguntas que debes hacer antes de contratar (a cualquiera)

Estas preguntas sirven igual para un freelance que para una agencia. Las respuestas vagas son una señal de alerta.

• ¿Qué proyectos parecidos has hecho y puedo ver alguno funcionando o su código?
• ¿Quién va a programar mi proyecto exactamente y cómo me comunico con esa persona?
• ¿Cómo divides el proyecto en etapas y qué recibo al final de cada una?
• ¿El repositorio de código, el dominio y el hosting estarán a mi nombre desde el inicio?
• ¿Qué pruebas haces antes de entregar y cómo me demuestras que funciona?
• ¿Qué pasa si quiero cambiar algo a mitad del proyecto?
• ¿Qué incluye el mantenimiento después de la entrega y cuánto cuesta?
• ¿Qué documentación me entregas para que otra persona pueda continuar el trabajo?
• ¿Qué costos mensuales tendrá el sistema (hosting, APIs, licencias) además de tu trabajo?

¿De quién es el código que pago?

Es la pregunta que más problemas evita y la que menos se hace. En México, la Ley Federal del Derecho de Autor establece que, salvo pacto en contrario, quien comisiona la producción de una obra con colaboración remunerada goza de los derechos patrimoniales sobre ella (artículo 83), y para los programas creados por empleados en ejercicio de sus funciones, esos derechos corresponden al empleador (artículo 103). Pero la misma ley pide que, para considerar una obra realizada por encargo, los términos del contrato sean claros y precisos, y en caso de duda prevalece la interpretación más favorable al autor (artículo 83 bis).

En la práctica: pon por escrito que el código desarrollado para tu proyecto es tuyo, qué componentes de terceros o librerías previas del desarrollador se usan y bajo qué licencia, y que recibirás el repositorio completo con su historial. Esto no es asesoría legal; si el proyecto es importante, que un abogado revise el contrato.

¿Cómo comparar cotizaciones de desarrollo?

Dos cotizaciones con precios muy distintos casi nunca describen el mismo trabajo. Antes de comparar montos, compara qué incluye cada una. Pide que cada propuesta detalle los módulos o páginas, las integraciones con otros sistemas, quién redacta el contenido, si incluye pruebas y documentación, cuántas rondas de cambios contempla, cuánto dura el soporte después de la entrega y qué costos mensuales tendrás aparte, como hosting o servicios de terceros.

Una buena práctica es enviar el mismo documento breve a todos los proveedores: qué problema quieres resolver, quién usará el sistema, qué herramientas usas hoy y qué fecha tienes en mente. Así las propuestas responden a la misma pregunta y la diferencia de precio se explica por el enfoque, no por malentendidos.

Señales de alerta al cotizar

Algunas señales se repiten en los proyectos que terminan mal, sin importar si el proveedor es una persona o una empresa:

• Te da precio cerrado sin hacer preguntas sobre tu operación.
• No quiere que el código o el dominio estén a tu nombre.
• Pide el pago completo por adelantado sin entregas intermedias.
• No puede mostrar trabajo previo ni explicar decisiones técnicas en palabras sencillas.
• Promete posicionamiento en Google, ventas o resultados de negocio asegurados.
• No menciona pruebas, documentación ni mantenimiento.

Cómo trabajo yo como freelance

Trabajo solo y lo digo desde el inicio. Para compensar los riesgos de depender de una persona, divido los proyectos en etapas con entregables funcionales, uso repositorios a nombre del cliente, escribo pruebas para los flujos críticos y dejo documentación de uso y despliegue. Si un proyecto necesita a más personas de las que puedo cubrir con calidad, prefiero decirlo y recomendar otra opción antes que aceptar algo que no voy a poder sostener.

Mi experiencia viene de trabajar en equipos —desarrollo y QA en ZazPay, backend en Faena Uniformes, evaluación de código en Outlier— y de proyectos propios como Menu Engine y ARE Engine que puedes revisar en este sitio.