Build in Public for a Launch: 30-Day Cadence
A 30-day build in public cadence tied to a launch date, with the exact launch asset each post produces, platform fit, and who should skip it entirely.
By Mark Fulton ·
Building in public works best when you treat it as a production schedule, not a personality. Pick your launch date, count back 30 days, and post two or three times a week about work you were doing anyway. The point is not the audience. The point is that every post forces you to produce one thing your launch needs: the screenshot, the demo clip, the one-line description, the changelog, the FAQ answer. By launch day you paste assets you already made instead of writing a listing from scratch at midnight. If that framing does not appeal to you, or your work is trivially copyable, skip it. It is a tactic, not a moral position.
Most writing on this subject argues about whether transparency is good. That argument is not very useful when you have an app and a date. The practical question is narrower: what do you post, how often, and what does each post leave behind that you can actually use on launch day?
What does building in public buy a solo maker?
Three things, in rough order of how reliably you get them.
Artifacts. This is the underrated one, and it is the reason to do it even if nobody reads a word. To post a progress update you have to take a screenshot, crop it, and describe what changed in a sentence. That is the same work a directory listing, an app store description and a launch post demand. Doing it weekly for a month means launch day is assembly, not creation.
Pressure that produces a date. A public "shipping in three weeks" is a commitment you can feel. Solo projects drift because nothing external says when. A visible countdown is a cheap fix for that, and it costs nothing if you handle a slip honestly.
A handful of people who already know what you built. Not an audience. A handful. Ten or twenty people who watched you build a thing are worth more on launch day than a thousand strangers who see a link once, because they arrive already understanding what it does. Anyone promising you a following in 30 days is selling something.
What it does not buy: traffic, revenue, or a guaranteed launch spike. Those come from the launch itself, from the product being genuinely useful, and from where you post it. Building in public feeds those. It does not replace them.
What should you post when there's no progress?
Some weeks you fix a caching bug and nothing looks different. That is most weeks. Posts that work when the product looks identical to last Tuesday:
- A decision you made and why. "I dropped accounts entirely. Here is what that costs me and what it saves the user." Decisions are content even when code is not.
- A thing you got wrong. Bug you shipped, assumption that broke, feature nobody used. These outperform wins, and they are honest.
- A number from your own work. Build time, bundle size, how long a task takes now versus before. Small and real beats big and vague.
- A question with a real answer you need. Naming, pricing, which of two flows reads better. Ask something you will actually act on. People can tell the difference.
- Something you learned that is not about your product. A library quirk, a platform rule that surprised you. This is the post most likely to reach someone outside your circle.
The failure mode is posting nothing for two weeks and then apologising for posting nothing for two weeks. Nobody was waiting. Just post the next thing.
How does a public build feed your launch assets?
Here is the cadence. Three posts a week, roughly Monday, Wednesday and Friday, for four weeks plus launch. The right-hand column is the whole point: each post leaves behind a file or a paragraph you will use again.
| Day | Post | Launch asset it produces |
|---|---|---|
| Day 1 | What you're building and who it's for, in two sentences | Your tagline draft |
| Day 3 | The problem, with a concrete example from your own life | Opening paragraph of your launch post |
| Day 5 | First screenshot of the ugly working version | Before shot for a later comparison |
| Day 8 | A decision and its trade-off | An FAQ answer |
| Day 10 | Screenshot of the main screen, cleaned up | Listing screenshot 1 |
| Day 12 | A thing you cut, and why | The "what this is not" line in your description |
| Day 15 | Short clip of the core action, start to finish | Your demo GIF |
| Day 17 | A bug you shipped and fixed | Trust, and a changelog entry |
| Day 19 | Second and third screenshots: settings, results, empty state | Listing screenshots 2 and 3 |
| Day 22 | Ask for testers, with a link that works | Your first real users |
| Day 24 | What a tester told you that you didn't expect | Feedback quote you can use, with permission |
| Day 26 | Your launch date, stated plainly | The commitment |
| Day 29 | The full description, posted as a draft, asking if it's clear | Your directory and store description |
| Day 30 | Launch. Link, demo, and you in the replies for the day | The launch itself |
A few notes on running it.
Day 15 is the hinge. A short clip of the core action is the hardest asset to fake and the one most listings are missing. If you only do one thing from this table, do that one. Our 20-second demo GIF shot list covers what to include and what to cut.
Day 10 and Day 19 give you three real screenshots, which is what most submission forms want. Sizes and framing rules are in the screenshot guide.
Day 17 is worth formalising. Keep a plain text changelog from Day 1 rather than reconstructing one at the end. The Keep a Changelog format is a fine default: notable changes grouped under Added, Changed, Fixed and Removed, newest first, written for humans rather than dumped from git log. That file becomes your update history on every platform that asks for one.
Day 22 needs its link to work for strangers, not just for you. If you are launching on Android, closed testing has a real gate: Google's guidance on setting up an open, closed, or internal test is where to check the current requirements for your track before you promise anyone access. Start recruiting testers earlier than feels necessary, because approval and device setup both take longer than you expect.
Day 30 is a day of work, not a post. The Product Hunt launch day runbook breaks the hours down if that is your platform, and the solo developer launch checklist covers everything that has to be true before you press anything.
Which platforms suit which kind of update?
Posting the same update everywhere is how the habit dies. Match the update to the room.
| Platform | Best for | Cadence that survives | Avoid |
|---|---|---|---|
| X | Short progress notes, screenshots, small numbers | 3 to 5 a week, one line each | Long essays, threads with no image |
| Decisions, trade-offs, lessons in plain language | 2 or 3 a week, short lines | Screenshots with tiny text, jargon | |
| Maker communities | Weekly recaps, asking for feedback | Once a week at most | Bare links, reposting the same recap |
| Your own changelog page | Every shipped change | Whenever you ship | Marketing language in a changelog |
| Email list | The launch, and one or two real milestones | Rarely, and only when something matters | Weekly updates to people who signed up for a product |
| Show HN | The finished, working thing, once | Once, when it is genuinely ready | Progress posts, landing pages, waitlists |
That last row is worth being precise about, because people burn their one shot. The Show HN guidelines say the format is for something other people can play with, that sign-up pages and landing pages are off topic, and that if your work is not ready for users to try, you should come back when it is. So a build-in-public update does not belong there. The finished thing does, once, on launch day.
Trading feedback with other builders is a different kind of channel again, and a more reliable one early on. Communities like favors.dev exist for builders who swap real help rather than upvotes, which is what you want at Day 22 when you need people who will genuinely try the thing and tell you what broke.
How much detail is too much?
Decide your boundary once, at Day 1, and write it down. Changing it mid-build is what creates regret.
Safe to share, almost always: screenshots, the stack, decisions, bugs, what you cut, time spent, what you learned. None of it helps a competitor much and all of it is interesting.
Share carefully: revenue, user counts, and conversion rates. Numbers pull attention, and they also set a bar you then have to keep clearing. A month of public revenue screenshots followed by silence reads worse than never having posted one. If you do share, share consistently or not at all.
Do not share: anything under NDA, customer data or screenshots containing it, security details, and the exact thing that makes your product hard to copy if that thing is a few days of work rather than a few months. Also skip live drama about clients, employers or other people's products.
One test that settles most cases: if this post were screenshotted and shown to the person it mentions, or to a customer, would you be comfortable? If not, do not post it.
Who should skip this entirely?
Genuinely, some people should not do this.
- Anyone whose product is a few days of work to clone, with no data, network or distribution defending it. Posting the idea early is doing a competitor's research for them.
- Anyone who finds public accountability paralysing. If a missed self-imposed date will stop you shipping rather than push you, the pressure is a cost, not a benefit.
- Anyone under an employer or client agreement that covers what you can say about your work. Check before, not after.
- Anyone with three weeks of runway and a half-built product. Build the thing. Posting about it will not save it, and the hours are better spent on the product.
There is also a quieter version that suits most people better than the loud one: build in public to a changelog page and a handful of people, not to a feed. You get the artifacts and the discipline without the performance.
FAQ
Do I have to share revenue numbers?
No, and for most solo makers it is the wrong place to start. Revenue posts attract attention from people interested in revenue posts, which is not the same as people who want your product. Screenshots, decisions and honest bugs do more for a launch. If you do share numbers, commit to sharing them on a schedule, because selective reporting is obvious and it costs you the trust the practice was meant to build.
Does building in public help you get users?
It reliably produces launch assets and a small group of people who already understand your product. Those help. It does not reliably produce traffic, and nobody can promise you a number, because it depends on your existing reach, your niche and what you actually shipped. Treat the assets as the guaranteed return and any audience as a bonus.
What if nobody engages with the posts?
That is the normal first month, and the calendar above is built so it still pays. Every post leaves a screenshot, a clip, a description or a changelog entry behind. Silence costs you nothing except the feeling of it. If you want responses rather than views, ask a specific question you will act on, and reply to other builders' posts first. Engagement is mostly reciprocal.
Can you build in public with a small following?
Yes, and the calendar does not change. With a small following the posts are working documents that happen to be public, and the value shifts almost entirely to the assets and the handful of people who do show up. Post where a stranger can find you through a topic rather than through your profile, answer other people's questions in the same rooms, and let the audience be a side effect.
If you have run a month like this, the work is already done. You have a tagline, three screenshots, a demo clip, a description and a changelog sitting in a folder. That is a complete submission. Submit your app free and a human will review it before it goes live. Listings are free for apps people can actually try, which after 30 days of building in public yours certainly is.