Let me be upfront about something. When I say "build a startup," I don't mean raise a seed round, quit your job, and move to San Francisco. I mean something much simpler and much more achievable: build something real, put it online, and tell people what you're learning along the way.
That's it. That's the whole idea.
I know how that sounds. But hear me out — because the market for junior and graduate developers right now makes this less of an ambitious bet and more of a practical one.
If you're a recent graduate or someone switching into tech, you already know this. The entry-level tier has compressed significantly. Companies that used to hire juniors are now posting "junior" roles that expect two years of experience. The interview process has gotten longer and more exhausting. Ghosting after five rounds is normal. And AI tools have raised the baseline for what "basic" looks like, which makes it harder to stand out with a portfolio of tutorial projects. Waiting it out — sending 50 applications a month and hoping — is a strategy. But it's a passive one. And it hands all the control to a market that isn't currently working in your favor.
I built IdeaPick — an AI-powered product idea generation and validation platform for indie hackers, solo developers, and early-stage founders.
The core loop: you describe your skills and interests, the app searches real competitor data, and generates grounded product ideas with validation scores, roadmaps, and a workspace to execute from.
Was it a moonshot startup idea? No. Was it a project that pushed me well beyond anything a junior job would have asked me to do? Absolutely.
Here's a partial list of what building IdeaPick actually forced me to learn:
A junior job teaches you how to work inside someone else's system. You pick up their conventions, their codebase, their deployment pipeline. That's valuable — genuinely. Working on a real team with real engineers is something building alone can't fully replace.
But here's what a junior job often doesn't give you: the full picture.
When you're a junior, tickets arrive scoped. Designs are handed to you. The architecture is already decided. You implement. You learn the layer you're touching and not much else.
When you build your own thing, there are no tickets. You make every decision — from database schema to color palette to whether the state should be a spinner or a skeleton. You face the consequences of every decision, which means you actually understand why certain decisions matter.
The learning is less comfortable. It's also deeper.
Building alone is good. Building and documenting publicly is a different thing entirely.
Write about what you're building. Post updates when something works. Post updates when something breaks — especially when something breaks. Explain the decision you made and why. Share the architecture diagram. Talk about the library you tried and abandoned.
This does a few things that quietly matter:
It proves you can think, not just copy. Anyone can follow a tutorial. Explaining a real tradeoff you navigated in production shows a different level of understanding. Hiring managers and engineers who see that know the difference immediately.
It builds an audience that compounds. Each post is a small signal. Over months, those signals accumulate into a body of work that represents you more accurately than any CV. People start to recognize your name before you've applied anywhere.
It attracts people you want to work with. The engineers, founders, and companies who respond to someone building and writing in public are usually the ones worth working for. The ones who don't notice aren't the ones you want.
It keeps you accountable. Saying publicly "I'm building X" creates just enough pressure to actually finish it. More projects die from abandonment than from bad ideas.
It doesn't have to be polished. It doesn't have to be long.
Building something won't guarantee you a job. Documenting it won't go viral overnight. This isn't a shortcut — it's a different kind of work, with a different kind of return.
What it does is give you something real to point to. When the market opens back up — and it will — you won't be walking into interviews with a portfolio of todo apps and a blank answer when they ask what you've shipped. You'll have a product, an architecture you can explain, decisions you can defend, and a trail of writing that shows how you think.
That's a different conversation entirely.
The biggest mistake is waiting for the right idea. The right idea doesn't exist before you start building. It emerges from building.
Pick a problem you've personally run into. Build the simplest version that solves it. Ship it, even if it's rough. Write one post about what you built and why.
That's week one. Everything else follows from there.
The market might not be hiring right now. But it's still watching.
Are you building something on the side while job hunting? What's been the hardest part — the building or the consistency of documenting it? Drop it in the comments.