Build in Public: Lessons From 170+ GitHub Repos

After 170+ public GitHub repositories, I've learned more from what went wrong than from what worked. Building in public is not a marketing strategy — it's a discipline. Here's what 170 repos taught me.

What "building in public" actually means

It doesn't mean tweeting about your metrics or posting revenue screenshots. It means your work is visible by default:

Code is public unless there's a specific reason not to
Architecture decisions happen in issues, not Slack DMs
Failures are documented, not hidden
Learning is shared as it happens, not polished afterward

Visibility creates accountability. When your code is public, you write it as if it'll be read — because it will be.

Lesson 1: Scope is everything

My first 50 repos: too small to be useful, too many to maintain. My last 50: fewer, larger, more deliberate.

The pattern that emerged:

Bad scope: "I want to learn WebSockets" → websocket-demo repo with 80 lines of code
Good scope: "I need real-time CRDT sync for LetX" → letx-collab repo that solves a specific, real problem

Projects with a specific user (even if that user is me) outlive projects made to "learn a technology." Technology is learned better by solving problems than by building demos.

Lesson 2: README is the product

A repo without a good README is a repo no one uses, including future-you. I've wasted hours re-understanding my own code because I didn't write down what it does, why I made certain choices, and how to run it.

README structure that works:

# Project Name

[One sentence: what it does and why it exists]

## Quick start
[Commands that work, tested before commit]

## How it works
[Architecture in < 200 words]

## Why [unusual choice]
[Explanation for non-obvious decisions]

That's it. No mission statements. No roadmaps. No "contributions welcome" boilerplate that you'll never follow through on.

Lesson 3: Reuse compounds

By repo 50, I had patterns I'd written 10 times: JWT middleware in Go, Terraform ECS service module, Next.js metadata template, GitHub Actions deploy workflow. By repo 100, those patterns were libraries.

The compound effect:

Repo 1–50: write everything from scratch
Repo 51–100: copy-paste from earlier repos
Repo 101–150: import from internal libraries
Repo 151+: scaffold entire projects from templates

Time-to-first-commit dropped from days to hours. Not because I got faster, but because I stopped solving solved problems.

Lesson 4: Public code forces quality

Private code has one reader: you. Public code has unlimited readers: future you, contributors, employers, users, critics. That audience changes how you write.

Specific behaviors that changed when code went public:

Error handling improved (you don't want public APIs that panic)
Variable names improved (one-letter variable names look amateurish publicly)
Tests appeared (embarrassing to have a public repo with 0 tests)
Documentation appeared (you stop taking "I'll remember this" as an answer)

Lesson 5: Momentum matters more than quality

The single biggest predictor of a repo's long-term value: did it get used in the first 30 days? Not by strangers — by me.

If I build something and don't use it immediately, I abandon it. Every time. The motivation that existed during building evaporates. The repo becomes dust.

Rule: build only what you need right now, for a real project. No speculative tooling.

Lesson 6: The right metric is impact, not stars

I've had repos with 200 stars that I abandoned after 3 months. I've had repos with 12 stars that I've maintained for 2 years because they're critical to my own products.

Stars are a vanity metric. The right metric: does this repo make something better?

My 10 most-used public repos

These aren't the most-starred. They're the ones I use daily:

hermes-agent-aws — always-on AI agent on AWS
common-knowledge — Git-backed agent memory
skill-builder — build agent skills from descriptions
go-chi-template — Go API scaffold (Chi + sqlc + pgx + JWT)
nextjs-seo-template — Next.js App Router + SEO-ready template
tf-ecs-service — Terraform ECS Fargate service module
bagh — Bengali programming language
letx — collaborative LaTeX editor (the product)
quantumsketch — STEM video generator (the product)
gh-actions-deploy — reusable GitHub Actions workflows

FAQ

What does "building in public" mean for software engineers? It means keeping your code public by default, documenting decisions in issues and READMEs, and sharing learnings as they happen — not just after success.

How many GitHub repositories is too many? There's no absolute limit, but quality over quantity matters. 20 well-maintained, genuinely useful repos are worth more than 200 abandoned experiments.

Does building in public help your career? Yes, significantly. A GitHub profile with real, working products is more credible than a resume. Recruiters, clients, and collaborators can see your code quality, consistency, and taste directly.

What should I build in public? Build things you actually need. Solve real problems for yourself first. A tool you use daily will be better maintained and more credible than something built to impress.

Written by Shihab Shahriar Antor — AI Engineer & Founder of Shahriar Labs. See also: My Engineering Principles · The Solo Founder Stack.