---
name: Build In Public
slug: build-in-public
category: Writing
description: Build In Public helps you write and time posts about what you shipped, learned, and changed. Use it when sharing engineering decisions, failures, and launch updates without exposing sensitive details.
github: "https://github.com/alinaqi/maggy/tree/main/skills/build-in-public"
language: Python
stars: 704
forks: 57
install: "npx degit https://github.com/alinaqi/maggy/tree/main/skills/build-in-public ~/.claude/skills/build-in-public"
installs_to: ~/.claude/skills/build-in-public
source_path: skills/build-in-public/SKILL.md
collection_size: 25
category_size: 1012
collection_url: "https://dirskills.com/collections/alinaqi/maggy"
added: 2026-08-23T05:20:37.690Z
last_synced: 2026-08-23T05:20:37.690Z
canonical_url: "https://dirskills.com/skills/build-in-public"
---

# Build In Public

Build In Public helps you write and time posts about what you shipped, learned, and changed. Use it when sharing engineering decisions, failures, and launch updates without exposing sensitive details.

**Install:**

```bash
npx degit https://github.com/alinaqi/maggy/tree/main/skills/build-in-public ~/.claude/skills/build-in-public
```

## README

# Build in Public — Best Practices

## Philosophy

Build in public isn't marketing. It's letting people watch you work. The best posts feel like you're narrating your thought process to a friend who's also a senior engineer. No hype sludge. No "I'm excited to announce." Just: here's what I built, here's why it matters, here's what I learned.

## What to Share (and What Not To)

**Share:**
- Technical decisions and the reasoning behind them ("Chose SQLite over Postgres because...")
- Architecture insights ("Here's how the 9-tier routing pipeline works")
- Failures and what you learned ("Spent 3 hours debugging a race condition. Root cause: ...")
- Before/after metrics ("Compaction death spirals: 26 → 0 after Mnemos")
- Open source releases with context, not just links
- Counter-intuitive findings that surprised you

**Never share:**
- Revenue numbers, user counts, valuation
- Customer names or identifiable client details
- Internal URLs, API keys, credentials
- Anything covered by NDA
- Roadmap promises you might not keep
- "We're hiring" disguised as content

## Channel-Specific Best Practices

### LinkedIn

**Audience:** Engineers, CTOs, founders who build. They scroll between meetings looking for something that makes them think.

**Format:**
- 1-3 paragraphs, 800-2000 characters sweet spot
- Lead with the insight, not the context
- Use line breaks generously — wall of text kills engagement
- One clear takeaway per post
- No external links in first paragraph (LinkedIn penalizes off-platform clicks)

**Tone:** Confident, teaches something. You're the senior engineer explaining your approach to a peer. No jargon without explanation. If you used a technique others might not know, explain it briefly.

**When to post:** Tuesday-Thursday, 8-10 AM in target timezone. Avoid weekends and Monday mornings (everyone's catching up).

**What works:**
- Technical deep dives with concrete code examples
- "How I built X" narratives with architecture diagrams
- Lessons learned from failures (these outperform success stories 3:1)
- Opinionated takes on industry trends (but only if you have data)

**What flops:**
- "Excited to announce" press releases
- Pure product updates without technical insight
- Motivational content without substance
- Posts longer than 2500 chars without strong hook

### X (Twitter)

**Audience:** Developers who ship. They scroll fast and judge faster. You have one sentence to earn their attention.

**Format:**
- 280 characters max
- No threads unless the insight genuinely needs 3+ posts
- Lead with the counter-intuitive or surprising element
- One idea per post. If you have two ideas, make two posts.
- Screenshots need alt-text describing what's shown

**Tone:** Sharp, opinionated, zero filler. Imagine you're texting a builder friend. If it sounds like marketing, delete it.

**When to post:** Tuesday-Friday, 9-11 AM or 2-4 PM in target timezone. Weekends can work for developer audience (they're building side projects).

**What works:**
- One-sentence technical insights ("The difference between a good API and a great one is error messages.")
- Before/after comparisons with metrics
- "Just shipped X. Here's the one thing that surprised me."
- Asking genuine technical questions (engagement bait backfires)

**What flops:**
- Hashtag stuffing
- Threads that could be one post
- Generic "hot take" without personal experience
- Posting links without context

## Content Calendar Rhythm

**Daily (if you have something to say):**
- One X post about what you're working on or learned today

**Weekly:**
- One LinkedIn post: deeper technical insight or project milestone

**Per event (triggered by plugin):**
- PR merged → LinkedIn within 24h, X same day
- Feature shipped → both channels, LinkedIn first, X 90 min later
- Review passed → X only (architecture insights are punchy)
- Major release → LinkedIn deep dive + X announcement

## Anti-Patterns to Avoid

1. **The "we" trap** — Solo builders using "we" sounds insecure. Use "I" unless you're actually a team.
2. **Engagement bait** — "Agree?" or "Thoughts?" at the end of every post reads as desperate. Let the insight stand alone.
3. **Posting without building** — If you haven't shipped in 2 weeks, don't post. Your content should be a byproduct of your work, not a substitute for it.
4. **The LinkedIn bro voice** — "I'm humbled and honored to share..." Delete immediately. You're not accepting an award.
5. **Over-polishing** — A post that sounds like it went through 5 rounds of editing reads as corporate. Ship the draft.
6. **Ignoring replies** — If someone takes time to engage, reply within 24h. The conversation in comments often outperforms the original post.

## Measuring What Works

Track these signals (Buffer, LinkedIn analytics, X analytics):
- **Impressions** — how many people saw it
- **Engagement rate** — (likes + comments + reposts) / impressions
- **Profile visits** — did the post drive people to learn more?
- **Inbound** — DMs, connection requests, or emails referencing specific posts

A good LinkedIn post: 3-5% engagement rate. A great one: 8%+. On X, anything above 2% is solid for technical content.

## Plugin Integration

The build-in-public plugin follows these practices automatically:

```yaml
# What gets shared vs skipped:
on_pr_merged:
  - Share if: >3 files changed, meaningful commit message
  - Skip if: typo fix, dependency bump, config change only

on_feature_shipped:
  - Share: always, with screenshot
  - LinkedIn: deep dive on architecture decisions
  - X: punchy one-liner on impact

on_review_passed:
  - Share if: 3/3 unanimous approval
  - X only: architecture insights are punchy
  - Skip if: 1/3 or 0/3 (revisions aren't share-worthy)
```

## Anonymous by Default

All posts are redacted through `anonymize.yaml` before publishing. Company names become generic descriptors. Revenue becomes "at scale." The reader learns about your engineering, not your employer's financials.