There's a piece of advice that gets repeated constantly to people trying to break into tech: build more projects. Make your portfolio bigger. Add another framework, another API, another polished README with a Vercel deploy link.
I think that advice is mostly wrong, or at least wrong about what it optimizes for.
Portfolio projects optimize for looking impressive. Real projects optimize for being useful.
In my eyes, those are not the same skill, and chasing the first one quietly starves the second.
The tell
You can usually spot a portfolio project by what it doesn't have: users. That's not because it's early, and it's not a mark against the project's quality or usefulness — it's structural. The project exists to demonstrate that you could build something, not because anyone, including you, actually needed it. So it never gets used, which means it never breaks in a real way, which means you never have to debug it under real conditions, which means you never learn the thing debugging actually teaches you.
Now compare that to building something for an annoyance you personally have.
Maybe a script that fixes a workflow problem. Or a utility that does one small thing correctly. The moment it has even one real user — even if that user is just you — the project starts talking back. It tells you where your assumptions were wrong. That feedback loop is the entire point, and portfolio-shaped projects are specifically designed to avoid it. What worked, what didn't, where the design held up and where it didn't — that's what creates a healthy, continuous feedback loop, and it's what makes a software engineer better over time.
Ship before you deepen
What do I mean by this? Here's the principle I try to build by:
Ship the small, useful version first, and let advanced architecture be earned by a real need — not anticipated in advance.
This runs against a lot of instinct, especially early-career instinct. It feels responsible to plan the "proper" architecture up front. It feels premature to ship something that's clearly not done. But in practice, undeployed architecture is just guessing, and guessing about a system's future needs before it has any users is almost always wrong in some direction you couldn't have predicted.
Shipping something small and real first means:
- Your first version tells you what actually needs to be robust, instead of you guessing
- Bugs show up in a context you can actually reason about, instead of in a vacuum
- You build professional habits by necessity — small targeted changes, understanding root causes, reproducible debugging — instead of by discipline you have to manufacture
- You get something done, which is its own skill, separate from getting something impressive
None of this means don't plan. It means resist the urge to build the general-purpose, endlessly extensible version of something before you've built the boring, specific version that actually works.
What this looks like in practice
The habits that fall out of "ship before you deepen" aren't glamorous:
- Small, focused changes instead of sprawling rewrites
- Understanding why something broke before changing code to fix it
- Reproducible debugging instead of poking at symptoms
- Clear commit history and controlled scope, instead of a branch that tries to do six things
- Shipping the useful version instead of endlessly redesigning toward some imagined final form
These aren't advanced-engineer habits you earn after ten years. They're available immediately, on a small project, the moment you decide the goal is useful instead of impressive.
The uncomfortable part
The honest reason portfolio projects proliferate is that they're safer. A project no one uses can't fail publicly. It can just sit there, unfinished-but-technically-not-wrong, forever.
A project built to solve a real problem has to actually work. That's scarier, and it's also the entire reason it teaches you something a portfolio piece can't.
If you're trying to break into tech — or just trying to become a better engineer — I'd rather see one small thing that actually works and that you can explain the tradeoffs of, than five ambitious things that never got past "looks good in a screenshot."
Ship it small. Let it be used. Let the real need tell you when it's time to go deeper.
Top comments (0)