Llevo semanas dándole vueltas a esto y no tengo una respuesta clara. Lo pongo por escrito a ver si ordenando las ideas encuentro algo, o al menos a ver si alguien que esté en la misma situación me dice cómo lo está resolviendo.
Soy freelance, llevo ya unos cuantos años vendiendo bolsas de horas a clientes y agencias, y el modelo se está rompiendo. No de golpe, sino poco a poco. Y tiene que ver con cómo la IA está cambiando la velocidad a la que trabajo.
Cómo funciono
Mi modelo es simple. El cliente necesita una funcionalidad, hago una estimación aproximada de las horas que puede llevar, y se van contratando en packs de X horas. Cuando se termina una bolsa, se renueva otra. Así hasta que la tarea está terminada.
La estimación es aproximada a propósito. Es muy difícil estimar con precisión un desarrollo: si pongo un precio alto para cubrirme, el cliente paga de más; si pongo uno bajo, me pillo los dedos yo. Con este sistema se va viendo a medida que se gastan las horas si estamos llegando a la estimación real o nos pasamos. También porque el cliente va pidiendo cambios sobre los requisitos iniciales, con lo cual la estimación se mueve.
Me gusta ser transparente. Si una tarea se ha hecho rápido, se le cobran pocas horas. Si se lía y la estimación no se ha cumplido, se lo comunico con los motivos, y a partir de ahí se negocia: se amplía la bolsa, se cierra la funcionalidad con solo una parte de los requisitos resueltos, o se busca otra solución.
Este modelo me ha funcionado bien durante años. El cliente comparaba con otros proveedores, miraba precio hora, miraba experiencia, y decidía.
Qué se ha roto
Con la configuración de agentes y herramientas de IA que tengo montada (lo expliqué en detalle en el artículo anterior sobre OpenCode y DDEV), hay tareas que resuelvo en una fracción del tiempo que me llevaban antes. Una tarea que antes eran 40 horas de bolsa, ahora pueden ser menos de 10. Y yo facturo las horas reales que he dedicado, no las que hubiera tardado antes.
El cliente está encantado porque le sale más barato. Pero yo estoy cobrando menos por el mismo resultado. Y encima ahora tengo gastos que antes no tenía: entre €200 y €300 al mes en suscripciones y APIs de inteligencia artificial, más el tiempo que dedico a formarme, a mantenerme actualizado con los modelos que salen cada pocas semanas, y a optimizar mis procesos y herramientas. Ese tiempo no se lo cobro a ningún cliente.
He subido un poco las tarifas, pero esa subida apenas compensa los costes nuevos. Al final facturo un poco más que antes, pero sinceramente no sé hasta qué punto me compensa el esfuerzo.
Tres alternativas, ninguna me convence
Le he dado vueltas y veo tres caminos para compensar que ahora tardo menos en hacer el mismo trabajo.
Subir mucho la tarifa hora. La más directa. Si antes tardaba 40 horas y ahora tardo 10, cobro más por cada hora. Tiene lógica: estoy entregando más valor en menos tiempo. El problema es que en el mercado en el que me muevo hay un techo. Ya me ha costado subirle las tarifas a algún cliente que las tenía congeladas desde hacía más de un año. Si subo mucho más, directamente dejan de contratarme.
Hinchar las horas. Es lo que sé que hacen muchas agencias: no decirle al cliente que tardo tan pocas horas, bajar un poco la tarifa para que parezca más competitiva, pero facturar muchas más horas de las que realmente dedico. No me gusta. No es mi estilo y no es cómo quiero trabajar. La transparencia con mis clientes es la base de cómo funciono. Mentir en las horas para cuadrar cuentas no es una opción para mí.
Presupuestos cerrados. Dejar de vender horas y dar un precio fijo por funcionalidad. Si lo hago en menos tiempo, me quedo con el margen. El problema es que estimar un desarrollo con precisión ya era complejo antes de la IA. Ahora lo sigue siendo, pero por motivos diferentes: hay tareas donde los agentes me resuelven el 80% del trabajo en un rato, y otras donde la IA se atasca y acabo tardando lo mismo que antes. Esa variabilidad hace que un precio cerrado sea arriesgado.
El problema de fondo: la percepción
Si fuera solo un problema de números, quizás tendría solución fácil. Pero hay algo más profundo que lo complica: cómo perciben los clientes el valor de lo que hago en un mundo donde "la IA ya programa".
He recibido correos de clientes (que no son programadores) con fragmentos de código generados por ChatGPT, diciendo cosas como "mira, aquí tienes una posible solución". Y yo tengo que dedicar tiempo a revisar ese código y responderles explicando que sí, que la IA ha identificado más o menos bien el problema, pero que la solución que propone no es correcta por este, este y este otro motivo. Un caso claro: código que no tenía en cuenta las zonas horarias ni las funciones de tiempo de Drupal, con lo cual los cálculos de fechas no funcionaban bien. ¿Funciona? Sí, parece que funciona. ¿Funciona bien? No tanto. Son funciones que la IA se inventa o implementa con malas prácticas que por motivos técnicos no deberían usarse.
Esas conversaciones, por un lado, ayudan a que el cliente entienda que no te puedes fiar ciegamente de lo que dice la IA. Pero por otro lado refuerzan esa sensación de "si ChatGPT ya lo hace, ¿por qué te pago a ti?".
Y no es solo con clientes directos. También con la competencia. Un caso que me encontré: una agencia que estaba usando ChatGPT y otras IAs en modo gratuito, iba cambiando de una a otra cuando se acababan los límites. Para una funcionalidad bastante concreta y simple, en vez de buscar un módulo contribuido que ya existía y hacía exactamente eso, dedicaron horas a crear un módulo custom con IA. El resultado fue un módulo mal planteado, que no seguía las buenas prácticas de Drupal, que no tenía funciones de traducción cuando la web era multidioma y los textos debían ser traducibles. Meses después, cuando la agencia ya no estaba, me tocó a mí lidiar con eso.
He heredado suficientes proyectos así para saber de lo que hablo. Código sin tests, sin análisis estático, sin revisiones de seguridad. Pero esto es muy difícil de explicarle a un cliente que no es técnico. Para él, la funcionalidad está hecha y punto.
Yo tengo 16 agentes especializados en Drupal, con gates de calidad automáticos, con tests, con análisis de seguridad. Y aun así hay cosas que los agentes se inventan, hay cosas que hacen mal, hay decisiones de arquitectura que no pueden tomar solos. Yo estoy encima de cada línea que se sube a producción porque tengo una responsabilidad con el cliente. Si algo falla, el que da la cara soy yo, no ChatGPT.
Pero hay clientes que no entienden esto. Que se piensan que la IA hace todo el trabajo y que yo me limito a copiar y pegar. Y después de más de una década trabajando con Drupal, invirtiendo meses en montar toda una infraestructura de agentes y herramientas, eso cuesta oírlo.
Dónde estoy ahora
Como ninguna alternativa me convence, sigo con lo que hacía: bolsas de horas, transparencia total, tarifas muy similares a las de antes. Trabajo no me falta. Estoy bastante desbordado y acabo llenando todas las horas disponibles del mes.
Pero escalar no es una opción. Ya estoy al máximo de horas. Puedo coger más proyectos, sí, porque lo que antes era un proyecto de 40 horas ahora es uno de 10. Pero mis ingresos no pueden ser mayores porque las horas disponibles son las que son. Facturo similar a antes, con más costes, y dedicando tiempo a formación y optimización que no le cobro a nadie.
Lo que me preocupa a futuro
Esto es lo que más me da que pensar. Si todos los desarrolladores estamos sacando más trabajo del que hacíamos antes porque con la IA podemos terminar proyectos más rápido, en principio es bueno. Pero el mercado de Drupal es el que es. Para bien o para mal está un poco estancado. Drupal es para webs complejas, no es un ecosistema masivo como WordPress donde hay millones de webs. En Drupal hay relativamente pocas, y el volumen de proyectos nuevos no crece al ritmo al que crece la productividad de los desarrolladores.
Si hay cada vez más gente capaz de sacar el mismo trabajo en menos tiempo, va a empezar a sobrar desarrolladores y a faltar webs que necesiten tantas horas de desarrollo. No sé si estoy siendo pesimista o realista, pero me da la sensación de que en un futuro no muy lejano va a faltar trabajo y a sobrar gente.
Una posible salida: dejar de vender horas
De momento hay algo que estoy probando. No sé si es la solución, pero es una vía que quiero explorar: dejar de vender mis horas y pasar a vender un producto. Estoy montando un SaaS dentro del nicho de webs Drupal, y espero tener noticias más pronto que tarde.
La idea es que un producto es escalable de una forma que las horas no lo son. Me cuesta más o menos lo mismo venderlo a diez personas que a mil. Los costes de infraestructura son los que son, pero no dependen de cuántas horas tenga yo disponibles al mes. Eso es justamente lo que me limita ahora con las bolsas de horas: ya estoy al máximo, no puedo escalar más.
No sé si es la solución definitiva. Es algo que quiero investigar, estoy a punto de publicar el servicio, y ya os iré contando cómo evoluciona. Pero por lo menos es un camino que no tiene el techo de las horas.
No voy a cerrar este artículo con una respuesta clara porque no la tengo. Lo que sí me niego a hacer es competir bajando precio. He invertido años especializándome en Drupal y meses montando un entorno de desarrollo con IA que funciona. La calidad de lo que entrego es la que es. Si un cliente quiere lo más barato, hay opciones. Pero lo más barato y lo más rentable no suelen ser lo mismo.
Si estás en una situación parecida, me encantaría saber cómo lo estás gestionando. Porque por ahora, estoy harto de dar vueltas al mismo problema sin encontrar una respuesta que me convenza.