How to build in public on X as a solo founder

Building in public on X means posting the real work as it happens: the question you are chasing, the method, the number you measured, and the caveat that keeps that number honest. You do not need a press team or a finished launch. You need something you actually did, written so a stranger can follow it.

What does building in public on X actually mean?

Building in public on X means showing the work while you are still doing it, not waiting until the story is polished. The record is a run of ordinary posts and threads. Each one should stand alone, so a reader who has never seen your account understands what you tried, what happened, and what you are not claiming.

A launch announcement is a single moment (How to launch a product on X). Building in public is the trail before and after that moment: the half-finished comparison, the baseline you intend to beat, the run that failed, and the measurement you trust enough to put your name on. The point is not to perform transparency. The point is to leave a record other builders can learn from, and to stay visible to the people who care about this kind of work.

Replying under other people's posts, by hand, is the other half of being found early; that craft is in How to reply on X to grow.

Asking for feedback on something still in motion:

What should you share, and what should you keep off X?

Share the work that helps someone else follow along: the question, the setup, the number with its unit, the caveat, and the miss. Keep off X secrets, customer data, unreleased security issues, private messages, and other people's work shared without permission. Building in public is not a request to abandon judgment.

Useful public material usually looks like this:

• The question you are trying to answer, before you have the result.
• The setup: hardware, software, dataset, or constraint, named specifically.
• The number, with the unit and the meter you used.
• The caveat that would change how a careful reader uses that number.
• The miss: the faster path that broke, the accuracy you gave up, the comparison that undersells one side.

Keep off X anything you would not want quoted later as if you meant to publish it.

The first two weeks, before you have results to show:

• Post the problem you picked and why it is yours.
• Post what you tried today and what you learned, even when it did not work.
• Reply by hand under a few people working on the same problem (see How to reply on X to grow).
• Say what you are not claiming yet.

How do you turn a day's work into a post without inventing a story?

Start from a fact you already have: the result, the method, and the limit of the claim. A clean pattern is what you did, what you measured, how you measured it, and what you are not proving yet. Write that, then stop, instead of adding a story about how it felt.

A December 2021 revenue milestone, plus an invitation to ask questions:

Notice what that post includes. It leads with a number he had already hit, then invites questions instead of padding the claim. A stranger can follow it. You do not need a narrative about your feelings or a promise about what this will mean for the industry.

A day's work, drafted from a diff and waiting for approval, looks like this in the Evenpost app on a test account, 10 November 2026:

If your day produced something smaller than a full experiment (a git diff, a bug you closed, a constraint you discovered), the same shape still works. For drafting a post directly from a diff, see Turn a git diff into a build-in-public post.

Why do caveats and misses belong in the same habit as wins?

A number without its limit teaches the wrong lesson, and a feed of only wins teaches people not to trust you. Posting the caveat next to the number, the way Tony Dinh posted churn beside revenue, turns a highlight into a measurement a careful reader can use.

An April 2022 revenue number published next to the churn that qualifies it:

The churn figure is not buried in a later reply. It sits beside the revenue number. That is the difference between a measurement and a highlight reel.

A March 2026 post on a long stretch of shipping, with the time it took and what he said he learned then:

You do not need those exact topics. You need that level of specificity about *your* work: what you tried, what broke, and what you would tell a careful friend before they copied you. For more sourced histories, see How founders grew on X: 6 real case studies.

How often should you post when you are building in public?

Post as often as you have something real to say, with enough space between posts that they do not read as a burst. There is no honest universal count: a day with two measured posts is more useful than a day with twelve vague ones. A thread about one experiment still counts as one moment in the feed.

For cadence and why clustering posts together works against you, see How many X posts a day is too many?. The wider habit of showing up without turning the account into a burst is in How to grow on X as a solo founder. If you approve several posts at once, natural spacing is how they can still go out across the day instead of as a pile.

The individual tweets in a thread should still make sense if someone lands on only one of them.

How do you keep building in public when the work already fills the day?

Draft from the work itself, while the details are still in front of you, then read the post before it goes out. You and your agent can shape a raw note from the terminal into a post, you approve every post today in the Evenpost app, and the voice and the caveats stay yours.

Evenpost is an app for X (Twitter) for solo founders. Your agent drafts from your work, you approve every post in the Evenpost app, and Evenpost posts with even spacing. Updates: @evenpost.

The failure mode for solo founders is not a lack of ideas. It is closing the laptop with the measurement still sitting in a terminal. Evenpost publishes what you approved with natural spacing. If a draft drops the caveat or dresses a baseline up as a final result, reject it.

That loop exists so the day's work can become a post without becoming unsupervised publishing. It does not decide what is worth saying. That part is you.

FAQ

Do I have to share everything to build in public on X?

No. Building in public does not mean publishing every private detail of the company. Share the work that helps someone follow along: the question, the method, the result, and the caveat. Keep credentials, customer data, unreleased security issues, and other people's private conversations off X.

Should I only post wins?

No. A feed of only wins is hard to trust, and it hides the information other builders need. Post the miss and the tradeoff in the same habit as the result, the way a careful lab note would. If a cheaper run lost accuracy, or a revenue post also names churn, that belongs in public next to the number.

How is building in public different from announcing a launch?

Building in public is the ongoing trail of work: the half-finished comparison, the failed run, the measurement you trust. A launch is one announcement that something is available to try. Keep those as separate posts. See How to launch a product on X for the announcement itself.

Can I draft build-in-public posts with an agent?

Yes, if you treat the agent as a collaborator and you read the draft. The agent can shape a post from a measurement, a diff, or a note, and the final words stay yours. Nothing goes out until you have read it in the app. If the draft invents a number, drops a caveat, or sounds unlike you, reject it.

How often should a solo founder post when building in public?

Post when you have a real update, not to hit a generic daily target. Two specific posts beat a dozen vague ones. Leave space between them. See How many X posts a day is too many? for the daily-count question.