I had twenty project ideas. I shipped two. Here's why that's the actual point.

At one point I had a list of twenty project ideas sitting in a notes file — an incident dashboard, an API monitor, a resume analyzer, a collaborative whiteboard, a URL shortener, a log analyzer, an AI documentation generator, and a bunch of others, each one with a tidy little tech-stack summary next to it like a menu. It was a genuinely fun list to write. Coming up with plausible, portfolio-shaped project ideas is one of the more enjoyable kinds of procrastination available to a developer, because it feels like progress while asking almost nothing of you.

This portfolio ships two of those twenty. SignalHQ, the incident management platform, and an API monitoring service. That's it. Not because the other eighteen ideas were bad — several of them, I still think, would make genuinely interesting builds — but because somewhere in actually trying to finish things, I ran into a distinction I hadn't taken seriously enough while the list was still just a list: an idea and a finished thing are not the same unit of value, and they don't even scale the same way.

Why the list was so easy to write

Writing "a distributed URL shortener with caching, rate limiting, and QR codes" as a bullet point takes about fifteen seconds, and it sounds like a real, considered plan, complete with a plausible tech stack attached. That's exactly what makes idea-generation so seductive as a way to spend time — it produces the visible artifact of planning, a list, without requiring you to survive the part of a project where the interesting problems actually live: the part where the naive first version breaks in some way you didn't anticipate, and you have to sit with that and actually fix it.

I know this now because I did eventually write the boring first version of a URL shortener, as an exercise, and the entire interesting part of that project, the birthday-paradox collision math, the read-heavy caching strategy, the rate limiting to prevent abuse, lived entirely in the part that never makes it onto a bullet-point list. "Build a URL shortener" as a line item captures none of that. It's a label for a destination, not a description of the actual walk.

What SignalHQ cost that the other nineteen ideas never had to pay

SignalHQ is the project on this list that actually got finished end to end, and I think it's worth being honest about what "finished" cost, because it's a lot more than what any bullet point implies. It's not just "incident management platform, React, NestJS, Postgres." It's the week I spent specifically on the state machine governing incident status transitions, because a plain enum let you skip straight from open to resolved with no investigation step in between, and I had to sit with that being wrong before I could fix it. It's the layered authorization system, because "anyone with the right role" and "anyone who owns this specific incident" turned out to be two genuinely different kinds of permission check that don't collapse into one decorator. It's the full-text search tuning, the audit-log design that split operational history from security history, the actual deployment, the actual real GitHub repository sitting behind the link on this page right now, not a placeholder #.

None of that shows up in a bullet point that says "incident management platform." All of it is the actual difference between an idea and a shipped thing, and it's a difference that takes real, unglamorous time, precisely because it's not the part anyone puts on the list.

The moment I actually decided to cut eighteen ideas instead of attempting all twenty

The honest turning point wasn't some grand realization. It was just noticing that I had a portfolio with one deeply built, real project, and a nagging itch to go add seven more half-finished stubs to it so the page wouldn't look so sparse. And I made myself sit with a genuinely uncomfortable question before doing that: would a stranger looking at this portfolio, given ten seconds of attention, come away more impressed by twenty projects each described in three bullet points, or by two they could actually click into and read an honest build timeline for?

I don't think that question has one universally correct answer — for some kinds of roles, breadth genuinely is the more relevant signal, and a wide tour of many small, working things says something a deep dive into one system doesn't. But for the kind of engineering I actually want to be doing, backend systems, real architectural tradeoffs, the boring reliability work nobody puts on a highlight reel, I decided depth was the more honest signal to send, and sending an honest signal mattered to me more than the page looking fuller.

So the eighteen didn't get built as fake placeholder projects with # links pretending to be real. Some of them, the URL shortener, a small AST-parsing tool I wrote for SignalHQ's own architecture, turned into standalone practice exercises and posts instead, honestly labeled as exactly that: things I built to learn something specific, not things I'm claiming to have shipped as products. The rest are still just sitting in the notes file, and I think that's fine. A list of ideas is allowed to stay a list of ideas.

What I actually learned

I don't think the lesson is "never write down project ideas" — the list itself was useful, it's where SignalHQ and the API monitor both started, and I don't think either one would exist without that first fifteen-second bullet point giving the idea a name. The lesson is narrower: a list of ideas measures your imagination, and a portfolio measures your follow-through, and those are different enough skills that optimizing for one will quietly starve the other if you're not paying attention to which one you're actually spending your time on.

Twenty bullet points made me feel productive for an evening. Two finished systems are the only two things on this entire site I can talk about in real, load-bearing detail if someone actually asks — the failure modes I ran into, the tradeoffs I made on purpose and the ones I made by accident and had to notice later, the parts I'd do differently next time. That depth was never going to come from the list. It only ever came from the narrowing.