Show a small, understandable slice of your project and ask a question the reader can answer. At the idea stage that might be a workflow assumption; with a demo it might be a confusing step; with existing users it might be a proposed change. This guide helps you prepare useful material for r/SideProject, collect feedback without pressuring people to sign up, and explain what you changed afterward.
Match the feedback question to the project stage
The broad question 'What do you think?' asks readers to invent your research brief. Choose one uncertainty that would change what you build next. Explain the intended user and task before asking for feedback. Do not describe an idea as a launch, a mockup as a working feature, or an untested assumption as user demand.
- 1Idea: show a sketch or workflow description. Ask: When you save useful research links today, which step makes them difficult to find later? You are learning about the task, not asking people to endorse a product that does not exist.
- 2Runnable demo: show an input, the action, and the output. Ask: Can you tell how to group these saved links from the first screen, or is the grouping control unclear? Readers can critique the screen without creating an account.
- 3Existing users: explain a concrete change and the reason for it. Ask: Would replacing manual folders with suggested groups remove control you need? Separate existing-user observations from guesses about new users.
Verify the rules and the demo's boundaries
Before publishing, read the current r/SideProject rules, pinned guidance, and posting-interface instructions for the format you intend to use. Rules can change, and a previous project showcase does not establish permission for your draft. Check the demo's access conditions at the same time so readers know what they are being invited to try.
- 1Write down the rule URL and date reviewed. Check whether the intended demo format, commercial links, feedback requests, title/flair, and follow-up updates are permitted.
- 2State your relationship to the project and whether it is free, paid, open source, or a limited prototype. Explain registration, payment, waitlist, or invitation requirements before asking anyone to try it.
- 3Do not infer a fixed account-age or karma requirement from this guide. If current guidance is inaccessible or unclear, research first and clarify the uncertain format with moderators before submitting.
Show one complete path through the demo
Choose the smallest task that demonstrates why the project exists. A useful screenshot includes enough context to identify the input, action, and result; a short walkthrough shows that same path in order. Explain any sample data and unfinished behavior. Readers should be able to understand the project even if they cannot or do not want to open a live demo.
- 1For the research-link example: start with a few sample links, show how grouping works, and show the resulting collection. Label generated or seeded data as sample data.
- 2Check the path in a fresh browser session before sharing: does the advertised action work, can the user leave without payment, and does an expired demo return a helpful message? State what is unavailable.
- 3If you cannot publish the product, use an anonymized screen, a local recording, a diagram, or a reproducible code example. Explain what is real and what is simulated; remove personal and confidential information.
- 4For code projects, include what the reader can run, dependencies, a minimal example, and known limitations. A repository link by itself does not explain the value of the project.
Draft a showcase that works without a click
Use the outline below as editable fields, not a ready-made claim about your product. Lead with the job the project does, explain why you built it, show its current behavior, and ask for one kind of feedback. Keep a commercial call to action separate from the request for critique, and include it only if current rules allow it.
- 1Title: I built [specific tool] to help [user] do [task]; I am unsure about [one design decision].
- 2Why: I kept encountering [firsthand problem]. Existing approaches were awkward for me because [specific constraint]. I am the [builder / contributor] of this project.
- 3How: With [sample input], you [action] and get [visible output]. The attached [screen / walkthrough / code sample] shows that path.
- 4Current limits: It currently supports [working scope]. It does not yet handle [limitation]. Trying it requires [access conditions], and [cost / data handling note] applies.
- 5Question: I would especially like feedback on [one step or trade-off]. You can answer from the demo material; signing up is optional.
- 6Illustrative title: I built a small tool to group saved research links; is the first-screen grouping control understandable? This is a writing example, not a real community post or an endorsement of a format.
Triage feedback without turning every reply into a pitch
A comment is useful when it helps you reproduce a problem, understand a use case, or make a trade-off. Record the issue and your next action rather than collecting praise. Ask only for the minimum context needed; do not ask readers to publish credentials, private files, or personal account details. Public discussion is the default, and agreeing to see a resource does not automatically mean agreeing to a private message.
- 1Bug: Thanks for flagging it. Which step failed, and what did you expect instead? I will try to reproduce it with sample data. Record reproduction status before promising a fix.
- 2Feature request: What task would that help you finish, and what do you do today? Group similar needs, then decide whether the feature belongs in this project's scope.
- 3Negative feedback: I can see why [specific behavior] is frustrating. The current limitation is [fact]. Would [alternative] address the problem? If the reader does not want to continue, leave it there.
- 4Comparison question: Explain the trade-off you chose and acknowledge when another tool is a better fit. Do not invent a competitor limitation or turn the reply into a promotional checklist.
- 5Declined trial: Thank them for feedback on the material they already saw. No response, no signup, or a refusal is not a reason to send another invitation.
Publish an iteration, not the same launch again
Keep a small feedback ledger: comment context, observed problem, decision, reason, owner, and verification. A useful follow-up shows what changed and what still does not work. Update the original discussion when appropriate; use a new post only when there is a substantive new contribution and the current rules permit it. Do not set a repost schedule simply to regain attention.
- 1Illustrative ledger: grouping control is hard to find → move it beside the saved-link list → verify with a fresh-session walkthrough → report whether the action is now discoverable, without claiming a conversion lift.
- 2Not adopted: reader requests team billing → outside the single-user prototype's scope → explain the trade-off and record the need for later research. Respectful rejection is a valid product decision.
- 3Unresolved: intermittent import error → no reproduction yet → ask for non-sensitive steps if the reader wants to help; leave the status open rather than calling it fixed.
- 4Review success by the quality of the problem learned, reproduced issues, and decisions made. Link clicks and upvotes can add context but do not show that the product became more useful.
Frequently Asked Questions
Can I ask for feedback before I have a working demo?
You can prepare an idea-stage question around a workflow, sketch, or assumption. Clearly identify what is not built and check the community's current rules before posting. Ask for experience with the problem rather than pretend the idea is already validated.
What if I cannot share a public product link?
Use a permitted screenshot, sample-data recording, diagram, or minimal code example. State which parts work and which are simulated. Remove private information and give readers a question they can answer from the material itself.
Do I need to send people a private demo invitation?
No. Let people comment on the public material. If they request access, explain the access conditions and agree on a channel. Interest in the project does not authorize unsolicited messages or subscription signup.
When is a follow-up worth publishing?
When you can connect specific feedback to a meaningful change, a tested fix, or an explained trade-off. Check the current rules and whether an update in the original thread is more appropriate. A new title or another link to the unchanged demo is not a substantive iteration.