Day 36 (Bonus): What Building In Public With Claude Code Actually Looks Like

Hey, it's G.

Day 36 of the Claude Code series.

Phase 4 starts now.

Phases 1 through 3 were about learning Claude Code properly.

Phase 4 is about doing it in public.

That sounds simple — just post what you build.

But building in public with AI has a specific dynamic that's different from building in public the traditional way.

The work moves faster. The content writes itself. And the documentation is a byproduct of the build — not a separate chore.

Today I mapped out what this actually looks like as a daily practice.

The Problem (Building vs Posting Are Separate)

Here's what traditional build in public looks like:

Step 1: Build Something

You ship a feature.

Took you three hours.

Code works. Tests pass. Deployed.

Done.

Step 2: Sit Down Later to Write About It

Now you need to create content.

Open a blank document.

Try to remember what you built.

What was hard? What did you learn? What's the hook?

Step 3: Usually Don't

Because it's late.

You're tired.

The session was three hours ago and the details are fuzzy.

"I'll write about it tomorrow."

Tomorrow Never Comes

And the feature ships without a story.

No post. No documentation. No audience growth.

Just code in production that nobody knows exists.

The building and the sharing are disconnected.

Two separate activities. Two separate efforts.

One usually wins. The other usually loses.

The Concept (Content as a Byproduct of Building)

Build in public with Claude Code changes the dynamic.

The documentation, the content, and the sharing are all generated as part of the build session itself.

By the time a feature ships:

• The LinkedIn post is written
• The changelog entry is done
• The README is updated
• The YouTube script exists

The content is a byproduct of the work — not extra work on top of it.

Three Ways This Changes the Dynamic

1. Authenticity Is Automatic

When Claude Code reads your actual git history and generates content from it, the content reflects what really happened.

No inflating.

No summarizing from memory.

The story is in the code and the commits.

2. Consistency Becomes Possible

Posting daily about what you're building is hard when content creation is separate from building.

When it's part of the session?

It happens every time without friction.

3. The Audience Grows With the Product

Every feature ships with a story.

Every bug fix has a post.

Every refactor produces a lesson.

The product and the audience build in parallel — not sequentially.

The Build In Public Loop

Traditional loop:

Build → Document → Share → Repeat

Each phase feeds the next.

The build produces real work.

Documentation captures it accurately.

Sharing grows the audience that cares about the next build.

With Claude Code the loop looks like:

1. Read the GitHub issue — understand what you're building
2. Build the feature — full session workflow from Phase 2
3. Run pre-release checks — parallel subagents from Phase 3
4. Document what shipped — docs-writer skill
5. Generate content — content-repurpose skill
6. Close the loop — update GitHub, commit, ship

Steps 4, 5, and 6 used to happen separately — if at all.

Now they're the last 10 minutes of every build session.

The Mindset Shift (Builder to Builder-Narrator)

Old mindset:

Build → maybe post about it later → usually don't

New mindset:

Build → the post is already written by the time you ship

This isn't about performing work for an audience.

It's about capturing real work accurately and sharing it while it's fresh.

The audience gets the real story.

You get the content without extra effort.

The Full Build In Public Loop in Practice

cd ~/projects/my-app
claude

Step 1: Start With the Real Task

Read GitHub issue #61.
Summarize what we're building before we start.

Real issue. Real context. Real work ahead.

Step 2: Build It

/plan

Approve the plan.

Claude builds.

Step 3: Pre-Release Checks

Run security-reviewer and performance-reviewer 
on the new files simultaneously.

Findings under 100 words each.

Parallel subagents from Phase 3.

Quality check before shipping.

Step 4: Document While Context Is Fresh

Use the docs-writer skill to update the relevant 
docs for what we just built.

Read the new files before writing.
Show me the diff.

docs-writer skill reads actual code.

Generates accurate documentation.

Shows diff for approval.

Step 5: Generate Content

Use the content-repurpose skill to turn this 
feature into content.

Reference what the feature does, why it matters,
and what I learned building it.

Generate: LinkedIn post, X post, YouTube Community post.

content-repurpose skill applies your voice.

Platform-specific rules.

Ready-to-post content.

Step 6: Close the Loop

Update CHANGELOG.md with what shipped.
Close GitHub issue #61 with a comment.
/ship

GitHub updated via MCP.

Changelog current.

Shipped.

Feature built. Docs updated. Content generated. Issue closed.

All in one session.

What Makes Build In Public Content Good

The content that resonates isn't "I built X today."

It's the story behind X.

What was hard?

What surprised you?

What did you learn?

Claude Code gives you the raw material because it was there for the whole build.

After a Session, Ask for the Story

claude

What was the most interesting technical decision 
we made in this session?

What did we try that didn't work before we got it right?

What would have taken hours to figure out without 
Claude Code?

Use those answers to make the content-repurpose 
output more story-driven — not just a feature announcement.

That's the difference between:

"Added dark mode toggle today ✅"

And:

"Dark mode isn't a feature. It's a promise that you respect how people want to use your product. Here's what I learned shipping it in one session..."

Story-driven content gets engagement.

Feature announcements get ignored.

Your Daily Build In Public Rhythm

Morning

- Pick the issue to work on
- Check CLAUDE.md is current
- git commit baseline

During Build

- Full Phase 2 + 3 workflow

Build like you learned in Phases 1-3.

No changes to the work itself.

End of Session (10 Minutes)

- docs-writer skill → update docs
- content-repurpose skill → generate posts
- Update CHANGELOG
- Close GitHub issues
- /ship
- Post the LinkedIn and X content

Optional

- /standup → your end-of-day summary

10 minutes added to the end of every session.

That's the only difference.

The Build In Public Content Calendar (It Writes Itself)

Every feature shipped = 1 LinkedIn post + 1 X post
Every bug fixed = 1 lesson post
Every refactor = 1 "what I learned" post
Every phase wrap-up = 1 milestone post
Every 10 days = 1 "here's what I've built" recap

If you ship three features a week — you have three posts.

If you fix two bugs — two more.

The content is the work. The work is the content.

Complete Real Session Example

Real Build In Public session from start to finish.

The Issue

cd ~/projects/my-app
claude

Read GitHub issue #61 — "Add dark mode toggle"
What are we building?

Claude reads issue via GitHub MCP:

Dark mode toggle in navbar
Persists to localStorage
Respects system preference

Confirmed. Ready to build.

The Build

/plan

Plan approved.

Claude builds dark mode toggle.

Component created. State management. Persistence. System preference detection.

Done.

Pre-Release Check

Run security-reviewer on the new files.
Any issues?

Clean. No findings.

Documentation

Use the docs-writer skill to update README.md
with the dark mode feature.

One paragraph, user-facing language.

docs-writer skill updates README:

## Dark Mode

Toggle between light and dark themes from the navbar. 
Your preference is saved automatically and respected 
across sessions. The app also detects your system 
theme preference on first visit.

Accurate. User-friendly. Done.

Content Generation

Use the content-repurpose skill.

Feature: dark mode toggle — persists preference,
respects system setting, zero dependencies.

Make the LinkedIn post story-driven:
What problem does this solve for users?
What was the most interesting part of building it?
What did Claude Code handle that would have 
taken me an hour manually?

content-repurpose skill generates:

LinkedIn Post

Dark mode isn't a feature.

It's a promise that you respect how people want 
to use your product.

Shipped it today in one session.

The interesting part? Making it respect system 
preference while still letting users override.

Most apps pick one or the other.

We do both — if you've never set a preference, 
we match your system. Once you toggle, we remember.

Claude Code handled the localStorage sync, the 
system preference detection, and the state management 
across components.

What would have taken me an hour of debugging 
weird edge cases? Done in 20 minutes.

Zero dependencies. Just clean React state.

Feature shipped. Users happy. On to the next one.

Read how we're building: giangallegos.com

X Post

Dark mode shipped ✅

Not just a toggle — respects system preference 
AND remembers your choice.

Most apps pick one. We do both.

Claude Code handled the localStorage + system 
detection edge cases in 20 min.

Zero dependencies. Just clean state.

#BuildInPublic #ClaudeCode

Story-driven. Real details. Lesson embedded.

Ready to post.

Close the Loop

Update CHANGELOG.md — "Added dark mode toggle (#61)"
Close issue #61: "Shipped — dark mode live"
/ship

Changelog updated.

Issue closed via GitHub MCP.

Shipped.

Post the Content

Copy LinkedIn post. Paste. Post.

Copy X post. Paste. Post.

Done.

The Timeline

Total session: 45 minutes

• Build: 25 minutes
• Pre-release check: 5 minutes
• Documentation: 5 minutes
• Content generation: 5 minutes
• Close loop + ship: 5 minutes

Feature shipped. Docs updated. Content posted. Issue closed.

10 of those 45 minutes were documentation and content.

Without Claude Code? Those 10 minutes would be separate. Later. Probably never.

Why This Matters

Building in public is one of the highest-leverage things a solo developer or indie founder can do.

It builds an audience while you build the product.

The reason most developers don't do it consistently?

The friction of content creation on top of already demanding build work.

Claude Code removes that friction.

The content is generated from the real work.

In the real voice.

With the real story.

Automatically, at the end of every session.

That's the Build In Public unlock Phase 4 is about.

My Raw Notes (Unfiltered)

The shift that clicked for me: the content isn't separate from the work anymore.

By the time I close a GitHub issue the LinkedIn post is already written.

That's a fundamentally different relationship with building in public than trying to remember what I built and write about it later.

The story-driven content prompt is the one that makes the difference between posts that get engagement and posts that get ignored.

Asking Claude what was interesting or surprising about the session produces real content — not just feature announcements.

The daily rhythm feels sustainable in a way posting never did before because it adds 10 minutes to a session that was already happening.

Phase 4 Is Open

This is the new normal.

Every feature ships with a story.

Every build session ends with content.

The product and the audience grow together.

Following this live:

Every feature I ship from now on gets documented here.

Real builds. Real stories. Real lessons.

No highlight reel. Just the actual work.

What's Next

Day 37 preview:

Documenting Your Claude Code Workflow As You Ship — how to capture your process in real time so your content is always accurate and your audience always learns something real.

Following This Series

Core 30 Days: ✅ Complete

Bonus Days: In progress

Phase 1 (Days 1-7): Foundations ✅ Complete

Phase 2 (Days 8-21): Getting Productive ✅ Complete

Phase 3 (Days 22-35): Power User ✅ Complete

Phase 4 (Days 36+): Build In Public ⬅️ You are here

G

P.S. - The mindset shift: Build → the post is already written by the time you ship. That's different from Build → maybe post later → usually don't.

P.P.S. - What makes content good: ask Claude what was interesting or surprising about the session. Story-driven content gets engagement. Feature announcements get ignored.

P.P.P.S. - The daily rhythm: 10 minutes at the end of every session. docs-writer skill, content-repurpose skill, update CHANGELOG, close issues, /ship, post. Sustainable because it's part of the session, not separate work.