Tres meses contra dos años y cinco programadores

Mi último producto propio me llevó tres meses con el foco puesto. Hace unos años, algo con esa profundidad habría necesitado cinco programadores durante dos años. La diferencia no es solo la IA. Es que un proyecto pequeño, llevado por alguien con experiencia y con un objetivo claro, ahora puede llegar donde antes solo llegaban los equipos grandes. Y para una pyme eso cambia qué merece la pena encargar.

Pero esa frase tiene letra pequeña, y es la parte importante.

¿De verdad se puede hacer en tres meses lo que antes llevaba dos años?

Sí, pero no lo puede hacer cualquiera. Esos tres meses se apoyan en más de ocho años programando, desde 2017, y más de cuatro trabajando con IA.

Me explico. Durante esos tres meses no hice otra cosa. Nada de otros proyectos en paralelo. Un solo producto, un solo objetivo, todos los días. Y detrás había años de haberme equivocado en cosas parecidas, de saber qué pantalla va a dar problemas antes de hacerla, de saber qué no construir.

Si alguien sin esa base intentara lo mismo, calculo que tardaría medio año o más. Y probablemente con menos profundidad.

La IA multiplica lo que ya sabes. Si sabes poco, multiplica poco. Eso es lo que no te cuentan los vídeos de "hice una app en un fin de semana".

¿Qué ha cambiado para que un equipo pequeño gane a uno grande?

Han cambiado tres cosas, y ninguna es magia.

	Antes	Ahora
Escribir el código	Lo más lento del proyecto	Lo más rápido
Lo que frena	Manos para programar	Decidir qué se construye
Tamaño del equipo	Cuantas más personas, más avance	Cuantas más personas, más reuniones
Dónde está el valor	En ejecutar	En entender el problema

Antes, programar era la parte cara. Necesitabas muchas manos porque cada pantalla, cada informe y cada conexión se escribía línea a línea. Un equipo de cinco avanzaba más que uno de uno, aunque se coordinara peor.

Ahora escribir el código es la parte rápida. Lo lento es saber qué hay que escribir. Y eso no se reparte bien entre cinco personas. Se decide mejor con una o dos que entienden el negocio y hablan directamente con quien lo usa.

Es contraintuitivo. Pero en un equipo grande, buena parte del tiempo se va en ponerse de acuerdo. En uno pequeño, ese tiempo se dedica a construir.

¿Qué significa esto para una pyme que quiere un programa?

Significa que ya no necesitas un proyecto enorme ni una consultora grande para tener una herramienta seria. Y que lo pequeño bien enfocado suele salir mejor que lo grande.

Veo dos formas de encargar software. La primera es la de siempre: se reúnen todos los departamentos, se hace una lista con todo lo que la empresa podría necesitar en cinco años, se pide un presupuesto para todo y se empieza. Dieciocho meses después, la mitad de la lista ha cambiado y la otra mitad no se usa.

La segunda es la que yo defiendo. Se coge el proceso que más duele. Se resuelve en unas semanas. Se usa. Y con lo aprendido se decide el siguiente.

En mis proyectos, lo normal es que la primera parte esté funcionando entre cuatro y diez semanas. No porque recorte calidad. Porque recorto lista. Cómo se decide qué entra lo cuento en qué pasa en la primera semana de un proyecto conmigo.

¿Por qué un proyecto grande suele salir peor?

Porque cuanto más largo es un proyecto, más tiempo pasa sin que nadie lo use. Y lo que no se usa no se corrige.

Piénsalo así. En un proyecto de dos años, la primera vez que tu equipo toca la aplicación puede ser a los doce meses. Todo lo que se construyó antes se hizo imaginando cómo iban a trabajar. Y la imaginación falla. Siempre.

En un proyecto de tres meses, tu equipo toca algo en la tercera semana. Dice "esto no, así no lo hacemos". Se corrige esa misma semana. El error cuesta dos días, no seis meses.

Además, en los proyectos largos pasan cosas. Cambia el responsable. Cambia la ley. Cambia el negocio. El proyecto que se pensó para una empresa acaba entregándose a otra distinta, aunque tenga el mismo nombre.

Hay otra trampa que conviene conocer. Cuando la IA permite producir tanto tan rápido, es fácil confundir volumen con avance. Mucho código, pocas cosas usables. Escribí sobre eso en generar código no es avanzar.

¿Cuándo sí hace falta un proyecto grande?

Cuando el problema es grande de verdad y no se puede partir. Pasa menos de lo que parece, pero pasa.

Estos son los casos en los que no te voy a decir que empieces pequeño:

• Empresas con muchos departamentos que dependen unos de otros en tiempo real.
• Sustituir de golpe un sistema antiguo que no se puede mantener ni un mes más.
• Normativas que obligan a tener todo el proceso completo desde el primer día.
• Volúmenes muy altos, con miles de usuarios a la vez desde el principio.

Si tu empresa tiene entre cinco y cincuenta personas, lo más probable es que no estés en ninguno. Y si lo estás, quizá lo tuyo sea un ERP y no un programa hecho a mano. Lo comparo en software a medida o ERP.

¿Cómo distingo a quien puede hacerlo en poco tiempo de quien lo promete?

Por lo que te pregunta antes de darte un plazo. El que entiende de verdad pregunta mucho y promete poco.

Desconfía de quien te da un plazo corto sin haber visto cómo trabajas. Desconfía también de quien te dice que con IA todo es rapidísimo, sin matices. La barrera de entrada para hacer una aplicación ahora es casi cero. Cualquiera con una suscripción de 20 € al mes puede hacer una. Pero hacerla bien, que aguante con datos reales y gente real, es otra historia.

Yo también podría escribir ahora mismo una tesis doctoral con IA. Y no estaría bien.

Pide ver proyectos terminados y en uso, no maquetas. Pregunta cuánto tiempo lleva cada uno funcionando. Y pregunta qué pasó la primera vez que algo falló. Ahí se ve la experiencia. Tienes algunos ejemplos de cómo trabajo en los casos por sector.

Lo que antes se medía en años ahora se mide en semanas, pero solo si alguien sabe qué dejar fuera. Si quieres ver qué dejaríamos fuera en tu caso, reserva una llamada de 30 minutos y lo hablamos con tus procesos encima de la mesa.