Build in public: what to share before you launch
George · 3 min read
A launch is much easier when some people are already waiting for it. Building in public, sharing your progress openly while you work, is one of the simplest ways for a small team to get there. It costs nothing but time, and it turns launch day from a cold start into a moment people have watched coming.
It only works if your posts are interesting to someone other than you. Here is what to share and how.
Share the problem before the product
People connect with problems they have themselves. Before you show a single screen, write about the problem you are solving: the moment you noticed it, how people deal with it today, and why the current options frustrate you.
These posts also help you test your idea. If nobody reacts to a clear description of the problem, that is useful information before you have built very much.
Show progress people can see
Updates with something visible get far more attention than updates about work in general:
- A short screen recording of a feature that just started working.
- A before-and-after of a redesigned screen.
- A rough sketch or diagram of how the product will work.
- A screenshot of the first time the core workflow ran end to end.
"Worked on the backend today" is invisible. "Invoices now send themselves when they are overdue, here is a ten-second clip" is something people can picture using.
Share decisions and trade-offs
Some of the most engaging posts explain a choice: why you picked one pricing model, why you cut a feature, why you chose a simpler approach. Decisions invite opinions, and opinions bring replies. You will also get useful advice from people who faced the same choice.
Share what you learned, including failures
A post about what went wrong is often more useful to readers than one about what went right. A failed experiment, a bug that cost you a day, or feedback that changed your plans are all worth sharing, as long as you include what you learned.
Numbers, carefully
Revenue, signups, and traffic numbers get attention, but you do not have to share them, especially early when they are small. If you do, be consistent and honest. Small real numbers build more trust than vague claims of growth.
What to keep private
- Customer data, names, and anything shared with you in confidence.
- Security details, keys, and anything that could help someone attack your product.
- Unfinished deals or partnerships that are not yours alone to announce.
- Anything that would embarrass a user or a collaborator.
How often to post
Consistency matters more than volume. One or two genuine updates a week, every week, works better than a burst of daily posts followed by a month of silence. Pick a rhythm you can keep while also building the product.
Build a small list for launch day
The point of building in public before launch is to have people ready when you go live. Give them a way to stay in touch:
- A simple waitlist or email signup on your landing page.
- A pinned post explaining what you are building and when it launches.
- A note in your profile bio.
A week before launch, tell people the date. On launch day, link to your launch page so they can see the product, try it, and support it in one place.
Where to post
Go where your users already are. Developers and founders gather on X and in communities like Indie Hackers. Business users are more often on LinkedIn. Many niches have their own forums, subreddits, and Discord servers. Read each community's rules about self-promotion before posting.
A simple pre-launch plan
- Write one post about the problem and why it matters to you.
- Share one visible piece of progress each week.
- Explain at least one real decision you made.
- Add a way for people to follow along or join a waitlist.
- Announce your launch date a week ahead.
- On launch day, share your launch page with everyone who followed along.
When you launch on ShipDesk.dev, your launch page has a share kit with ready posts and a share picture, so telling the people who watched you build takes a minute.