By Appzoku ·
Building in public means sharing the work while it is happening: what you shipped, what you decided, what went wrong. Done well it builds trust and an audience before you need either. Done badly it becomes a stream of vague updates nobody reads. Here is what to post and how to keep it useful.
What to share
- Release notes as posts. Every update is content. A "what's new" carousel with the real screens beats a line in a changelog.
- Decisions and why. "We removed the tutorial and kept one screen" is more interesting than the fact that you shipped.
- Before and after. A real screen from three versions ago next to today's.
- Mistakes and fixes. A bug that cost you a weekend and how you found it. Specific beats polished.
- User feedback, with permission. A request that shipped, credited to the user if they agree.
- Milestones that are real. A rating, a review count or a version number, stated plainly. Do not round up.
What to leave out
- Numbers you cannot back up.
- Anything about a user's data or private messages.
- Complaints about platforms or competitors that read as venting.
- Vague teasers with nothing in them.
Pair it with posts for your audience
A feed that is only about you is a diary. Alternate behind-the-scenes posts with posts that are useful about the topic your app covers: tips, facts, relatable posts. Founders follow founders; users follow what helps them. You want both groups, so give each something to save. See 35 post ideas that aren't ads.
Turn each release into a week of content
- 1A "what's new" carousel on release day, from your release notes.
- 2A feature spotlight a few days later, one feature and one screenshot.
- 3A how-to for the most useful change.
- 4A thank-you post to the user who asked for it, if they agree.
Post Studio's "What's new" post type builds the first of these from your latest App Store release notes, and its other types cover the spotlight and how-to. You can edit all of it before downloading.
A note on tone
Write the way you would explain it to a friend who also builds apps. Plain words, specifics, no hype. If a post makes you wince when you read it back, rewrite it.
Is building in public worth it for a small iOS app?
It can be, if you share specific, honest updates and pair them with content that is useful to your audience. Vague updates do not build anything.
Should I share revenue numbers?
Only if you are comfortable and the numbers are accurate. Milestones like ratings, reviews and versions are lower-risk and still show progress.
How often should I post build-in-public updates?
Tie them to real events: a release, a decision, a milestone. A post a week is plenty when there is something to say.