Marketing on r/SaaS in 2026: Research, Evidence, and Discussion

A useful SaaS discussion starts with a decision another operator might face: where users abandon onboarding, what a pricing change revealed, or which support work should stay manual. Bring the evidence behind that decision and a question someone can answer without visiting your product. This guide helps you prepare that contribution, check whether it belongs on r/SaaS, and turn the response into a concrete next experiment.

Choose a SaaS operating question worth discussing

Use this workflow when you can contribute firsthand context to a SaaS problem or ask a bounded question about a real trade-off. Research existing discussions before drafting: note the buyer, company stage, workflow, and constraint behind the question. A solo founder choosing an onboarding sequence and an enterprise team managing procurement may use the same words but need different answers. If recent threads do not match your situation, shortlist a more relevant community before writing.

• 1Research: look for repeated descriptions of a problem, then record the workaround and why it falls short. A recurring complaint is a research lead, not proof of market demand.
• 2Contribute: explain an onboarding, support, pricing, or technical decision you actually made, including the option you rejected.
• 3Reconsider: a discount announcement, feature list, or request to visit your homepage gives readers little to discuss. Reframe around a real lesson only if you have one; usefulness alone does not grant promotion permission.

• Match a draft to a community with Post Subreddit Finder
• Research relevant communities with Find My Subreddits

Check the rules before choosing a format

Community rules can change. Read the official r/SaaS rules and pinned guidance immediately before contributing, then match your intended format to the current requirements. The checklist below helps you make that decision; it does not grant permission to promote a product or prescribe an account threshold.

• 1Record the review date, rule URL, relevant wording, and intended format: standalone post, existing discussion, or a designated thread if one is specified.
• 2Check product mentions, external links, disclosure of your relationship, title/flair requirements, and any restrictions on feedback requests or repeated updates.
• 3Use recent accepted posts to understand context, not to override written rules. An older promotional post is not evidence that your draft is permitted today.
• 4If guidance is unavailable or ambiguous, leave permission unresolved. Read and research first; ask moderators a specific question before publishing the uncertain content. Do not infer eligibility from account age or karma alone.

• Read the official r/SaaS rules
• Ask moderators about a specific draft

Build a topic from evidence you can share

Start with materials you already have permission to publish: an anonymized onboarding map, aggregate funnel counts, a support-category summary, or a technical decision log. Remove customer identifiers and confidential details. Select one topic below and bring its minimum evidence; if you do not have that evidence, write a question about your uncertainty instead of presenting a result.

• 1Onboarding friction: show the step users struggled with, the old and new path, and how you observed the issue. Ask which assumption you should test next, rather than claiming the redesign improved activation without a completed cohort.
• 2Paid conversion: state who was eligible, what counted as a trial and a paid account, the observation window, and any pricing or acquisition changes. Ask whether the experiment isolates the decision you care about.
• 3Build versus buy: compare required integrations, maintenance work, privacy constraints, and recurring cost. Explain why your chosen option fits your stage, not why every reader should use it.
• 4Support versus automation: group requests by task, describe one failed handoff, and show the proposed escalation rule. Ask where a human should remain in the loop.

Write a case study with a useful limitation

Use this five-part outline: context, intervention, observation, limitation, discussion question. Keep the observation narrower than the conclusion you would like to draw. Report raw counts alongside any rate, use comparable periods, and identify concurrent changes. A failed experiment can be worth discussing when readers can understand why it failed.

• 1Context: We build [type of SaaS] for [user and task]. At [specific step], we observed [documented behavior]. My role is [relationship to the product].
• 2Intervention: We changed [one part of the workflow] because [evidence or explicit hypothesis]. We left [important constraint] in place.
• 3Observation: During [dates], [count] of [eligible count] completed [defined action]. We measured this using [source]. If measurement is incomplete, say so.
• 4Limitation: The sample is [size], the cohort has [follow-up time], and [another change] may explain some of the difference. We cannot yet conclude [unsupported claim].
• 5Discussion: For teams facing [same constraint], what would you inspect or test before choosing [next decision]?
• 6Illustrative angle, not a customer case: a billing tool asks whether requiring a full data import before showing a sample invoice creates unnecessary setup work. The useful question is about the sequence, not whether readers like the product.

Answer the business problem before mentioning a product

Read the actual question and answer the constraint it contains. If someone asks why trial users stall, outline how to inspect the first-value step before suggesting software. If a product reference is relevant and allowed, disclose your relationship beside the mention and explain the fit and limitation. A request for advice is not consent to a sales message, a trial invitation, or a private follow-up.

• 1Example reply framework: I would separate setup completion from first value. Check [event] for [eligible cohort], then inspect [drop-off step]. That will tell you whether to test [specific change].
• 2If asked for a recommendation: describe the must-have capability and an alternative approach. Add your product only when it meets that requirement; identify yourself as its builder or team member.
• 3If challenged: clarify the evidence, acknowledge uncertainty, and correct an overstatement. If the reply is off-topic or unwelcome, stop pitching instead of adding another link.

• Adapt a helpful-answer and soft-recommendation template

Turn the discussion into an experiment log

After the discussion has had time to develop, record what changed your understanding. Distinguish a useful objection from buying intent: a founder explaining a workaround may be a valuable research conversation without being a qualified lead. Keep the public thread reference for context, but avoid copying personal profiles into a prospect list. Close the loop in the original thread when an update is relevant and permitted.

• 1Log: discussion/date → operating problem → contribution type → evidence or objection → proposed action → owner → review date.
• 2Illustrative log: onboarding discussion → importing data blocks the first useful screen → test a sample-data path → measure completion for the next eligible cohort. This is a proposed experiment, not a measured improvement.
• 3If feedback is contradictory, split it by use case before changing the product. If there is no response, revisit relevance, question clarity, and visibility before inferring there is no demand.
• 4Choose the next action: answer an unresolved question, run a small product test, research a different audience, or stop a weak angle. More posts are not automatically the right next step.

• Use the eight-metric weekly report
• Plan ongoing participation as a founder

Frequently Asked Questions