Lesson 7: Building in Public
most engineers try to separate "building things" from "marketing things." they code for 6 months, then spend 2 weeks trying to "promote" it and get frustrated when nobody cares. the audience wasn't there because the story wasn't being told while the thing was being built.
building in public fixes this. it collapses the gap between creating and distributing into zero. the same act — building something — becomes your marketing. no separate "content calendar." no "thought leadership" posts. just showing your work.
The reframe: every commit, design decision, bug fix, and learning moment is content. you're not "creating marketing content" on top of your work. you're narrating the work. the marketing is the exhaust of building, not a separate job.
What Building in Public Actually Means
it doesn't mean livestreaming your screen 8 hours a day. it doesn't mean posting your revenue numbers if that makes you uncomfortable. it doesn't mean being an "influencer."
it means making your process visible.
Building in public is a spectrum, not a binary. you don't have to share everything. you share the parts of your process that would be useful, interesting, or educational to someone 2 years behind you. the "public" is your audience of peers and learners — not the entire internet.
the spectrum of public building
| level | what you share | effort | example |
|---|---|---|---|
| 1: decision logs | why you made a technical choice | low | "chose sqlite over postgres for this project. here's the tradeoff analysis." |
| 2: progress updates | what you built this week, what's next | low-medium | "week 3 of building the api. rate limiting is done. auth is next." |
| 3: post-mortems | what broke, what you learned, how you fixed it | medium | "our database went down for 47 minutes. here's the root cause and what we changed." |
| 4: teach-as-you-learn | explain a concept you just understood | medium-high | "i finally understand bloom filters. here's the explanation i wish i had 2 days ago." |
| 5: open source / open process | your code, your roadmap, your metrics | high | "here's the repo. here's what we're building. here's how many users we have." |
Start at level 1. decision logs. one post about why you chose a tool, an architecture, or an approach. these are the easiest to write because you already did the thinking — you're just externalizing it. level 1 is the gateway to everything else.
The Formats: What Building in Public Posts Look Like
the decision log
"we chose [X] over [Y] for [project].
pros of X: [1, 2, 3]
cons of X: [1, 2]
why Y lost: [specific reason, not just 'X was better']
the constraint that made the difference: [the real insight]
curious what others would have done — [question]"
why it works: decision logs demonstrate judgment. anyone can list pros and cons. the value is in the constraint that tipped the scales — that's where your experience shows. and the question at the end invites other engineers to share their own tradeoffs, starting conversations with exactly the peers you want to connect with.
the progress update
"building [project] — week 4 update:
done:
- [accomplishment 1]
- [accomplishment 2]
stuck on:
- [problem]. tried [approach], didn't work because [reason].
thinking about trying [next approach].
next:
- [upcoming milestone]
what i learned this week: [1 insight, specific, not generic]"
why it works: progress updates build a narrative over time. someone who sees week 4 is curious about weeks 1-3. someone who sees week 8 has been following the journey. by the time you launch, you have an audience that's been invested in the outcome for months. the launch isn't a cold announcement — it's the season finale.
the post-mortem
"[system] went down for [duration] on [date].
what happened: [1-2 sentence summary]
root cause: [the actual bug or failure, specific]
why our safeguards didn't catch it: [the honest part — this is where credibility lives]
what we changed: [the concrete fix, not 'we'll be more careful']
if this happened to your team, what would you have done differently?"
why it works: post-mortems are vulnerability that reads as competence. admitting a mistake and explaining the fix signals that you understand your system deeply enough to break it and fix it. the most popular engineering blog posts of all time are overwhelmingly post-mortems. people don't share success stories — they share war stories.
the teach-as-you-learn
"i just spent [time] understanding [concept].
here's the explanation i wish i had:
[clear, simple explanation of the concept]
the part that confused me: [the specific thing you misunderstood]
the moment it clicked: [what made it make sense]
[diagram or code example]
if you're also learning this, here's what i'd tell myself 2 days ago: [1-2 sentences]"
why it works: this is the 2-year rule applied in real time. you just learned something. someone else is about to learn it. your confusion is still fresh, so your explanation addresses the exact sticking points a textbook would skip. you don't need to be an expert — the fact that you just figured it out is the advantage.
Case Study: How Pieter Levels Builds in Public
Pieter Levels (@levelsio) has built multiple successful products (Nomad List, Remote OK, Photo AI) while sharing nearly everything publicly. he didn't start with an audience — he built one by sharing his process.
what he does:
- tweets his revenue numbers monthly (controversial, but effective — transparency is his brand)
- shares his build process in real time ("just added this feature, here's the commit")
- posts his failures alongside his wins (a failed project, a bad month, a technical screw-up)
- replies to everyone (his reply game is relentless)
why it worked for him:
- transparency became his differentiator. in a world of polished startup marketing, raw honesty stood out.
- the audience felt invested in his journey. when he launched a new product, thousands of people were already rooting for it because they'd watched it get built.
- the content engine was self-sustaining. he didn't need "content ideas" because his actual work generated them automatically.
what to steal:
- you don't need to share revenue (most people shouldn't). steal the process transparency.
- reply to everyone who engages. especially early on. a reply takes 30 seconds and makes someone feel seen.
- share the boring parts. not every post needs to be profound. "shipped a bug fix, here's what it was" is enough.
Case Study: How Simon Willison Builds in Public
Simon Willison (@simonw) is the creator of Datasette and a prolific engineering blogger. his approach is more measured than Levels but equally effective.
what he does:
- writes detailed blog posts about technical decisions ("why i built this," "how i solved this problem")
- maintains a public "today i learned" (TIL) repository where he documents small discoveries
- uses his blog as both documentation and marketing — every post is useful to someone, and collectively they demonstrate deep expertise
- engages thoughtfully in technical discussions on twitter, always adding value
why it worked for him:
- his TILs compound into a searchable body of knowledge that attracts organic traffic for years
- his blog posts are reference-quality — people bookmark them, cite them, and return to them
- he built credibility one post at a time over years, not through a single viral moment
- the TIL format is low-effort and high-signal — a discovery takes 15 minutes to document and can attract traffic for a decade
what to steal:
- start a TIL (public or private first, then public). small discoveries are easier to share than big ideas.
- write posts that answer specific questions. "how to do X with Y tool" gets searched for years.
- consistency over intensity. simon has been doing this for over a decade. the archive is the moat.
Case Study: How Cassidy Williams Builds in Public
Cassidy Williams (@cassidoo) is a developer who built a large following by being relentlessly helpful and consistently herself.
what she does:
- shares her learning process openly ("i'm learning rust, here's what i built today")
- creates and shares resources (her weekly newsletter, coding challenges, cheatsheets)
- mixes technical content with personality (memes, hot takes, daily life as a dev)
- engages actively with her community — her replies feel like talking to a friend
why it worked for her:
- her content is useful first, personal second. people come for the resources and stay for the person.
- she's consistent across platforms — same voice on twitter, same voice in her newsletter, same voice in talks
- she built multiple owned channels (newsletter, blog, github) so she's not dependent on any one platform
- her "cosigned" newsletter curates links with commentary — curation plus personality is a content engine that never runs dry
what to steal:
- curation is a valid content strategy. you don't need original ideas every time. "here's what i read this week and what i thought about it" is valuable.
- voice matters more than polish. cassidy's content feels like a person, not a brand.
- build resources. a single well-made cheatsheet or guide can outlast 100 tweets.
How to Start Building in Public (Without Feeling Like a Tool)
the biggest objection: "it feels self-promotional." "nobody cares what i'm working on." "what if i look stupid?"
the self-promotion problem
building in public feels like self-promotion when you're sharing achievements without process.
# cringe (self-promotional):
"so proud to announce i just hit 10k users!!! 🚀🚀🚀"
# not cringe (process):
"10k people are now using this thing i built. here's the 3 things
that broke at 1k users that i wish i'd known about at launch."
The rule: share process, not achievements. share the bug you fixed, not the user count. share the decision you're struggling with, not the decision you already made and are proud of. process invites conversation. achievements invite congratulations. conversations build relationships. congratulations do nothing.
the "nobody cares" problem
true — nobody cares about your project. yet. they'll care when it's relevant to them. your job is to make the connection.
don't post: "i'm building a CLI tool for managing docker containers." post: "i got tired of typing the same 3 docker commands 40 times a day so i automated it. here's the script — takes 2 minutes to set up."
the first post is about your project. the second post is about a problem your audience might also have. always frame from the problem, not the project.
the "what if i look stupid" problem
you will look stupid. that's part of it. the alternative is looking like you never try anything, which is worse.
The expertise paradox: the more you learn, the more you realize how much you don't know. this makes you reluctant to share because you feel unqualified. but the people reading you know less than you do about your specific thing. your "obvious" is someone else's revelation. share before you feel ready — because you'll never feel ready.
The Flywheel
here's why building in public compounds faster than any other distribution strategy:
build something
→ share the process (decision, progress, setback, learning)
→ someone relates, replies, or shares
→ conversation builds trust with that person and everyone watching
→ they follow you, join your list, or tell someone about you
→ their engagement signals the algorithm to show your content to similar people
→ new audience sees your body of work (the archive of everything you've shared)
→ some of them reach out with opportunities, collaborations, or questions
→ those interactions become more content
→ repeat
the flywheel spins because the input (building things) and the output (sharing the process) are the same activity viewed from different angles. you're not adding marketing on top of your work. the work IS the marketing.
The archive effect: after 6 months of building in public, you have an archive of 100+ posts, decision logs, and progress updates. when someone discovers you, they don't see one post — they see a person who's been consistently doing interesting work and sharing it. the archive is your credibility. a single post is an impression. an archive is a reputation.
Check Your Understanding
Practice: Your First Decision Log
Think about the last meaningful technical decision you made. It could be anything — a library choice, an architecture decision, a tool selection, a process change.
Write a post using the decision log format:
- What you chose and what you rejected
- The pros and cons (be honest — no tool is perfect)
- The constraint that made the difference (the real insight)
- A question for your audience
Publish it. Tag it or post it wherever your audience is.
This one post is your entry into building in public. It took 15 minutes and used information you already had in your head. That's the entire strategy — externalizing decisions you've already made.
Create a document, repo, or notes page called "things i learned this week." Every friday, write down one thing you learned — technical or otherwise. At the end of the month, pick the best one and turn it into a teach-as-you-learn post.
This habit generates 12 high-quality posts per year with zero creative effort — they're things you were going to learn anyway.
This is the meta-lesson of the entire course: your best content is your actual work, narrated. not manufactured. not researched. just documented. the people who succeed at organic distribution aren't the best writers or the smartest people. they're the ones who simply decided to let people watch them work.
1. 1. Building in public means:
2. 2. What's the difference between a self-promotional post and a build-in-public post?
3. 3. Why do decision logs work as content?
4. 4. What's the best starting point for building in public?
5. 5. Why does building in public compound faster than traditional content marketing?