Marketing an app when you're the only one building it

The problem isn't that you don't know what to post. It's that posting loses every prioritisation fight it ever enters. There is always a bug worth more than a tweet, and it's always genuinely true, which is what makes it so effective at killing your marketing.

So this isn't a list of ideas. It's about building something that survives the weeks you vanish into the code.

Why launches don't compound

A good launch day gets you a spike: traffic, some signups, a burst of encouragement. Then you go back to building, and three months later the traffic is at zero and the audience hasn't grown, because a launch buys attention rather than an audience.

The accounts that compound post through the boring middle — the months where nothing is launching and there's nothing to announce. That's precisely when a solo founder has the least to say and the least time to say it.

Stop posting about your product

The most common mistake, and it feels like the obvious thing to do. Your feed becomes features, releases and screenshots — content that only lands with people who already know what your product is.

The people you want are searching for the problem. They don't know your category exists. Someone struggling to keep track of freelance invoices isn't looking for invoicing software; they're looking for a way to stop losing invoices. Post about that, and the product is the thing they find at the end.

A rough ratio that works: four posts about the problem for every one about the product. Most founders run that backwards.

You are the worst judge of what's interesting

You've thought about this problem for a year. The framing that feels obvious and boring to you is frequently the thing nobody else has articulated — and the clever insight you want to lead with usually requires context your audience doesn't have.

The test: if explaining something to a new user makes you say "oh, everyone gets confused by that" — that's a post. Your support inbox is a content calendar and most founders never read it that way.

Your changelog is a content source

You're already writing release notes nobody reads. Each meaningful release solves a problem, and the problem is the interesting half.

Rather than "v2.3: added bulk export", the post is about the twenty minutes people were wasting before bulk export existed. Same information, aimed at someone who doesn't use your product yet. It also gives you a steady supply of posts generated by work you were doing anyway.

Build in public, minus the theatre

Build-in-public works when it's about decisions and trade-offs — what you chose, what you rejected, what broke. It stops working when it becomes revenue screenshots and milestone announcements, which are content about you rather than for anyone.

The useful version reads like a technical decision log written for humans. The tiresome version reads like a scoreboard.

Pick the platform your users are on, not the one you're on

Founders default to X because that's where founders are. If you're building developer tools, fine. If you're building a consumer app, your users are on Instagram and TikTok and your feed is reaching an audience of other founders who will never be customers.

This is worth being honest about in both directions. It's also why our own page for app makers says plainly that if you're B2B and selling on LinkedIn, this probably isn't your tool.

A system that survives a build sprint

1. Write twenty problem-focused topics in one sitting. Take them from your support inbox, not your imagination. An hour, once.
2. Pick a cadence you can hold in your worst month, not your best. Two a week that never stops beats daily for five weeks — the reasoning is here.
3. Batch or automate the production. The failure is never the idea, it's the forty minutes of making the thing at 9pm.
4. Let releases top up the queue. Every meaningful ship is one post about the problem it solved.
5. Check monthly, not daily. Daily numbers are noise and they'll make you quit.

The uncomfortable part

Nobody is going to do this for you at the stage you're at, and hiring it out before you know what resonates produces expensive generic content. The realistic options are to protect an hour a week for it, or to automate the production and keep the judgement.

If it's the second — SlideBuddy generates and publishes the carousels, and on Studio and Agency you can drive it over MCP from Claude or Cursor, so queuing a post about what you just shipped is a sentence typed where you already are.