Mi primer freelance iba a durar seis meses

Cuando acepté mi primer freelance, tenía cerca de un año y medio de experiencia profesional como desarrollador de software. Ya había construido pequeñas aplicaciones full stack para aprender, pero sentía que me faltaba una experiencia en mi trayectoria: entregar un producto completo a un cliente real. Quería entender el problema de negocio, negociar directamente con el contratante, tomar las decisiones técnicas y asumir la responsabilidad de la entrega. En otras palabras, quería experimentar lo que era ser mi propio jefe.

La oportunidad surgió en 2021, por recomendación de un antiguo compañero de trabajo: un profesional necesitaba una plataforma digital para apoyar sus actividades comerciales. Sabía que sería un desafío y estaba dispuesto a asumir los riesgos para ganar experiencia. Lo que todavía no sabía era que desarrollar la aplicación sería solo una parte del trabajo.

La primera trampa: negociar pensando solo en la experiencia

Mi motivación principal no era económica. Ya tenía empleo y veía el freelance como una oportunidad para desarrollar nuevas competencias, por eso acepté una remuneración modesta para el alcance y las responsabilidades involucradas, con la expectativa de terminar el proyecto en un plazo de seis meses. No creo que aceptar un valor menor para ganar experiencia haya sido, por sí solo, un error. El problema fue la manera en que conduje la negociación.

Mi propuesta comercial era muy simple: una descripción genérica del producto, un precio cerrado, una estimación de horas y una fecha prevista de entrega. No detallaba los requisitos, las responsabilidades de cada parte ni los criterios de aceptación, y tampoco preveía ningún procedimiento para los cambios de alcance. Para colmo, la mayor parte del pago dependía de la entrega final. En la práctica, asumí buena parte de los riesgos de un proyecto cuyas necesidades todavía no estaban del todo claras.

Hoy entiendo que es en la propuesta comercial donde se acuerdan las expectativas y las condiciones que permiten a ambas partes trabajar con previsibilidad. El precio es solo una parte de ella.

Cuando el proyecto empezó a tomar forma

Comencé el desarrollo por la interfaz, construyendo los principales flujos con datos simulados. Creía que sería más fácil empezar por el front-end, porque era donde tenía más experiencia, y quería validar el funcionamiento de la solución antes de pasar a las integraciones y los detalles visuales. El problema es que algunas reglas de negocio dependían de información que el cliente todavía tenía que pasarme. A medida que el proyecto avanzaba, me di cuenta de que entender la idea general de un producto es distinto de tener requisitos lo bastante definidos para implementarlo.

Además de entender lo que el cliente quiere construir, hay que definir cómo va a funcionar la solución y qué decisiones faltan por tomar.

Cuando el cronograma dejó de representar la realidad

A lo largo del proyecto, mi vida profesional y personal cambió bastante. Me mudé de ciudad, empecé un posgrado y pasé a repartir el tiempo entre nuevos compromisos y el desarrollo. El contratante también tenía poca disponibilidad. Con ello, el trabajo perdió ritmo y el proyecto empezó a extenderse mucho más allá de lo planeado. Reconozco que debería haber gestionado esos cambios de forma más organizada, reevaluando la planificación, registrando el estado del proyecto y renegociando las expectativas.

Cuando cambian las circunstancias que sostienen un cronograma, la planificación también tiene que revisarse.

Cuando los cambios de alcance se convirtieron en un problema

Uno de los mayores desafíos vino de los sucesivos cambios en las necesidades del proyecto. Funcionalidades ya construidas tuvieron que modificarse o rehacerse para atender a nuevas reglas de negocio, y la complejidad empezó a crecer más rápido de lo que yo podía gestionar. Hubo momentos de mucha frustración: invertía tiempo en una funcionalidad y después tenía que revisar decisiones que creía ya cerradas.

En cierto momento, la propia arquitectura pasó a ser parte del problema. Tuve que reorganizar el código y adoptar un enfoque más simple, con responsabilidades mejor separadas, para poder avanzar. Una arquitectura bien estructurada facilita los cambios, pero no elimina el costo de unos requisitos inestables.

Los cambios de alcance forman parte de muchos proyectos. Lo que tiene que quedar acordado es cómo se evaluará, negociará e incorporará cada uno al proyecto.

La entrega no es necesariamente el final

Finalmente, en agosto de 2024, concluí la entrega de la aplicación. Después, hice algunas mejoras solicitadas y ofrecí un período de soporte para corregir problemas funcionales.

La experiencia también me hizo pensar en la diferencia entre entregar una aplicación que funciona y dar las condiciones para que se pueda operar con autonomía. Algunas operaciones todavía dependían de procedimientos técnicos, porque las funcionalidades adicionales de administración no formaban parte de la solución acordada.

En mayo de 2026, hice el handoff final, organizando la documentación y la información necesarias para que otra persona diera continuidad técnica al proyecto, y así di por concluida formalmente mi participación. Esta última etapa reforzó la importancia de definir límites claros para el mantenimiento, el soporte y la evolución del software.

¿Qué haría diferente hoy?

Después de esta experiencia, empecé a ver la propuesta comercial como mucho más que un presupuesto. Si empezara un freelance hoy, prestaría especial atención a seis puntos:

1. Entender el problema antes de ponerle precio a la solución. Intentaría comprender los procesos, los objetivos y las principales restricciones del negocio.

2. Definir qué está dentro y fuera del alcance. Documentaría las funcionalidades previstas, las exclusiones y los criterios de aceptación.

3. Distribuir responsabilidades. Dejaría definido qué información, accesos, materiales y aprobaciones dependerían del cliente y cuáles serían mis obligaciones.

4. Establecer hitos de entrega y de pago. Evitaría concentrar la mayor parte de la remuneración en la conclusión del proyecto.

5. Definir un proceso para los cambios. Evaluaría el impacto en plazo y costo antes de incorporar nuevos requisitos.

6. Separar entrega, garantía, soporte y mantenimiento. Dejaría claro qué está incluido en la contratación y qué requiere un nuevo acuerdo.

Estas prácticas no eliminan los riesgos, pero hacen las expectativas más claras y la relación comercial más equilibrada.

Cómo evolucionó mi propuesta comercial

Recientemente, convertí parte de estos aprendizajes en un modelo de propuesta comercial para el desarrollo de un MVP. Es un material didáctico y ficticio: el cliente, los valores y los plazos son inventados, y el documento viene comentado, con notas que explican por qué existe cada cláusula y una página final con una lista para adaptarlo a tu proyecto. Trata el alcance, las exclusiones, las responsabilidades, los hitos y criterios de aceptación, el pago, los cambios de alcance, la garantía, el soporte y el handoff.

Ampliar imagen

Las ocho páginas del modelo. Las notas educativas comentan las cláusulas, y la última página incluye la lista de adaptación y los riesgos que el modelo busca evitar.

• Abrir el modelo en PDF (8 páginas)
• Descargar la versión editable (DOCX)

Usa el modelo como punto de partida para armar tu propuesta, no como un contrato listo. Cada proyecto tiene sus particularidades y puede requerir acuerdos técnicos, comerciales y jurídicos diferentes, y el propio documento recomienda una revisión jurídica cuando haya compromisos relevantes o datos sensibles.

El primer freelance exige concesiones, pero deben tener límites

Si estás pensando en aceptar tu primer freelance, quizá tengas que hacer concesiones, como ofrecer un precio más competitivo, elegir un proyecto más pequeño o dedicar más tiempo al descubrimiento de requisitos. Esas decisiones pueden tener sentido cuando forman parte de una estrategia consciente de aprendizaje y de posicionamiento profesional. Pero hacer concesiones no significa aceptar responsabilidades ilimitadas.

Un precio menor no exige un alcance indefinido, y las ganas de ganar experiencia no te eximen de negociar condiciones justas.

Proteger tus intereses tampoco es actuar en contra del cliente. Una negociación bien estructurada beneficia a quien contrata, porque reduce ambigüedades y facilita el seguimiento del proyecto.

Consideraciones finales

Mi primer freelance no fue una experiencia comercial especialmente exitosa. El retorno económico fue modesto para el esfuerzo y la responsabilidad que asumí, el proyecto se extendió mucho más de lo previsto y cometí errores que hoy puedo ver con más claridad. Aun así, me enfrenté a problemas que van más allá de implementar funcionalidades, como la negociación, la planificación, la comunicación, los cambios de requisitos, las decisiones de arquitectura y la transferencia de responsabilidades. Y aprendí que dominar una tecnología no significa estar preparado para conducir un proyecto de software.

Si pudiera dejar una recomendación a quien está empezando, sería esta:

No tengas miedo de hacer concesiones para ganar experiencia. Pero intenta entender exactamente qué estás concediendo, qué riesgos estás asumiendo y dónde están tus límites.

Aprender a negociar también forma parte de convertirse en un ingeniero de software más completo.