Indie Hackers Launch Post: What Actually Lands

An Indie Hackers launch post that lands reads like a founder's working notes, not a press release. Lead with a specific problem and a decision you made, show one or two real numbers you are comfortable publishing (time spent, price, what it cost to run), admit what isn't working yet, and end with a question other founders can answer from their own experience. Put the product link in the post, but make the story the reason to read it. Then treat the post as a conversation you've committed to: reply to every comment for the first day and check back on the second. Polished announcements with feature lists and a "check it out" close tend to collect a couple of upvotes and disappear, because the people reading Indie Hackers came to learn how businesses get built, not to be sold one.

Indie Hackers describes itself as a place where founders of businesses and side projects share their stories transparently so others can learn from them. That one sentence explains almost everything about what works there. The currency is transparency. A launch post is judged on how much a stranger learns from reading it.

What kind of post does Indie Hackers actually reward?

Look at what sits on the front page on any given day and a pattern shows up fast. The titles are about a problem, a number or a decision: a founder who built a tool because a spreadsheet kept breaking, someone admitting a claim on their own site was wrong for weeks, someone asking how other people handle a trade-off they're stuck on. The product is usually present. It is rarely the headline.

A few mechanics shape how a post gets seen, and they're worth knowing before you write:

• Posting needs an account. You sign in to submit a post, and the community votes on what rises.
• There's a newest feed and there are top lists. New submissions land in a newest list, and the site ranks top posts by day, week, month and all time. The front page shows a selection of recent submissions alongside the top ones.
• The newsletter follows the votes. The site's own about page says the newsletter compiles the week's top posts as determined by what the community upvotes. A post that earns a real discussion can get a second life there.
• There's a products directory and a build board. Products can be added to their own directory, and a daily leaderboard tracks build-in-public posts. Neither replaces the launch post; they're places for the product to keep existing after it.
• Some makers prefix launch titles with "Show IH:". You'll see it in the newest feed. It signals "I made this, please look", which is honest, but the prefix doesn't do the work. The rest of the title still has to say something.

Features and layout change. Before you post, spend ten minutes reading the top posts of the current week. That's the only style guide that stays current.

Why do polished launch announcements sink there?

Because they answer a question nobody on the site is asking. A Product Hunt launch page is a showroom: the visitor wants to know what the thing does in five seconds. An Indie Hackers reader wants to know how you got here and whether they can use what you learned. A post built for the showroom gives them nothing to take away.

The polished announcement fails in three predictable ways:

1. It has no tension. "Excited to announce" tells the reader the story is already over and went well. There's nothing to follow.
2. It hides the useful parts. The reader wants the price you picked and why, the channel that didn't work, the week you lost to a rewrite. The announcement sands all of that off.
3. It leaves nothing to reply to. A feature list invites agreement or silence. Nobody writes a comment that says "nice features".

The honest counterweight to all launch advice is also on the site itself: founders who have launched dozens of products writing that almost none took off, and that slow, steady work on one product did more than any launch. That's worth keeping in mind. A launch post is one day of attention. It isn't the plan.

What specifics are worth sharing publicly?

Transparency is the currency, but you decide what's in your wallet. You don't have to publish revenue to write a good post. You do have to publish something real.

Specifics that make a post useful, roughly from easiest to hardest to share:

• Time. How long it took to build, and what took longer than expected.
• Cost. What it costs to run per month, or what you spent to get to launch.
• The decision. Why this price, why this stack, why you cut the feature everyone asked for.
• The miss. A channel you tried that did nothing, a bug that hit your first users, a wrong assumption.
• Early usage. Signups, active users or first payments, if you have them and want to share them.
• Revenue. The number many of the site's featured stories lead with, and the most optional.

The rule for all of them: only numbers that are true today and that you'd defend in a reply. A rounded figure you'll be asked to explain is worse than no figure. If you have no users yet, say so. "Zero users, launching today, here is what I'm unsure about" is a legitimate post, and often a better one than a vague "early traction".

How do you write the opening two lines?

The title and the first two lines are all most readers will see before deciding. Give them the problem and the stakes, in your own voice, with one concrete detail.

Weak opening:

Excited to launch FormFix, the AI-powered form builder for modern teams!

Stronger opening:

I kept losing beta signups because my form broke on phones. So I spent six weekends building a form tool that only does short forms.

The second version has a person, a problem, a cost and a constraint. It also sets up the question the rest of the post answers: did cutting everything but short forms work? That's a reason to keep reading.

A quick test for your opening: could someone who never clicks the link still learn something from those two lines? If not, rewrite them.

What does a launch post that earns replies look like?

Here is a full example, marked up paragraph by paragraph. The product is invented so there's nothing here to copy wholesale. Swap in your own story and your own true numbers.

TITLE
Show IH: I built a form tool that only does short forms,
because my beta signups kept dying on mobile

[1] THE TRIGGER
Last spring I ran a beta waitlist for a side project. The form
had nine questions. When I finally checked my analytics, most
visitors were on phones and almost nobody finished the form.

[2] THE DECISION
I tried trimming it. Then I realised every form builder I'd used
made long forms easy and short forms an afterthought. So I built
one that caps a form at five fields. That limit is the product.

[3] WHAT IT IS, PLAINLY
It's called FormFix. You make a form, embed it or share a link,
and responses land in a table you can export. Free for one form,
paid if you need more. Link: formfix.example

[4] THE NUMBERS I'M COMFORTABLE SHARING
Six weekends to build. Hosting is a few dollars a month right now.
Price is $8 a month for unlimited forms; I picked it because it's
below the tools I was comparing against, and I'm not sure it's right.

[5] WHAT ISN'T WORKING
No file uploads yet, and the table view is slow past a few
thousand rows. Two people who tried it in private asked for
conditional logic, which breaks my five-field rule.

[6] THE QUESTION
If you've capped a product on purpose, did users respect the limit
or did you end up removing it?

Why each part earns its place:

Paragraph	What it does	Why it gets replies
Title	Names the product type and the real problem	A reader knows in one line whether this is their problem too
[1] Trigger	A dated, first-person moment	Founders recognise their own mistakes and say so in comments
[2] Decision	Explains the one bet the product makes	A clear bet is something people can agree or argue with
[3] What it is	Plain nouns, pricing tier, the link	Answers "what is it" without turning the post into an ad
[4] Numbers	Time, cost, price and the doubt behind it	Admitting doubt about price gives experienced founders an easy way in
[5] Misses	Admits gaps before anyone finds them	Removes the "gotcha" comment and invites suggestions instead
[6] Question	Asks for experience, not approval	Anyone who's shipped something can answer it in two sentences

Notice what's missing: no "excited", no feature grid, no "would love your support", no request for upvotes. Asking for votes tends to cost goodwill on any community site, and on this one it reads as missing the point.

Before you post, run the draft through this checklist:

• The title names a problem or decision, not just the product name
• The first two lines teach something without the link
• Every number is true today and you'd defend it in a reply
• At least one thing that isn't working is named
• The link is in the post, once, after the story has started
• The closing question can be answered from the reader's own experience
• You've blocked out time to reply today and tomorrow

How long do you stay in the comments?

Plan for two days. The first few hours matter most, because early replies are what make a post look alive to the next reader. Answer every comment, including the short ones. Answer the critical ones first and without defending yourself: thank them, say what you'll change or why you won't, and move on.

On day two, go back. Discussion threads on community sites often keep moving after launch day, and late commenters tend to be the ones who actually tried the product. If a comment changes your mind about something, say so in the thread. That's the kind of detail that makes people follow what you do next.

Then stop. Don't bump the thread with "any more thoughts?" replies. If you have news later, a real update, a first paying customer or a pricing change, that's a new post with its own story.

How does this differ from Show HN and Reddit?

All three reward honesty, but they want different posts.

	Indie Hackers	Show HN	r/SideProject
What readers want	The business story: decisions, numbers, misses	Something they can try right now	The build story and the artifact
Where the product sits	Inside the story	The post is the product	Third paragraph, after the why
Numbers	Welcome, often expected	Rarely the point	Optional
The close	A question founders can answer from experience	No close needed; the comments are the launch	A specific question a stranger can answer
Rules to read first	The current week's top posts	The official Show HN guidelines	The subreddit's rules widget and Reddit's site rules

Hacker News is strict about what counts: its Show HN guidelines say to make it easy for people to try the thing, and put sign-up pages and landing pages off topic. The full walkthrough is in the Show HN checklist. Reddit adds a platform layer on top of each community's rules: Reddit's site rules ask you to participate authentically and not to spam, and the post format that survives r/SideProject is in the r/SideProject launch post guide.

The practical upshot: write three posts, not one. The same launch told as a business story, a try-it-now demo and a build story will each fit their room. Copy and paste one post across all three and it'll read as broadcasting everywhere. If you're still choosing which rooms to walk into at all, the Product Hunt alternatives for indie apps guide sorts them by the kind of app you have, and where to post your app in 2026 covers the wider map.

Frequently asked questions

Is Indie Hackers still worth posting on?

Yes, if your post is useful to founders, and less so if your product isn't for them. It's a room full of people building businesses, so it's strong for feedback, for tools aimed at makers, and for the kind of story that gets you followed. For a consumer app with no founder angle, the post can still work as a lessons-learned piece, but don't expect it to find your end users.

Should I share revenue in a launch post?

Only if you want to. Revenue is the headline number in many of the site's featured stories, but a post can be honest without it. Time spent, running cost, the price you chose and why, and what isn't working are all specifics that make a post useful. Whatever you share, make sure it's accurate today, because someone will ask a follow-up.

Can I post the same launch on Indie Hackers and Reddit?

You can launch in both places, but write a different post for each. Indie Hackers readers want the business decisions behind it; r/SideProject readers want what you built and why. The same text pasted into both reads as broadcasting and tends to underperform in each.

What gets the most engagement on Indie Hackers?

Posts with a real tension and a question at the end: a hard decision, a surprising miss, a specific number with the reasoning behind it. Browse the site's top posts for the current week before you write, since what the community upvotes shifts over time. Asking directly for upvotes is the fastest way to lose the room.

After the thread goes quiet

An Indie Hackers thread does its work over a couple of days, then it scrolls into the archive. The replies are worth having. The people who meant to try your app next week will have a harder time finding it.

That's what a showcase listing is for. Submit your app free and it stays browsable in the showcase with your description, screenshots and link, reviewed by a human before it goes live. The one requirement is that people can actually try it: free, freemium or a free trial, and a working URL. If you want more ways to put the app in front of people after launch week, how to get your first 100 people to try your app picks up where this post ends.

Write the story. Stay in the thread for two days. Then give the app a home that doesn't cool down.