Tabla de contenidos
- Introducción
- El problema que nadie dice en voz alta
- Lo que cambia cuando el desarrollador entra antes del diseño
- Conocer a los clientes de la agencia tiene un valor que no se puede comprar
- La válvula de escape cuando el equipo no da abasto
- Estar en producción es estar en el negocio del cliente
- Lo que hace que este modelo funcione, y lo que lo rompe
- Conclusión
Introducción
Llevo más de ocho años trabajando como partner técnico de una agencia de diseño boutique. No como proveedor externo al que se llama cuando hay un proyecto. Como parte del equipo, en las reuniones con clientes, en las decisiones técnicas previas al diseño, en los despliegues de producción a las once de la noche cuando hay que entregar al día siguiente.
Ese tiempo me ha enseñado algo que no habría aprendido trabajando solo para clientes directos: que la relación entre diseño y desarrollo, cuando funciona bien, produce resultados que ninguna de las dos partes podría conseguir por separado.
No es una cuestión de talento individual. Es una cuestión de contexto compartido, de confianza construida con el tiempo y de un modelo de trabajo que elimina la mayoría de las fricciones que normalmente aparecen cuando diseño y desarrollo operan por separado.
En este artículo quiero contar cómo es ese modelo desde dentro, qué lo hace diferente y por qué creo que es la forma más honesta y eficiente de colaborar entre una agencia de diseño y un desarrollador técnico.
El problema que nadie dice en voz alta
Las agencias de diseño tienen un problema que casi todas conocen pero pocas resuelven bien: necesitan desarrollo técnico de calidad, pero no siempre tienen capacidad ni justificación económica para tenerlo dentro a jornada completa.
Contratar un desarrollador senior en plantilla no siempre tiene sentido. El volumen de proyectos fluctúa, hay semanas de mucha carga y semanas de poca, y mantener un perfil técnico caro en nómina cuando no hay suficiente trabajo para él es una decisión difícil de justificar.
La alternativa más habitual es subcontratar a un proveedor externo en cada proyecto. Y funciona, hasta cierto punto. El problema es que genera una fricción constante que se acaba notando: hay que explicar el contexto desde cero cada vez, el nivel de calidad varía de un proyecto a otro, los plazos son impredecibles y la comunicación con el cliente pasa por demasiados filtros.
Lo que muchas agencias necesitan en realidad no es ni una cosa ni la otra. Es algo intermedio: alguien que entienda su forma de trabajar, que conozca a sus clientes, que pueda estar en la reunión técnica antes de que empiece el diseño y que sea capaz de convertir un Figma en producción sin que haya que supervisar cada paso.
Eso es lo que yo llamo un partner técnico. Y es algo muy distinto a ser un freelance de turno al que se llama cuando hay trabajo.
Lo que cambia cuando el desarrollador entra antes del diseño
Una de las cosas que más me ha sorprendido de este modelo es el impacto que tiene participar en las fases tempranas del proyecto, antes de que exista una sola pantalla diseñada.
Cuando un desarrollador entra en escena solo para ejecutar lo que ya está diseñado, su margen de maniobra es muy limitado. Si hay algo técnicamente inviable, si una funcionalidad va a disparar el presupuesto o si hay una decisión de arquitectura que va a condicionar el proyecto durante años, ya es tarde para cambiarlo sin generar tensión con el cliente.
Cuando el desarrollador está en la reunión técnica previa, las cosas funcionan de otra manera. Se pueden identificar los condicionantes técnicos antes de que existan compromisos difíciles de revertir. Se pueden proponer soluciones alternativas que el diseñador no habría considerado porque no es su especialidad. Se pueden alinear las expectativas del cliente con la realidad del proyecto antes de que el presupuesto esté cerrado.
El resultado es un proceso más fluido, con menos sorpresas en la fase de desarrollo y un producto final más sólido. El cliente lo nota aunque no sepa exactamente por qué. Nota que el equipo tiene las cosas claras desde el principio, que los plazos se cumplen y que no hay revisiones de último momento que nadie esperaba.
Eso no ocurre por casualidad. Ocurre porque la parte técnica ha estado presente desde el inicio.
Conocer a los clientes de la agencia tiene un valor que no se puede comprar
Después de ocho años, conozco los proyectos, las preferencias y las particularidades técnicas de los clientes de la agencia con la que trabajo como si fueran clientes propios. Sé qué tipo de soluciones les gustan y cuáles generan fricción. Conozco las decisiones técnicas que se tomaron en proyectos anteriores y el razonamiento detrás de ellas. Sé cómo piensan cuando tienen que elegir entre dos opciones y qué argumentos les convencen.
Ese conocimiento acumulado tiene un valor que no se puede transferir fácilmente ni comprar con dinero. No existe un documento de onboarding que lo cubra. Se construye con el tiempo, proyecto a proyecto, conversación a conversación.
Cuando llega un proyecto nuevo de un cliente con el que ya hemos trabajado, no hay que empezar de cero. Se puede arrancar más rápido, tomar mejores decisiones desde el principio y anticiparse a problemas que de otra forma aparecerían en las fases finales del proyecto, cuando son más caros de resolver.
Para la agencia, esto se traduce en menos tiempo de coordinación, menos errores y una experiencia de cliente más consistente. Para el cliente, se traduce en la sensación, muchas veces difícil de articular, de que el equipo que le atiende realmente le conoce y trabaja pensando en su negocio, no solo en entregar un proyecto.
La válvula de escape cuando el equipo no da abasto
Uno de los roles más importantes que he desempeñado a lo largo de estos años no es el de desarrollador principal en los proyectos grandes. Es el de válvula de escape cuando el equipo interno no tiene capacidad para absorber todo lo que llega.
Las agencias tienen picos de trabajo. Hay periodos en que los proyectos se acumulan, los plazos coinciden y el equipo simplemente no llega a todo. En esos momentos, tener a alguien de confianza que puede incorporarse sin fricción, que no necesita que le expliquen el contexto desde cero y que puede asumir carga de trabajo real con garantías de calidad es algo que tiene un valor enorme, aunque sea difícil de cuantificar en una hoja de Excel.
No se trata de subcontratación masiva ni de meter a alguien externo que genere más trabajo de coordinación del que resuelve. Se trata de tener disponibilidad real cuando hace falta, con alguien que ya conoce el entorno, que comparte los estándares de calidad de la agencia y que puede rendir desde el primer día sin necesitar supervisión constante.
Con el tiempo, ese rol de válvula de escape se ha convertido en uno de los aspectos más valorados de la relación. No porque ocurra constantemente, sino precisamente porque cuando hace falta, está ahí.
Estar en producción es estar en el negocio del cliente
Hay una parte del trabajo que muchos desarrolladores evitan o minimizan: el despliegue en producción y el soporte posterior.
Entregar el código es fácil. Lo difícil es hacerse responsable de lo que pasa después. De que el servidor esté bien configurado, de que el certificado SSL no caduque sin avisar, de que la base de datos esté correctamente respaldada, de que cuando algo falla a las diez de la noche haya alguien que lo resuelva antes de que el cliente se dé cuenta.
En un modelo de partner técnico, esa responsabilidad es parte del trato. No hay un handover al cliente con una documentación y suerte. Hay una relación continua en la que el desarrollador conoce la infraestructura porque la ha construido, sabe dónde pueden aparecer los problemas y tiene criterio para resolverlos cuando ocurren.
Para la agencia, esto significa poder ofrecer a sus clientes un nivel de servicio post-entrega que sería imposible sin ese soporte técnico continuado. Y para el cliente, significa tener la tranquilidad de que su negocio digital está en manos de alguien que realmente conoce su sistema.
Lo que hace que este modelo funcione, y lo que lo rompe
He visto colaboraciones entre agencias y desarrolladores que no funcionan. Y normalmente el problema no es técnico. Es de encaje, de expectativas mal gestionadas y de una relación que nunca llegó a construirse de verdad.
Para que un modelo de partner técnico funcione bien, hacen falta algunas cosas que no siempre son obvias. El desarrollador tiene que entender el negocio de la agencia, no solo ejecutar tareas. Tiene que ser capaz de comunicarse con clientes cuando la situación lo requiere, sin esconderse detrás de tickets o de intermediarios. Tiene que tener criterio técnico propio para tomar decisiones sin necesitar validación en cada paso. Y tiene que ser fiable en el sentido más simple y más difícil de la palabra: cuando dice que algo estará listo, está listo.
Por otro lado, la agencia tiene que estar dispuesta a tratar al partner técnico como parte del equipo, no como un proveedor al que se gestiona a distancia. Eso significa incluirle en las fases tempranas de los proyectos, compartir el contexto del cliente con la misma transparencia con la que se comparte internamente, y confiar en su criterio técnico sin necesidad de microgestión.
Cuando esas dos cosas ocurren al mismo tiempo, el resultado es una colaboración que beneficia a todo el mundo. A la agencia, que puede ofrecer un servicio técnico de calidad sin los costes fijos de tenerlo en plantilla. Al desarrollador, que trabaja en proyectos variados con un contexto rico y una relación de confianza real. Y especialmente al cliente, que recibe un producto mejor hecho y una experiencia más coherente a lo largo del tiempo.
Cuando alguna de las dos partes no cumple su parte del trato, la colaboración se deteriora rápidamente. Y en ese caso, lo mejor para todos es reconocerlo pronto y buscar otra solución.
Conclusión
Llevar ocho años en este modelo me ha convencido de que es la forma más eficiente y honesta de colaborar entre diseño y desarrollo. No es la más común, porque requiere un nivel de confianza y de compromiso mutuo que no se construye de un día para otro. Pero cuando funciona, funciona de verdad.
El cliente recibe un producto mejor. La agencia puede ofrecer un servicio técnico de calidad sin asumir los costes de tenerlo en plantilla. Y el desarrollador trabaja en un contexto rico, con proyectos variados y una relación que tiene valor más allá de cada proyecto individual.
Si tienes una agencia de diseño y te reconoces en alguno de los problemas que he descrito en este artículo, me encantaría explorar si tiene sentido colaborar. Puedes ver cómo trabajo y qué tipo de proyectos llevo aquí: Partner técnico para agencias de diseño