I build HairOver in public, mostly as a founder. Building in public has a side effect that matters for developers too: it puts your work in front of the people who hire. Building in public is one of the best job-search strategies for developers, if you do it with intent.
For the founder side, see How to Build in Public and Grow an Audience. This post is the career angle.
Why it works
Recruiters and hiring managers are trying to reduce risk. Public work answers their questions before the first call:
- Can you build? Shipped projects.
- Can you think? Write-ups with trade-offs.
- Can you communicate? Clear posts and READMEs.
- Do you finish things? Progress over months.
Choose projects that signal the job you want
| Target role | Project signal |
|---|---|
| Frontend / React | Polished UI, performance, accessibility |
| Full-stack | Auth, payments, data model, deployment |
| AI engineer | RAG, evals, cost control, real users |
| Climate tech | Geospatial data, dashboards, public datasets |
My own mix: HairOver (AI product), Vayu (IoT and climate), and writing on EUDR engineering.
What to share
- The problem and who has it
- Decisions and what you considered
- Results: real numbers only, small is fine
- Mistakes and what you changed (HairOver founder mistakes)
Where to share
- Your site: the permanent home (technical blogging)
- LinkedIn: where recruiters search (LinkedIn guide)
- GitHub: clean READMEs
- Communities: X, Reddit, Discords in your niche
Turn visibility into interviews
- Put a "currently open to" line on your site and profiles.
- Make it easy to contact you.
- When someone engages, reply and continue the conversation.
- Turn your best project into a case study (template).
Things to avoid
- Leaking employer information. Only share what's yours to share.
- Performing instead of building. Substance first.
- Inconsistency. Monthly is fine. Disappearing for a year isn't.