No tengo 70 proyectos. Tengo 15, y a algunos no los pidió nadie

Casi todo el mundo te dice que un junior necesita muchos proyectos para que lo miren. Diez, veinte, cincuenta. Cuantos más, mejor.

Yo tengo quince. Y cuatro de esos son demos conceptuales de arquitectura, interiorismo y un café que nadie me pidió ni pagó. Hay otra que es una plataforma de reservas con pagos de verdad, roles, bases de datos y un sistema de concurrencia que quedó muy bien armado. Esa tampoco tiene un solo usuario, porque el cliente se bajó por presupuesto antes del lanzamiento.

Por un tiempo me obsesioné con eso. Sentía que quince no alcanzaba, que el número quedaba corto, que un recruiter iba a abrir la lista, ver demos lindas de arquitectura y preguntarse qué tenía que ver eso con la programación web.

Después entendí que el problema no era la cantidad. Era que yo no sabía bien para qué existía cada proyecto. Y cuando lo descubrí, todo lo que parecía un fracaso cambió de lado.

§El juego de contar proyectos

Cuando empecé a armar el portfolio hice el ejercicio que hace todo el mundo: contar. Sumar demos, sumar proyectos de la facultad, sumar lo que fuera para que el número subiera.

El número miente. Porque una demo, una herramienta y un producto para un cliente se cuentan igual, pero no pesan igual ni demuestran lo mismo. Una demo demuestra criterio. Una herramienta demuestra que la usás. Un producto demuestra que alguien confió, pagó y quedó conforme. Son tres cosas distintas que el conteo aplasta en una sola unidad.

Y lo peor: cuando contás solo para inflar el número, terminás publicando cosas que vos mismo no sabés por qué están ahí. Esas sí que son señal de humo.

§El día que entendí qué era "terminar"

En mi portfolio cada proyecto tiene una etiqueta: Demo Conceptual, Demo Funcional, Herramienta, Recurso Abierto, Sistema en Producción, Producción Real. Al principio la usé como clasificación técnica, para ordenar la página. Después me di cuenta de que era otra cosa: era mi definición de "terminado".

Porque terminar no es publicar. No es que el botón funcione ni que se vea lindo. Terminar es cumplir el objetivo para el que el proyecto existía. Y según cuál sea ese objetivo, "terminado" significa cosas muy distintas.

Una demo está terminada cuando transmite el criterio que querías transmitir, no cuando tiene usuarios. Una herramienta está terminada cuando la usás, aunque la use una sola persona. Un sistema está terminado cuando un cliente real lo usa todos los días para facturar, reservar o coordinar. La página de proyectos lo dice exactamente así.

§Los post-mortems cortos

Cuatro de mis proyectos son demos conceptuales: BRÜNN, un estudio de arquitectura; LÜMEN, uno de interiorismo; MAREA, un café, bar y cocina; y STRØ, arquitectura de autor. Nadie las pidió. Ninguna tiene usuarios reales ni métricas de uso. Si contás proyectos para impresionar, son lastre.

Pero no son lastre. Son demos. Su objetivo era investigar un rubro, entender cómo piensa un estudio, aprender a transmitir criterio. Y ese objetivo lo cumplieron. MAREA incluso dejó a mitad de camino el concepto más fuerte que tenía, el del espacio que cambia según el horario. Lo dejé anotado en la ficha del proyecto, sin esconderlo. Eso es lo que hay que mirar de una demo: no la demo en sí, sino que yo sé exactamente hasta dónde llegué y por qué.

El caso que más me enseñó es el que no figura como demo. Zabira es una plataforma de reservas para un estudio de pilates: landing premium, dashboard con roles, reservas atómicas sobre una base de datos con concurrencia, membresías activadas por webhooks de Mercado Pago y autenticación con JWT. Es el sistema más completo que armé hasta acá.

No tiene un solo usuario. El cliente se bajó por presupuesto antes del lanzamiento.

Hubo un momento en que me pregunté si esa plataforma había sido una pérdida de tiempo. Después lo vi distinto: el objetivo nunca fue operarla con ese cliente; el objetivo fue demostrar que podíamos construir algo así, y quedó demostrado. Aprendí a pensar la reserva de un turno como un momento de ansiedad para el cliente, a separar una landing que vende de un dashboard que opera, y a trabajar con concurrencia real. Hoy puedo explicarlo. Lo publiqué como una demo completa y pulida, no como un fracaso.

DuckSale es otra cosa: una demo de e-commerce que armamos para que un cliente potencial recorriera su tienda como si ya existiera, con carrito, cupones, checkout y panel de administración. No es un producto, es un arma de venta. Y MyVisor es un lector de Markdown que uso para mis propios apuntes. Lo usa una persona: yo. Y está perfecto así.

Terminar no es publicar. Es saber para qué existía cada cosa.

§Lo que dejé de hacer

Lo que cambió mi forma de trabajar fue dejar de contar proyectos y empezar a decidir para qué existe cada uno antes de construirlo. Y cuando se termina, etiquetarlo con el criterio que corresponde. Si es una demo, que sea clara como demo. Si es una herramienta, que se note que la uso. Si es un sistema en producción, que tenga usuarios reales.

Esa categoría no está en la web para el recruiter. Está para mí. Es el mecanismo que me dice cuándo parar. Ningún proyecto se "termina de verdad": siempre hay algo que haría distinto hoy, y de hecho todas las fichas de la página lo dicen. Pero se terminan cuando cumplen lo suyo. El resto del tiempo estás puliendo y no te das cuenta de que ya estás apilando señal de humo.

§Cierre

Si estás armando tu portfolio, dejá de hacerte la pregunta equivocada. No preguntes "cuántos proyectos tengo". Preguntate para qué existe cada uno. El día que sepas para qué existe, vas a saber si está terminado.

Y si mirás mi lista y ves demos que nadie pidió y un sistema completo sin usuarios, ahora sabés leerla. No son fracasos. Son, cada uno, exactamente lo que tenían que ser. El único proyecto que no se termina nunca es este journal: hoy publico esto, y mañana seguramente lo complete.