I don't have 70 projects. I have 15. Some of them nobody asked for

Everyone tells you a junior needs lots of projects to get noticed. Ten, twenty, fifty. The more the better.

I have fifteen. Four of them are conceptual demos of architecture, interior design and a café that nobody asked me for or paid for. Another one is a booking platform with real payments, roles, databases and a concurrency system that turned out really well built. That one doesn't have a single user either, because the client walked away over budget before launch.

For a while I was obsessed with that. I felt fifteen wasn't enough, that the number fell short, that a recruiter would open the list, see pretty architecture demos and wonder what that had to do with web development.

Then I understood the problem wasn't the quantity. It was that I didn't really know what each project existed for. And once I figured that out, everything that looked like a failure turned around.

§The project counting game

When I started building my portfolio I did the exercise everyone does: count. Add up demos, add up university assignments, add up anything to make the number go up.

The number lies. Because a demo, a tool and a client product all count the same, but they don't weigh the same and they don't prove the same thing. A demo proves judgment. A tool proves you use it. A product proves someone trusted you, paid you and was happy. Three different things flattened into a single unit by the count.

And the worst part: when you count just to inflate the number, you end up publishing things you don't even know why they're there. Those are actual smoke signals.

§The day I understood what "finishing" meant

In my portfolio every project has a label: Conceptual Demo, Functional Demo, Tool, Open Resource, System in Production, Real Production. At first I used it as a technical classification, to organize the page. Then I realized it was something else: it was my definition of "finished".

Because finishing isn't publishing. It's not that the button works or that it looks nice. Finishing is fulfilling the goal the project existed for. And depending on what that goal is, "finished" means very different things.

A demo is finished when it communicates the judgment you wanted to communicate, not when it has users. A tool is finished when you use it, even if a single person does. A system is finished when a real client uses it every day to invoice, book or coordinate. The projects page says exactly that.

§The short post-mortems

Four of my projects are conceptual demos: BRÜNN, an architecture studio; LÜMEN, an interior design one; MAREA, a café, bar and kitchen; and STRØ, author architecture. Nobody asked for them. None of them has real users or usage metrics. If you're counting projects to impress, they're dead weight.

But they're not dead weight. They're demos. Their goal was to research an industry, understand how a studio thinks, learn to communicate judgment. And they fulfilled that goal. MAREA even left halfway its strongest concept, the space that changes depending on the time of day. I wrote it down on the project's page, without hiding it. That's what you should look at in a demo: not the demo itself, but that I know exactly how far I got and why.

The case that taught me the most is the one that doesn't show up as a demo. Zabira is a booking platform for a pilates studio: premium landing, dashboard with roles, atomic bookings on a database with concurrency, memberships activated by Mercado Pago webhooks and JWT authentication. It's the most complete system I've built so far.

It has zero users. The client walked away over budget before launch.

There was a moment when I wondered if that platform had been a waste of time. Then I saw it differently: the goal was never to run it with that client; the goal was to prove we could build something like it, and it was proven. I learned to think of booking a class as a moment of anxiety for the client, to separate a landing that sells from a dashboard that operates, and to work with real concurrency. Today I can explain it. I published it as a complete, polished demo, not as a failure.

DuckSale is something else: an e-commerce demo we built so a potential client could walk through their store as if it already existed, with cart, coupons, checkout and an admin panel. It's not a product, it's a sales weapon. And MyVisor is a Markdown reader I use for my own notes. One person uses it: me. And it's perfect that way.

Finishing isn't publishing. It's knowing what each thing existed for.

§What I stopped doing

What changed how I work was stopping to count projects and starting to decide what each one exists for before building it. And when it's done, labeling it with the right criterion. If it's a demo, let it be clearly a demo. If it's a tool, let it show that I use it. If it's a system in production, let it have real users.

That label isn't on the website for the recruiter. It's for me. It's the mechanism that tells me when to stop. No project is ever "truly finished": there's always something I'd do differently today, and in fact every project page says so. But they're finished when they fulfill their purpose. The rest of the time you're polishing and you don't realize you're already stacking smoke signals.

§Closing

If you're building your portfolio, stop asking yourself the wrong question. Don't ask "how many projects do I have". Ask yourself what each one exists for. The day you know what it exists for, you'll know if it's finished.

And if you look at my list and see demos nobody asked for and a complete system with no users, now you know how to read it. They're not failures. They're, each one, exactly what they needed to be. The only project that never finishes is this journal: today I publish this, and tomorrow I'll probably complete it.