There's a pitch that floats around developer Twitter every few months: just build in public. Share what you're working on, post your progress, let people follow along. The audience will come, the opportunities will follow, and your side project will practically market itself.

It's not wrong. Developers who consistently share their work do build audiences, attract collaborators, and open doors that would otherwise stay shut. But there's a gap between the advice and the reality. Most developers who try to build in public start strong — a week of daily updates, maybe two — and then go quiet. Not because the strategy failed, but because the execution is exhausting.

This guide is about closing that gap. How to build in public as a developer in a way that actually lasts.

What building in public actually means

Building in public is the practice of sharing your work process openly as it happens, rather than waiting until you have a polished launch to announce. For developers, this usually means posting about the code you're writing, the decisions you're making, the problems you're solving, and the metrics you're tracking — all while the project is still in progress.

It's not the same as open source, though they overlap. Open source means your code is publicly available. Building in public means your journey is publicly visible. You can do one without the other, or both at the same time.

The format varies. Some developers write long-form blog posts about their architecture decisions. Others post short daily updates on Twitter. Some stream their coding sessions live. The medium matters less than the consistency.

Why building in public works for developers

Before getting into the how, it's worth understanding why this strategy has so much traction in developer communities specifically. There are four main reasons.

Social proof that compounds

Every public update is a small deposit into your professional reputation. A single tweet about fixing a tricky bug doesn't do much on its own. But six months of those tweets, stacked together, creates a body of evidence that you know what you're doing. Potential employers, clients, and collaborators can see your thinking process, not just a static resume.

This is especially powerful for self-taught developers and indie hackers who don't have a brand-name company on their LinkedIn profile. Your public build log becomes your portfolio.

Networking that happens naturally

When you share specific technical decisions — why you chose Postgres over MongoDB, how you structured your API layer, what testing strategy you went with — other developers respond. They agree, disagree, offer alternatives, share their own experiences. These conversations become genuine professional relationships, not the forced kind you get from cold outreach.

Some of the strongest developer communities on Twitter and LinkedIn formed around people who were simply building in public and responding to each other's updates.

Accountability you didn't know you needed

There's something about telling a few hundred (or even a few dozen) people that you're working on something that makes you actually work on it. Public commitment creates a gentle pressure to follow through. It won't save a doomed project, but it will get you through the weeks where motivation dips and the code isn't cooperating.

Developers who build in public report shipping faster and more consistently than when they worked in silence. The audience becomes an accountability partner.

Hiring and opportunity signals

Hiring managers and recruiters increasingly look at public developer activity. Not just open source contributions — though those help — but any evidence that a candidate thinks deeply about their craft and communicates well about technical topics.

Building in public gives you a stream of content that demonstrates both skills simultaneously. You're showing you can write code and explain it. For developer advocates, DevRel roles, and senior positions where communication matters, this is a significant advantage.

The burnout problem nobody talks about

Here's the part of the build-in-public narrative that gets conveniently left out: it's genuinely hard to sustain.

Think about what's actually involved. You spend your day writing code — solving problems, debugging, refactoring, reviewing PRs. At the end of that, you're supposed to context-switch into content creator mode. Open Twitter. Think about which part of your day would make an interesting post. Write it in a way that's engaging but not clickbaity, technical but not impenetrable, personal but not oversharing. Do this every day.

Some developers manage it for a while through sheer willpower. But willpower is a finite resource, and it's already depleted by the actual work of building software.

The pattern is predictable. Week one: daily updates, genuine enthusiasm, good engagement. Week two: still posting, but the updates feel forced. Week three: you skip a day. Then two. Then a week. Then you're one of the thousands of developers who have an abandoned build-in-public thread on Twitter with a last post from four months ago.

This isn't a character flaw. It's a workflow problem. Building in public asks you to do two jobs — build the thing and market the thing — with the same hours and the same energy. Without a system to make the marketing part nearly effortless, most people can't keep it up.

A sustainable approach to building in public

The developers who successfully build in public long-term have one thing in common: they found ways to reduce the friction. They're not more disciplined or more extroverted. They just made the process easier.

Here are the three principles that make it work.

Automate what you can

The biggest source of friction in building in public is the translation step: going from "I did this work" to "here's a post about this work." If you can eliminate or reduce that step, you remove the main reason people quit.

Your commit history already contains the raw material for public updates. Every meaningful commit is a potential post — a feature shipped, a bug fixed, a refactor completed, a performance improvement measured. The information is there; it just needs to be transformed into a shareable format.

This is exactly the problem CommitLore was built to solve. When you add /lore to your commit message, CommitLore reads the diff, understands the change, and generates a draft post for Twitter, LinkedIn, or your blog. The work you're already doing — committing code — becomes the input for your public content. No separate content creation step required.

Batch your content

Not every update needs to go out in real time. You can commit code on Monday through Friday and schedule all your public posts on Sunday evening. Batching lets you review everything at once, pick the most interesting updates, and ensure you're not over-posting about small changes or under-posting about big ones.

Tools like Typefully let you queue up a week's worth of tweets and drip them out on a schedule. Combined with an automated draft generator, your weekly content workflow can take 20 minutes instead of 20 minutes per day.

Set a minimum viable cadence

Daily posting is not required. Three times a week is plenty. Twice a week is fine. Even once a week, consistently, puts you ahead of the vast majority of developers who post nothing at all.

Pick a cadence you can maintain on your worst week — when you're sick, when the codebase is on fire, when you just don't feel like it. That's your floor. Anything above it is a bonus.

A developer who posts twice a week for a year will have over 100 public updates. That's a serious body of work, and it's more than enough to build an audience and a reputation.

What to share when you build in public

One of the biggest blockers is not knowing what's "interesting enough" to post about. Developers tend to underestimate how interesting their daily work is to other developers. Here are the categories that consistently perform well.

Features and launches

The obvious one. When you ship something new, talk about it. But go beyond "we launched X." Explain what it does, why you built it, and one interesting technical detail about the implementation. Specificity is what separates a forgettable announcement from an engaging post.

Bugs and debugging stories

People love debugging stories. The weirder the bug, the better the post. "Spent 4 hours tracking down a race condition that only appeared on the second Tuesday of the month" is inherently interesting content. Share what the bug was, how you found it, and what the fix turned out to be.

Metrics and milestones

Numbers make abstract progress concrete. Revenue, user count, response times, test coverage, deploy frequency — any metric that shows movement is worth sharing. You don't need to share everything, but sharing something makes your journey tangible.

Lessons learned

"Here's what I would do differently" posts are consistently among the highest-performing content in developer communities. They signal experience and humility at the same time. Architecture decisions you'd reverse, libraries you'd swap out, processes you'd change — all fair game.

Stack decisions and trade-offs

Why did you pick Next.js over Remix? Why PostgreSQL over a NoSQL option? Why that particular auth library? These decisions are interesting because every developer faces similar choices, and hearing someone else's reasoning — especially after they've lived with the consequences — is genuinely useful.

Where to share: picking your platforms

You don't need to be everywhere. Pick one primary platform and optionally one secondary, then actually be consistent there before expanding.

Twitter / X

Still the dominant platform for developer build-in-public content. The short-form format works well for daily updates, and the developer community is active and engaged. Threads work well for longer narratives about features or debugging sessions. Hashtags like #buildinpublic and #indiehackers help with discoverability.

Best for: Quick updates, debugging stories, milestone celebrations, hot takes on tech decisions.

Underrated for developers. The audience skews more toward engineering managers, CTOs, and recruiters, which makes it valuable for career-related visibility. Posts tend to get more reach per follower than Twitter, and the comment quality is often higher for professional topics.

Best for: Architecture decisions, career reflections, milestone announcements, project retrospectives.

Dev.to

A dedicated developer community that rewards long-form technical content. Articles about your build process, technical deep-dives, and tutorials based on what you're building all perform well here. The audience is specifically developers, so you can go deeper on technical details.

Best for: Technical write-ups, tutorials, architecture breakdowns, project postmortems.

Personal blog

The only platform you fully own. Content here is permanent, indexable, and under your control. Even if you post primarily on social media, having a blog that aggregates your build-in-public journey creates a lasting archive. It also helps with SEO for your project.

Best for: Everything, but especially long-form content you want to own permanently.

Tools that help you build in public consistently

The right tools turn building in public from a daily chore into a background process that runs alongside your development workflow.

CommitLore — commit-to-content automation

CommitLore connects to your GitHub repositories and generates social media content directly from your commits. Add /lore to any commit message and get a draft post tailored for your chosen platform. It reads the actual diff, so the content is specific and technical — not generic marketing fluff.

This solves the core problem: the translation step between doing the work and talking about the work. Instead of staring at a blank tweet compose box at the end of the day, you review a draft that was generated from the code you already wrote.

The Starter plan runs $12/month and covers up to 3 repositories with Twitter and LinkedIn support. For most indie developers and small teams, that's all you need.

Typefully — tweet scheduling and threads

Typefully is a dedicated Twitter scheduling tool that's popular in the build-in-public community. Queue up your tweets, schedule them for optimal times, and track engagement. Their thread composer is particularly good if you like sharing longer-form updates on Twitter.

Pairs well with CommitLore: generate drafts from your commits, then schedule them through Typefully for consistent publishing.

GitHub profile — your living portfolio

Your GitHub profile is itself a build-in-public tool. A well-maintained profile README, consistent commit activity (the contribution graph), and descriptive repository documentation all signal that you're actively building. Pinned repositories and a clear bio turn your GitHub profile into a portfolio that updates itself as you work.

Developers who built their careers in public

The build-in-public approach isn't theoretical. There are concrete examples of developers who used it to create real opportunities.

The indie hacker path. Developers like Pieter Levels (levelsio) built entire businesses — Nomad List, Remote OK, Photo AI — while documenting every step publicly. His Twitter following grew alongside his revenue, and each project launch benefited from the audience he'd built by sharing the previous one. He famously targets $1M+ in annual revenue as a solo developer, and his public build log is a significant part of how he acquires users.

The career accelerator. Developers who consistently share technical content attract recruiter attention, conference invitations, and consulting opportunities. Swyx (Shawn Wang) coined the concept of "learning in public" and parlayed that approach into roles at AWS, Temporal, and Airbyte, plus a significant following that opened doors at each step.

The community builder. Some developers use building in public to attract contributors to open source projects. When people can see the decisions being made and the direction a project is heading, they're more likely to get involved. Daniel Roe's public work on Nuxt is a good example — his transparency about the framework's development helped build one of the most engaged communities in the Vue ecosystem.

The common thread across all these examples isn't personality type or writing skill. It's consistency. They showed up regularly and shared what they were working on. The format, platform, and style varied, but the habit didn't.

Your 30-day build in public kickstart plan

If you've read this far, you're interested but maybe not sure where to start. Here's a concrete plan for your first 30 days.

Days 1-3: Set up your infrastructure.

Pick your primary platform (Twitter or LinkedIn — just one to start)
Set up CommitLore on your main repository so commit-to-content drafts are automatic
Write a brief "starting" post: what you're building, why, and that you'll be sharing the journey
Follow 20 developers who are already building in public, so your feed has examples

Days 4-14: Build the habit.

Aim for 3 posts per week minimum
Use your CommitLore drafts as starting points — review, edit lightly, and publish
Focus on what you're working on today, not grand narratives about the project
Reply to other builders' posts — engagement is a two-way street
Don't worry about follower count; it's irrelevant this early

Days 15-25: Find your voice.

Notice which of your posts get the most engagement and lean into that style
Try different formats: short updates, debugging stories, decision explanations, metric shares
Start batching if daily posting feels heavy — write three posts on Sunday, schedule for the week
Share one "lesson learned" post — these tend to resonate strongly

Days 26-30: Evaluate and adjust.

Review your posts from the month. Which felt natural? Which felt forced?
Decide on a sustainable cadence for month two and beyond
Set up any additional tooling (Typefully for scheduling, a second platform if you have capacity)
Write a "30-day retrospective" post — your audience loves meta-content about the process itself

The goal of this first month isn't to go viral or gain thousands of followers. It's to prove to yourself that you can share your work publicly without it consuming your life. If you end the month with a rhythm that feels maintainable, you've succeeded.

The honest truth about building in public

Building in public works. The evidence is overwhelming. Developers who do it consistently build bigger audiences, attract better opportunities, and ship more product than those who build in silence.

But the honest truth is that it's hard to sustain manually. The developers who make it look effortless have almost always built systems — automated, semi-automated, or at least highly streamlined — that reduce the effort of turning their work into content.

That's the problem CommitLore exists to solve. Your commits already tell the story of what you're building. CommitLore translates that story into content you can share. The building happens in your editor. The public part happens automatically.

You don't need to become a content creator. You just need to let the work you're already doing speak for itself.

How to Build in Public as a Developer (Without Burning Out)