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.
The market is genuinely hard
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.
What I did instead
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:
- Streaming UI — rendering LLM responses progressively via NDJSON, handling partial state, avoiding layout thrash
- LLM integration at scale — 13+ separate model calls, each with Zod validation, structured outputs, and proper error handling
- Hybrid scoring systems — combining deterministic algorithms on real App Store data with LLM narrative generation, so the model narrates instead of hallucinating metrics
- Auth, rate limiting, RLS — Supabase with Row Level Security, Upstash Redis for per-IP and per-user limits, guest flows that convert on sign-in
- Product thinking — onboarding flows, empty states, the difference between what users say they want and what they actually need None of that came from a tutorial. All of it came from hitting a wall and having to get through it.
The learning gap between a junior job and building something
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 loading 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.
But here's the part most people skip: document it
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.
What "document the journey" actually looks like
It doesn't have to be polished. It doesn't have to be long.
- A DEV.to post about a bug that took you three days to fix and what you learned
- A short LinkedIn update when you ship a new feature with a screenshot
- A tweet thread walking through an architecture decision
- A postmortem when something you built didn't work the way you expected The bar is: be specific and be honest. Generic posts ("I'm learning React!") disappear. Specific ones ("Here's why I replaced Redux with Zustand for conversation state in my AI app, and what broke when I did") get read, saved, and shared.
The realistic expectation
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.
Start smaller than you think you should
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.
Top comments (0)