Build in public is the oldest piece of founder led marketing advice on X, and most people do it badly. They post a progress screenshot every Friday, call it a weekly update, and wonder why nobody cares. The problem is not the idea. The problem is that progress on its own is not a story. Your followers do not care that you shipped a settings page. They care about why you made the calls you made, and whether the thing will solve their problem. This play gives you a twelve week plan that builds toward launch day.
What build in public on X actually means
To build in public on X is to show your reasoning while you work, so that people who share your problem start to trust your judgement before they ever use your product. That is the definition we use.
Notice what is missing: it does not say “share everything”. Total transparency is a choice some founders make, and it is fine, but it is not required. You need enough openness that a stranger can follow the story. That means the problem, the decisions, the tradeoffs, and some honest numbers.
Before you start, write a short list of things you will never post. Customer names without permission. Security details. Anything an investor asked you to keep private. Having this list means you will not freeze every time you sit down to write.
Screenshots show what you did. Decision logs show how you think. Only one of those builds trust.
Weeks 1 to 3: the problem
Do not show the product yet. Talk about the problem.
For a hypothetical AI tool that drafts customer support replies, weeks one to three are about support teams drowning in repetitive tickets. Post what you learned from talking to support leads. Post the workaround people currently use and why it breaks. Post the thing that surprised you.
An illustrative post for this phase:
“Talked to 11 support leads this month. Not one of them complained about ticket volume. All of them complained about the same 30 questions coming in every day, worded slightly differently each time. That is the problem we are working on.”
The goal of this block is simple: the right people should start recognising themselves in your posts.
Weeks 4 to 6: the decisions
Now you start showing how you are building, but through decisions, not features.
Every week, post one decision log. The format:
- What we had to decide.
- The options we considered.
- What we picked and why.
- What would make us change our minds.
This is the core of founder led marketing that works. It lets readers argue with you, which is engagement you actually want. It also shows that a real person with real judgement is behind the product.
Mix in one honest number per week. Interviews done, prototype users, response time on a test set. Pick numbers you are comfortable seeing on a screenshot forever.
Weeks 7 to 9: the product
Now show it. Short screen recordings of one thing working. A before and after on a real (anonymised) example. A thread on the hardest technical problem you solved.
This is also when you open the waitlist. Not earlier. If you open it in week one, you ask people to commit to something they know nothing about. By week seven they have watched you think for six weeks. The ask makes sense now.
Put the waitlist link in your bio and in your pinned post. Mention it in roughly one post out of five. More than that and the account turns into an ad.
Threads do most of the heavy lifting in this phase. If you have not written one before, read the play on how to write a Twitter thread that sells and look at our annotated thread examples.
Open the waitlist when people start asking how to try it. If nobody is asking, you are not ready to ask them.
Weeks 10 to 12: the countdown
Announce the launch date three weeks out. Then start the countdown, but keep it about the user, not about you.
- Week ten: who this is for and who it is not for. Saying no to an audience makes the right audience lean in.
- Week eleven: early user feedback, with permission, and what you changed because of it.
- Week twelve: what launch day will look like and how people on the waitlist get in first.
During this block, you should also be in regular contact with the AI creators you started warming up earlier. They should hear about the date from you directly, before they see it in their feed. The play on the Twitter marketing strategy for AI startups covers how that warmup fits into the bigger plan.
Common ways this goes wrong
A few patterns we see in almost every account teardown:
- Updates without stakes. “Shipped auth today” tells nobody anything. “Shipped auth. Chose magic links over passwords because our users forget passwords twice a week” tells them how you think.
- Going quiet when things break. The weeks where something goes wrong are the most interesting weeks to post. Share the problem and how you are handling it.
- Talking only to other founders. Founder audiences cheer each other on, but they are rarely your users. Write for the person with the problem.
- Stopping at launch. Building in public does not end on launch day. That is just when the audience is largest.
Run it with a plan, not a mood
Building in public fails when it depends on how you feel that day. The fix is a plan written in advance, with every week’s theme decided before you start. If you want that plan built around your product, along with the threads and the AI creator outreach, that is what the pre-launch audience sprint does.