How to Build
in Public on Twitter
(X): A Practical Guide

What Building in Public Actually Means

Building in public is the practice of sharing the process behind a product while you are still making it. Not a launch announcement. The messy middle: what you decided, what you shipped, what broke, what the numbers did.

It is worth separating from two things it gets confused with. It is not the same as having a personal brand, which is about what you are known for. And it is not marketing, though it often works as marketing. You can build in public with forty followers and no product, because the point is the sharing itself.

The transparency spectrum

There is no single correct level. Think of it as a dial:

• Open startup. Live public dashboards with revenue, churn, and traffic. Maximum trust, maximum exposure, and very hard to walk back once you start.
• Milestone sharing. You post numbers at moments that mean something: first paying customer, a pricing change, a bad month. Most builders sit here.
• Process only. You share decisions, craft, and lessons, but no financials. Works well if your numbers are boring, private, or not yours to share.

Pick your level before your first post, not after someone asks a question you did not want to answer. Moving down the dial later reads as hiding something, even when it is a perfectly reasonable decision.

Why X Is Where This Happens

Build-in-public culture has pockets on LinkedIn, Reddit, and a handful of forums. The centre of gravity is still X, for reasons worth understanding before you commit.

The founder density is the main one. The people who fund, hire, buy from, and write about small products are already there, in public, replying to each other. A post about a database migration finds an audience on X that it simply does not have elsewhere.

The format helps too. Short posts suit a shipped-it update, and threads suit the longer retrospective, so you can run both cadences on one platform. Replies are where most of the relationship-building actually happens, which is why reply-led growth and build-in-public tend to reinforce each other: your updates give people a reason to follow, and your replies put you in front of people who have not heard of you yet.

One caution. The #buildinpublic tag itself is not a distribution strategy. It is crowded with people posting into the same void, and by most accounts the tag brings in other builders rather than customers. Use it if you like. Do not expect it to do the work.

What to Share, and What to Keep Private

This is the part most guides skip, and it is the part that determines whether building in public helps or quietly costs you.

Worth sharing

• Decisions with the reasoning attached. "We moved pricing from usage-based to a flat tier, here is what forced it." The reasoning is the value. The decision alone is trivia.
• Failures with the specifics intact. A launch that flopped, a feature nobody used, a rewrite that wasted a month. Specific failures are the most useful thing you can publish and the most likely to be remembered.
• Numbers with context. A revenue figure on its own is a flex. The same figure next to what you changed to get it is a case study.
• Craft. How you solved a genuinely hard technical or design problem. This is what earns respect from people who can tell the difference.
• Open questions. Real ones, asked before you build, where the answers will change what you do.

Keep private

• Anything identifying a customer. Screenshots with names, emails, or workspace data. This is the fastest way to lose the trust you are trying to build.
• Security details of unshipped work. Architecture diagrams and auth flows are an invitation.
• Conflicts involving people who did not consent. Co-founder disputes, employee performance, client problems. You are publishing their business as well as yours.
• Numbers you cannot sustain sharing. If you post MRR every month, a bad month is a post you now owe people. Decide whether you want that obligation before you create it.
• Anything under NDA or employment agreement. Obvious, and still the most common way this goes wrong for people building on the side.

Five Build-in-Public Post Formats That Work

"Share your journey" is not an instruction anyone can follow. These five formats are, and between them they cover almost everything worth posting.

1. The shipped-it post

What changed, who it is for, and one concrete detail. Skip the changelog voice.

Weak: "Big update live! Lots of improvements and bug fixes."

Better: "Search now returns results as you type instead of on enter. Sounds small. It cut the average time-to-first-result to roughly a third of what it was, and it was one line moved out of a debounce."

2. The decision log

You hit a fork, you picked a direction, you explain the tradeoff. These age well and get quoted back to you later.

Example: "Chose Postgres over a managed vector DB for search. Slower to build, one less vendor, and at our size the performance difference is not the bottleneck. Revisit at 10k documents."

3. The postmortem

Something broke. Say what, what it cost, and what you changed. Do not soften it into a lesson-shaped platitude.

Example: "Shipped a migration Friday afternoon. Broke signups for six hours before anyone noticed, because our only alert was email and I was out. Added a webhook to my phone. Not shipping Fridays again."

4. The number with a story

One metric, one decision, one outcome. The story is what makes the number readable.

Example: "Churn dropped after we added a setup checklist to onboarding. Turned out people were not leaving because the product was bad. They were leaving because they never finished setting it up."

5. The open question

Ask before you build, and make the question narrow enough to answer in one line.

Weak: "What features should I add next?"

Better: "For those of you using this daily: do you want scheduled exports, or would you rather I made the manual export not take four clicks? Genuinely torn."

Rotate these and you will not run dry. Notice that four of the five require you to have actually done something that week, which is the honest constraint of building in public: it works best when there is real work underneath it.

A Weekly Cadence You Can Actually Keep

The failure mode is not posting badly. It is posting for eleven days and stopping. A rhythm you can hold through a busy week beats an ambitious one you abandon.

1. Ship-day posts. Whenever you ship something a user would notice, post it that day using the shipped-it format. No shipping, no post. Manufactured updates read as manufactured.
2. One weekly recap. Pick a day and keep it. A short thread covering what shipped, what broke, and what is next. This is the anchor that makes the whole thing legible to someone who missed your other posts.
3. Two reply windows a day. Fifteen minutes each on other builders' posts in your space. This is where the audience for your updates actually comes from, and skipping it is why most build-in-public accounts stay quiet.
4. A monthly milestone post. Numbers if you share them, direction if you do not. Longer, more reflective, and the one most likely to get shared beyond your followers.

The recap thread does most of the work. If you only manage one thing a week, make it that.

The Mistakes That Make It Backfire

Building in public has failure modes that are not obvious until you are already in them.

Marketing to founders instead of customers. The biggest one. Revenue screenshots and stack breakdowns attract other builders, because those are the people who find that content interesting. If you sell to dentists, an audience of indie hackers is a nice-feeling metric that will not move your revenue. Ask who a post is for before you write it.

The highlight reel. Only posting wins. It reads as marketing within about three weeks, and it makes the eventual bad news impossible to post without it looking like a crisis.

Performative vulnerability. The reverse failure. Struggle posts written for engagement rather than because something actually happened. Readers detect the difference faster than most people expect.

No continuity. Isolated updates with no through-line. If someone reads three of your posts and cannot say what you are building or who it is for, the transparency is not compounding into anything.

Sharing on someone else's behalf. Covered above, and worth repeating, because it is the mistake with actual consequences rather than just wasted effort.

Competitive paranoia, which is the mistake in the other direction. The fear that a competitor will copy your roadmap is, for almost everyone, larger than the risk. Execution and distribution are the hard parts, and neither is in your roadmap post.

Keeping It Sustainable

The work is real: ship, write it up, reply to people, do it again next week. The writing is usually the first thing to go when a week gets busy, and once you miss two weeks the habit is gone.

Two things reduce that friction. The first is a template, so a shipped-it post is a fill-in rather than a blank page. The second is not writing every post from scratch when the raw material already exists.

Ghosti is a Chrome extension built around that second problem. Its GitHub Tweets feature reads the latest commits from a connected repo and drafts a build-in-public post from what you actually shipped, so the update comes from real work rather than memory.

Thread Studio turns the week's main idea into a multi-part thread, which is the shape the recap wants anyway, and Hunt Mode plus Reply Guy handle the reply windows, all inside the X feed rather than a separate dashboard. Ghost DNA learns your voice from your own examples and rules, which matters more here than in most content: a build-in-public post that sounds like a press release defeats the point of building in public.

Ghosti runs on your own AI key, so you pick the model and pay the provider directly. Pricing and plan details are on the homepage.

How to Tell If It Is Working

Build-in-public metrics are easy to read wrong, because the most visible number is the least useful one.

Likes on a revenue post tell you that revenue posts get likes. Track these instead, over a month rather than a day:

• Follower growth and profile visits. X's own analytics covers your follower and impression trend, which is the baseline for whether your updates make people want more of you.
• Inbound from the right people. DMs, replies, and signups from people who look like your customer, not from other founders. This is the number that actually predicts revenue.
• Which format earns the reach. Tag your own posts by format for a month. Most people find one or two carry the weight, and it is rarely the one they expected.
• Whether anyone follows the story. Do people reference your earlier posts? Ask how the thing you mentioned turned out? That is the continuity compounding.

X publishes the For You ranking system as open source, and the model it describes works by predicting engagement in order to rank posts. In practice, that means the habit which builds relationships tends to help distribution as well. Convenient, but secondary. The reason to build in public is that it makes strangers care about what you are making before it is finished.