How to Build in Public on X: The SaaS Founder Playbook

People often treat building in public as screenshots, revenue charts and daily shipping logs. That is only what you see on the surface. A good public update makes your work easy to follow for someone who cares about the problem. It can bring feedback, record a decision, show demand or bring in the next user.

I started using X while building ClimbX and reached 6,900 followers in 81 days. The follower number was not the useful part. Public posts started conversations. They made me explain things more clearly. They gave the product an audience that cared about the work. This guide shows how to do that without turning your company or your life into content.

What building in public is, and what it is not

Building in public means choosing parts of your work to share before the story is done. The useful unit is not an announcement. It is proof plus context. Readers should see what changed, why it mattered and what you learned.

• It is documentation: decisions, tests, what customers do, tradeoffs and results.
• It is conversation: questions a relevant reader can answer from experience.
• It is a way to get seen: repeated proof that makes people recognize the problem and your view on it.
• It is not surveillance: your audience is not owed private data, exact revenue or every half-formed thought.
• It is not a commit log: a list of what you shipped, with no lesson for the reader, usually only interests you.

Choose the business reason before the content format

“Grow an audience” is too vague to shape a post. Pick one reason for the next 30 days. A founder with no product yet may need problem interviews. A founder with a working product may need testers. A founder with users may need clearer positioning, stronger proof or more eyes on a launch.

The five-part public update

The best build-in-public posts usually go up an evidence ladder. You do not need all five parts every time. A post just gets more useful the further it goes past activity.

Start with the assumption. Say what you saw and name the decision it changed. Add the limits before you ask a relevant reader to reply. These are formats to try. They are not a measured ranking of which format brings the most customers.

Seven formats that give the audience a reason to care

1. 1

   The decision post

   Lay out two real options, the limit that mattered, your choice and what would make you change it. This shows judgment, not just activity.
2. 2

   The customer-language post

   Describe a common problem in customer words with names removed. Then say how it changed the product or positioning. Never expose a private conversation.
3. 3

   The experiment post

   State the guess, the one thing you changed, how long you watched, the result and the catch. Small honest tests are more believable than big general claims.
4. 4

   The proof artifact

   Use a screenshot, chart, short demo or before-and-after only when it proves the claim. A pretty image is not proof.
5. 5

   The mistake and repair

   Name the decision that failed, what it cost, the sign you missed and what changed. Do not perform vulnerability just for engagement.
6. 6

   The weekly operating note

   Sum up what shipped, what changed your mind, what is still unclear and the next goal. This beats a list of finished tasks.
7. 7

   The focused invitation

   Ask for a specific type of user, use case or experience. “Thoughts?” brings noise. A clear “this is for you if” brings useful replies.

What to keep private

Public does not mean exposed. Limits are what let you keep doing this. Check every screenshot for browser tabs, notifications, email addresses, tokens, customer names, private URLs and image metadata. When a lesson comes from a customer, share the lesson and leave out who it was.

• API keys, tokens, cookies, recovery codes, private repos and security details someone could exploit.
• Customer names, emails, analytics IDs, payment details and support chats, unless you have clear permission.
• Partner deals, unreleased integrations, contracts and anything owned by an employer or collaborator.
• Personal routines, locations, family details or health info that do not help the lesson.
• Open decisions where public reaction would skew the work before you have enough proof.

A late look back still counts as building in public. Take private notes during the test. Make the decision. Then post the proof and the tradeoff once the lesson is clear.

Build with customers, not only in front of founders

The most common mistake is pulling in people who enjoy the founder story but will never buy. If your SaaS serves other founders, that overlap can help. If it serves accountants, recruiters, clinics or tradespeople, a founder-heavy audience may clap without buying.

Keep some founder-story posts, but center the account on the customer problem. Use the words buyers use. Show the workflow they know. Spend time in the conversations where they already hang out. My analysis of 926 posts found that broad questions could produce enormous discussion. That helps you get seen, but reach does not prove anyone wants to buy. The next article in this cluster explains why build-in-public posts can get likes without customers.

A sustainable weekly system

1. 1

   Capture while working

   Keep one note with decisions, customer questions, surprising data, bugs, tradeoffs and screenshots that are safe to share.
2. 2

   Select by business value

   Pick the item most likely to clear up the problem, get feedback, prove progress or bring in a relevant person.
3. 3

   Add the missing context

   Explain what you assumed before, the limit you hit and the proof. A stranger will not follow an internal changelog.
4. 4

   Publish in one clear format

   Use a short post for one idea and a thread for a real sequence. Add a screenshot or demo only when it shows proof.
5. 5

   Stay for the conversation

   Answer relevant replies, ask follow-up questions and note the words people use. The replies often hold your next product or content idea.
6. 6

   Review the business outcome

   Track relevant replies, profile visits, site clicks, tester chats, signups and revenue. A post can be useful without going viral.

A practical weekly mix

• One customer-problem observation.
• One decision or tradeoff from the product.
• One proof-backed result or honest failed experiment.
• One useful reply session inside customer conversations.
• One weekly recap with a focused invitation.

How to measure whether building in public is working

Measure it as a ladder. Impressions show reach. Profile visits show curiosity. Relevant follows show your positioning works. Qualified replies and DMs show people know the problem. Trials and sales show money moving. Track each step so you can see where it breaks.

Common build-in-public mistakes

• Posting a task log with no lesson for the reader.
• Turning every setback into a show of vulnerability.
• Sharing customer info because a screenshot looks convincing.
• Writing for other founders when your buyers are somewhere else.
• Asking broad questions that get engagement but no feedback you can act on.
• Letting content eat the hours you need to build and support the product.
• Treating one viral post as a channel you can repeat.
• Hiding the product so well that interested readers cannot understand or try it.

Your first 30 days

At the end of the month, keep the formats that started relevant conversations and moved the product. Drop the ones that only got shallow attention. Over time your build-in-public posts get quieter and sharper, because you learn what your audience and business really need.

Frequently asked questions