r/SideProject Launch Post: Format That Survives

To post on r/SideProject, read the subreddit's current rules on the sidebar first, then write a post that leads with the build story rather than the product. A post that survives has four parts: a title that says what you made and for whom, a body of three or four short paragraphs covering why you built it, what it does and what it cannot do yet, a link placed wherever that subreddit's rules allow it, and a specific question at the end that a stranger can answer in one sentence. Then you sit in the thread and reply to every comment for the next several hours. Posts get removed for being a bare link with no context, for being the same project posted again too soon, and for being a referral or affiliate push. Posts get ignored for a much simpler reason: nobody was given anything to reply to.

Rules summaries tell you what gets removed. They do not tell you what gets read. Those are different problems, and most launches that fail on Reddit fail the second one while passing the first. The post is up, it is compliant, it collects four upvotes and no comments, and it is gone by morning.

What does r/SideProject remove and why?

Two layers of rules apply to anything you post, and only one of them is written by Reddit.

The platform layer is Reddit's own content policy. Its second rule is "Abide by community rules", and it asks that you participate authentically in communities where you have a personal interest and that you do not spam or engage in behaviour that manipulates or disrupts a community. That is the sentence that sits behind account bans, as opposed to post removals. It is also the sentence that makes the ratio advice you have heard roughly correct without anyone needing to invent a number for it: an account whose entire history is links to one domain is not participating authentically, and it does not matter how good the product is.

The community layer is written by the moderators of the subreddit. Reddit's Moderator Code of Conduct, effective June 2025, requires mod teams to set clear and reasonable expectations and to publish them. That is why the rules widget exists and why it is the only source worth trusting. Subreddit rules change without notice, and guides that summarise them, including this one, go stale. Open the subreddit's rules page in another tab and read it before you write anything. Two minutes.

What that layer usually catches in a maker community:

• A link with no substance around it. A title plus a URL plus nothing reads as an ad to a human mod and to automod filters alike. The description is not decoration. It is the thing that makes the post a post.
• The same project posted again too soon. Reposting a launch every couple of weeks with a new title is the most common route to a ban in maker subreddits.
• Referral links, affiliate codes, and paid gates dressed as free. If the "try it" link goes to a checkout, say so in the body.
• Overstating what exists. A waitlist page described as a launch, or a mockup described as a working app, gets called out in the comments long before a mod arrives.
• Recruiting. Looking for a cofounder or contractor is a different post in a different subreddit.

None of that is unique to one subreddit. It is the shape of every maker community, which is why the same post rewritten travels well across several of them. The map of which communities are worth the rewrite is in where to post your app in 2026.

What does a post that gets comments look like?

It looks like a person talking about a problem they had. The product arrives in the third paragraph as the consequence, not the subject.

Here is the full shape, ready to copy. The project in it is invented so nothing here is a real launch you can cargo cult. Replace every bracketed part, and read the notes underneath for the two lines that come out depending on the subreddit's rules.

TITLE
I built a CLI that diffs two OpenAPI specs because I kept
breaking my own API by accident

BODY

[1] The trigger. Two or three sentences. A specific moment, with
    a date or a number that is actually yours.
For about a year I have maintained an API that four other teams
build against. Twice this spring I shipped a change that broke
one of them, and both times I had reviewed the diff and missed
it because the spec file is nine thousand lines long.

[2] What you built, in plain nouns. No adjectives. No category
    words like "platform" or "solution".
So I wrote a command line tool. You give it two spec files or
two URLs and it prints what changed, grouped into breaking,
additive, and cosmetic. It exits non-zero on a breaking change
so I can put it in CI.

[3] What it does not do yet. Do not delete this paragraph.
    It is the paragraph that gets replies.
Right now it only handles OpenAPI 3.x, JSON and YAML. It does
not understand webhooks properly, and the "cosmetic" bucket is
too aggressive about description changes. GraphQL is the thing
people keep asking for and I have not started it.

[4] The link and the honesty about cost.  <-- REMOVABLE
It is free and open source, no signup: <link>. There is no paid
version and I am not planning one.

CLOSING QUESTION  <-- keep, and make it answerable in one line
If you maintain an API that other teams consume, what actually
tells you a change is breaking today? I want to know whether
CI is the right place for this or whether it belongs in the
pull request diff.

Notes on the two moving parts:

Paragraph 4 comes out if the subreddit's rules restrict links in the body, or if you are posting to a community you have never participated in. In that case, post the body without it and add the link as your own first comment straight away. Do not delay it to game anything. People are looking for it.

The bracketed labels come out too. They are scaffolding. Paste the block, write over it, then delete every line starting with a number in brackets. What is left should read like four short paragraphs and a question, with a blank line between each one, because a wall of text loses on mobile before it loses on merit.

The title carries more weight than the body. Two rules: it names the thing and the person it is for, and it contains no exclamation mark, no emoji, and no word you would find in a press release. "I built X because Y" works because Y is where the reader recognises themselves. A title that is only the product name plus a tagline gives a scrolling reader nothing to attach to. This is the same discipline that makes an app store subtitle work, and if your one liner is not settled yet, fix that before you post rather than in the thread.

Where should the link go?

Wherever the rules say, and no cleverness beyond that.

If the body allows links, put one link in the body, low down, after you have said what the thing cannot do. One. A post with a homepage link, a Product Hunt link, a Discord link and a newsletter link reads as a campaign, and it splits the attention of the handful of people who were actually going to click.

If links in the body are restricted, put it in your own first comment. This is normal and mods are fine with it. What is not fine is the pattern of writing a post that describes a product, refusing to name it, and asking people to DM you. Makers see that as a lead capture move, because it is one, and the top comment will say so.

Two things about the link itself matter more than its placement. First, it has to work on a phone, because most of the traffic is on a phone. Second, whatever is behind it has to be usable without a signup, or the trip was wasted. A signup wall between a curious redditor and your product converts a comment thread into nothing. If your app genuinely requires an account, link a hosted demo or a short screen recording instead. That single failure explains most of the launches covered in why nobody tries your app.

What question should you end on?

A question that a stranger can answer without installing anything.

"Would love your feedback!" is not a question. Neither is "what do you think?" Both put the work of deciding what to say on the reader, and the reader is scrolling. A good closing question has a narrow subject, assumes the reader has expertise you lack, and can be answered in a sentence from the bus.

Weak, and why:

• "Any feedback appreciated" - no subject.
• "Would you use this?" - invites a yes or no that tells you nothing and is usually a polite lie.
• "What features should I add next?" - asks a stranger to do product management for free.

Stronger, on the same project:

• "If you maintain an API other teams consume, what tells you today that a change is breaking?"
• "Is CI the right place for this check, or should it live in the pull request diff?"
• "Does anyone actually version their spec files, or is that a thing people say they do?"

Each of those is answerable by someone who never clicks your link, which is the point. Comments keep a post alive and visible; clicks do not. And the answers are worth more than the traffic, because they are the same conversations that turn a launch thread into a small group of people who will try the next version. That is the recruiting move described in how to get your first 100 people to try your app, and if you want structured testers rather than drive by opinions, a builder trade community like Favors.dev is a better fit than a launch post.

How do you respond when the feedback is harsh?

Assume you will get one comment that stings, because you probably will, and that how you answer it is read by everyone else in the thread.

The useful split is between a comment about the product and a comment about you. A comment about the product, however blunt, is free consulting. "This is just a wrapper around library X" deserves a straight answer: either it is and you say what you added on top, or it is not and you say what is different in one sentence. Do not argue about tone. The lurkers are judging whether you are a person who can take input, and that judgement decides whether they try the thing.

A comment about you is not feedback. Do not reply to it at all. Deleting your post because of one hostile comment is the reflex to resist, because the thread usually corrects itself and a removed post takes the good comments with it.

Three habits that hold up:

1. Reply to everyone, shortest first. Clearing the easy ones fast makes the thread look alive in the window where that matters.
2. When someone is right, say so in the first four words. "You are right, the cosmetic bucket is too noisy" earns more goodwill than a paragraph of context.
3. Do not promise a feature to end an argument. You will be held to it in the next post.

If the same objection appears three times, that is not harsh feedback, it is a finding. Write it down and put it in the "what it does not do yet" paragraph next time. Treating your own launch thread as a test session is exactly the loop in the beta tester checklist.

How often can you post the same project?

Far less often than you want to, and the honest limit is set by whether you have something new to say rather than by a clock.

Reposting the identical launch is the fastest way to a ban in a maker community. Posting again months later with a genuine milestone, a rewrite, a shutdown post mortem, a real number you can share, is normal and welcome. The test is simple: if the new post would be interesting to someone who read the first one, it is a new post. If the only change is the title, it is a repost.

A better use of the same hour is to post about something other than your project. Answer three questions in the subreddit where you actually know the answer. That is the participation the platform rules ask for, and it also means the next time you post a launch, your account is not a single domain wearing a hat.

When should you skip r/SideProject entirely?

Sometimes the right answer is not to post. Skip it if:

• There is nothing to try. A waitlist, a landing page, a Figma file. The community is for things people can open. Come back when they can.
• It is behind a hard paywall. Not "has a paid tier", but "cannot be evaluated without a card". You will get the removal or the pile on, and both are deserved.
• You cannot be at the keyboard for the next few hours. Posting and disappearing wastes the one launch you get in that community. Move it to a day when you can sit with it.
• Your audience is not there. A tool for dental practice managers is not going to find its people among makers, no matter how well the post is written. Generic maker communities are the wrong room for a vertical product, and the sequencing for that case is in the app launch checklist for solo developers.
• You are still one bug away. A launch thread finds your worst bug within the hour, in public. Fix the one you already know about first.

Frequently asked questions

Can I link my project directly in the post?

Usually yes, provided the post is not only a link. Check the subreddit's rules widget the day you post, because that permission varies by community and changes. When links in the body are restricted, put yours in your own first comment immediately after posting. Never make people ask you for the URL in DMs.

How many times can I post about one project?

Once per launch, then again only when there is a real reason: a significant rewrite, a milestone, a lessons learned write up. Reposting the same launch on a schedule is the behaviour that gets accounts banned rather than posts removed. If you want repeated visibility for one product, spread it across different communities and different formats instead of repeating yourself in one place.

Do screenshots help on Reddit?

Yes, and a short screen recording usually beats a screenshot. Most people will never click through, so anything that lets them evaluate the thing inside the feed increases both comments and clicks. Show the actual interface doing the actual job. A hero image with your logo on a gradient is not a screenshot and adds nothing.

What's the difference between r/SideProject and r/indiehackers?

Broadly, r/SideProject skews toward the artifact and r/indiehackers skews toward the business around it. A weekend tool with no revenue plan fits the first comfortably. Pricing questions, churn, first paying customer, positioning, land better in the second. The practical consequence is that the same project needs two different posts: one about what you built, one about what you learned trying to sell it. Copying a post from one to the other is visible, and it reads as broadcasting.

After the thread scrolls away

A Reddit thread has one good day. That is not a criticism of Reddit, it is what a feed is for. The comments are worth having and the traffic spike is real, but by the weekend the post is unreachable and the people who meant to come back cannot find you.

A showcase listing does not scroll away. Submit your app free and it stays browsable in the showcase with your link, your description and your screenshots, reviewed by a human, at no cost. The only requirement is that people can actually try it: free, freemium or a free trial, a working URL, a real product. There is a featured spot if you want position and a badge, and it is exactly that, a position and a badge, not a promise of traffic. The free listing is the one most makers should start with, and it is genuinely free.

Post the thread. Answer every comment. Then put the thing somewhere it can still be found in November.