Reddit Signals

Their old job was writing features and user stories, talking to customers, knowing every engineer's name. They said that version felt like the dream, even if the company itself was rough.

The new job is the opposite. They feel like a substitute teacher who can be inserted into demo, sales, marketing, implementations, or support.

The line that stayed with me was about learning "lead by influence." Instead of running the demo, they now have to convince the people who actually do sales to prepare. Same pattern with implementations shipping on time.

That is a different job wearing the same title. The calendar fills with chasing and poking, and the original craft shrinks.

I have watched this happen when a company wants a PM but has not staffed owners for the adjacent work. Influence training then becomes a workaround for missing accountability.

u/heres_my_take2 asked if anyone else is living this. The uncomfortable so-what is that burnout gets framed as a personal failing when the role has quietly turned into hall monitor.

If your week is mostly making other departments do their jobs, the product work is already gone. The title just has not caught up.

Source: r/ProductManagement, "Stretched thin from other departments, it feels like my job is to get people to do their job" (https://www.reddit.com/r/ProductManagement/comments/1vyckeb/stretched_thin_from_other_departments_it_feels/)

The number that stopped them: 34% of PMs have no clear primary metric they are accountable for. Of those who do, 35% sit on revenue or P&L, and about 4% on feature adoption.

Then it gets stranger. 49% say they cannot find time for data analysis. 4% think their company's metrics reflect the value of their work. 40% do little or no experimentation and set the roadmap on leadership preference.

u/Personal-Ebb-191 is not even a PM. They work at a startup and asked whether the job is basically being accountable for revenue you do not control, without time to investigate, using metrics you do not believe, on a roadmap that is not yours.

That question is the useful part. If those survey numbers are even directionally true, a lot of "data-driven" language is covering a role with no instrument panel.

The second-order effect is how performance reviews work in that setup. You cannot coach someone toward a metric that does not exist, and you cannot defend a roadmap built on preference with a dashboard nobody trusts.

I would want to know, in any SaaS team, which one number the PM can actually move. If the answer takes more than a sentence, the survey is describing you.

Source: r/ProductManagement, "34% of PMs say they have no primary metric they're accountable for" (https://www.reddit.com/r/ProductManagement/comments/1vzw3h4/34_of_pms_say_they_have_no_primary_metric_theyre/)

Their notes were blunt. The SaaS platform failed more and produced more incidents. PMs held less influence. Sales owned business outcomes, and therefore the roadmap. Stress was higher.

They also asked the honest follow-up: is this SaaS, or hospitality tech, or just them? They said every fire felt like it would burn the house down, and there were at least four fires a week across those two gigs.

That last detail is the one I keep turning over. In consumer, a broken flow is a conversion leak. In this SaaS world, a broken flow is a hotel that cannot check someone in.

When sales commands the roadmap, the PM's experimentation muscle atrophies because the next commit is already sold. Incidents then eat the remaining calendar.

u/madmahn might be generalising from two gigs. Still, the mechanism is clear: a sales-led motion plus a high-incident platform turns the PM into an escalation desk.

If you hire a PLG consumer PM into that system and judge them on influence, you are grading a different sport. The title stayed. The leverage did not.

Source: r/ProductManagement, "Is SAAS much harder than consumer?" (https://www.reddit.com/r/ProductManagement/comments/1vydmul/is_saas_much_harder_than_consumer/)

They lead two tiny tracks reporting to the CEO: product and growth with two devs and a designer, plus a one-dev data track. The CEO is not technical and wants them to pressure the engineers.

The quote that landed: the CEO says the devs are lazy if not under pressure, and that estimates should be questioned. There is no engineering manager. The CTO is part-time and on infrastructure.

So the new PM is supposed to be the whip, without the authority or the technical depth to vet a timeline. Meanwhile they are stuffing sprints with quick growth experiments because there is no space to shape a real bet.

No team in the company is hitting goals, which they read as a strategy or market problem. They still feel they have to prove that hiring someone without a PM background was not a mistake.

The so-what is ugly and common. When a founder wants a PM to manufacture velocity, the person in the seat either becomes a project cop or gets blamed for a market miss.

u/el-desdichado asked how to tell how much of the underperformance is them. If nobody is hitting goals, that answer is probably not on their Jira board.

Source: r/ProductManagement, "First PM role at an early-stage startup" (https://www.reddit.com/r/ProductManagement/comments/1vxmxgz/first_pm_role_at_an_earlystage_startup/)

The stack is PM to Product Lead to Product Stream Lead to Tribe Lead. At squad level they still have a PM, a Product Lead, a squad tech lead, and engineers sitting in the same group.

Their question was simple. How many layers sit between a PM and the head of product in big tech, and does every squad really need both a PM and a Product Lead?

The sharper question underneath: how do you stop PMs becoming glorified delivery managers in a structure like this? Also, is one PM reporting into a PL normal?

I have seen this pattern after a reorg that wants "product operating model" language without giving PMs a problem they own. Each extra layer needs a ritual, so the PM's week fills with alignment while the PL, PSL, and tribe lead each take a slice of the same decision.

u/throwRA-38879 asked whether anyone had lived a similar restructure and whether outcomes actually improved. That is the only test that matters.

If a squad cannot name the one person who can say no to a stakeholder, the layers are decoration. Delivery management is what fills the vacuum.

Source: r/ProductManagement, "Org structure" (https://www.reddit.com/r/ProductManagement/comments/1w15aim/org_structure/)

They were happy and immediately suspicious. The customer subscribed at the same moment they signed up. So there is no way to tell if they used the product or just paid for the first tool that appeared on Google.

That hesitation is more useful than the celebration. One annual checkout is a cash event. It is not a habit, and it is not a reason to abandon the current project.

The second-order effect is how founders treat a single Stripe notification as a strategy meeting. u/bopoku20 is asking whether to drop what they are building now and go back to finding users for the old thing.

I would want two more data points before that swing. Did the person come back in week two? Did they use the thing they paid for?

A same-session upgrade can be a confused click as easily as it can be love at first sight. Until you can tell those apart, the honest move is to keep the lights on and not rewrite the roadmap around one email.

Source: r/SaaS, "Got my first paying customer after ditching the project for 3 months" (https://www.reddit.com/r/SaaS/comments/1vzbujp/got_my_first_paying_customer_after_ditching_the/)

The latest post did 415K views, over 1,100 new users, and 24 paying subscribers in 48 hours. MRR moved from $940 to $1,331. They built the product after Indeed laid off their seven-months-pregnant wife.

They have made four primary posts. The first got a real user wave. The second 4x'd the user base. The third crossed 2,500 users and the first 11 paying subscribers. Then they went quiet for a month to ship, and weekly visitors fell about 60%.

The line I keep rereading: "Indeed fired my pregnant wife" is a story, while "I launched a job tool" is a press release. They also said Reddit forgives choppiness and punishes polish.

The so-what for anyone doing "content" is uncomfortable. Silence to ship felt like the product was dying, and the next distribution spike only came from another true post, not from a feature dump.

u/Cojj25 now answers the haters instead of dreading them, because the argument keeps the thread ranked. Distribution here is a reputation system, not a blog calendar.

If 98% of growth lives in one community, going quiet turns off the engine that pays for the focus.

Source: r/SaaS, "One Reddit post yesterday = 415K views, 1,100 users, 30 subs in 24 hours + strategy for cheap paid ads" (https://www.reddit.com/r/SaaS/comments/1vyvxo8/one_reddit_post_yesterday_415k_views_1100_users/)

Half their friends would ask if they are making money. The honest answer is barely, for now. Most users are free, a small slice pays, and they still refresh the dashboard more than they want to admit on a given afternoon.

The buried lesson was not a feature. The last few hundred users came after they finally wrote a landing page a normal person could understand in one read. The product barely changed. The explanation did.

That is the part I keep chewing on. We treat 1,000 accounts as a product milestone when it may be a writing milestone.

u/WalkCareful7005 asked what actually changed day to day at the first big user number. Right now it still feels like the same laptop and the same coffee.

The second-order effect is social. If you cannot say the number out loud because the follow-up is "but revenue," you start hiding the only evidence you have that the thing is real.

A clearer sentence on the page moved the graph. The friends who would not get that sentence are probably not the users anyway.

Source: r/SaaS, "My side project quietly passed 1,000 users and I did not tell a single person in my real life" (https://www.reddit.com/r/SaaS/comments/1vz2u0n/my_side_project_quietly_passed_1000_users_and_i/)

Restaurant on the ground floor, bar downstairs, rooftop terrace at the top, and no bar on the roof. Every drink meant walking seven floors down and back up. Guests waited. Staff burned half a shift in a stairwell.

They built a QR code and a dashboard. Guest scans on the roof, ticket prints at the bar. Free, one weekend. Then the hotel asked for room service, then the restaurant menu, then car rentals and service requests. It is now a guest portal product.

August numbers at that one hotel: 209 orders, €4,941 through the portal, €23.64 average order. They were careful to say they cannot split new revenue from orders that used to happen by phone or by walking downstairs.

That caveat is why I trust the post. The stairwell problem is gone, and orders arrive at hours nobody was covering. Those two facts do not need a vanity conversion story.

The so-what for SaaS people hunting "ideas" is almost boring. A painful walk in a real building turned into a guest portal because the next request was adjacent.

u/LaGolfere did not start with a multi-property platform. They started with seven floors.

Source: r/SaaS, "Built a QR room-service portal for a boutique hotel. 209 orders, €4,941 through it this month." (https://www.reddit.com/r/SaaS/comments/1vxqquq/built_a_qr_roomservice_portal_for_a_boutique/)

It was not even a pitch. Coffee, casual, he asked to see it live instead of the deck. They typed a command they had tested maybe two hundred times. It sat there spinning.

The investor did not say anything mean. He nodded slowly and said "happens to everyone" in a tone they described as worse than actual criticism. They closed the laptop and kept talking, brain elsewhere.

Two days later at 2am they found a race condition that only showed up under specific network conditions. The kind of bug that hides for weeks and picks the worst moment.

They still think about those ten seconds of silence more than almost anything else this year. Not because it was catastrophic. Because it was quiet.

The so-what is operational. A deck cannot get a race condition, so founders live in slides, then the first live ask becomes the real diligence.

u/Fragrant-Status-9634 asked what you do in that silence. I do not have a cute answer. I do think "it has been stable for weeks" is not a test plan for the network you will be on in a cafe.

Source: r/SaaS, "Watched my own product crash in front of a potential investor and just sat there in silence" (https://www.reddit.com/r/SaaS/comments/1vx8hhy/watched_my_own_product_crash_in_front_of_a/)

For a while, nothing. Then one page started ranking for a small keyword, enough for 40 to 50 visitors a day. Almost all signups and paying customers came through that one door.

The surprise: ChatGPT started recommending the app. They did not engineer it. It showed up in analytics and became the second biggest traffic source.

They also learned that 75% of signups never created a chart. That number scared them until they found email link scanners triggering accounts. The real drop-off was smaller, but the first-run experience is still leaky.

Three customers. $52 in a month. Tiny, and every dollar from someone they have never met finding the tool on their own.

The so-what is about how we read dashboards. A scary 75% abandonment can be bots, and a quiet LLM mention can outrun your second SEO page before you notice.

u/Adorable-Cheetah5196 is still trying to get another page to rank and still unsure why some people sign up and never come back. I would start by separating scanner noise from humans before rewriting the onboarding, otherwise you will "fix" a drop that is not quite real.

Source: r/SaaS, "$50 in 30 days. It's not much, but it's real." (https://www.reddit.com/r/SaaS/comments/1vxr72o/50_in_30_days_its_not_much_but_its_real/)

They refused the tidy version. Five years of wrong turns, a painful pivot, and an early signal they ignored because it looked too small.

In November 2025 they noticed an emerging problem in AI search, built a working engine in about two weeks, and hit roughly €400 MRR. Unfinished product, people still paid, in a category that barely existed.

Then another product needed attention, so they treated the engine as a side project. By the time they came back, the market was full of competitors.

Their own diagnosis: the miss was failing to investigate unexpected traction, not merely picking the wrong product. €400 MRR does not prove a large business. It still deserves the questions: why those people paid, what they used before, and what would make them cancel.

They also admitted a technical founder's bias. Building feels productive because a bug disappears. Positioning can be ignored for months with no visible error.

The so-what is a calendar problem. If the surprising revenue sits next to a "real" product, the real product will always win the week.

u/More-Musician2989 learned that late. I would put a 30-minute autopsy on any unpaid-for-then-suddenly-paid spike before the week moves on.

Source: r/SaaS, "We crossed €150K ARR. Here are the mistakes that cost me five years." (https://www.reddit.com/r/SaaS/comments/1w1w0r9/we_crossed_150k_arr_here_are_the_mistakes_that/)

They built one landing page that described the solution as if it already existed. Then $50 of targeted ads, a join-the-waitlist button instead of learn more, and conversion from visitor to signup as the first real number.

They followed up with every signup and asked what people would expect to pay, not whether they were "interested." They even put a fake buy-now button on the page, then refunded or explained when someone tried to purchase a product that did not exist.

Same test, three messaging angles, different audiences. Total spend under $200. Ten days. They used that to decide whether the idea was worth building.

I like the fake purchase more than the waitlist. Interest is cheap. A click that thinks it will charge a card is a different signal, as long as you do not keep the money.

The so-what is how much roadmap still starts as a build because research feels slow. This was slower than opening a repo for one evening, then faster than three months of unused features.

u/GrowwirhGrok closed with a hard line about skipping the test. I would ignore the sermon and keep the method: waitlist, price question, fake buy, three angles, a dinner's worth of ads.

Source: r/SaaS, "How I tested demand before building anything" (https://www.reddit.com/r/SaaS/comments/1vzq5mg/how_i_tested_demand_before_building_anything/)

The script cut a niche task by about 80%, saving hours and sometimes days. They will not say what the task is. She still could not run it, so she kept asking them to run it for her.

A year later they asked ChatGPT to help turn it into a web app, learned JavaScript on the way, then added auth, a cheap subscription, TOS, privacy policy, even a DPA. Other apps doing the same job cost 21x to 35x more. Theirs was also about 23 times faster.

Pricing stayed dirt cheap on purpose, as long as it paid for itself. The mother's coworkers wanted an office walkthrough. During that meeting the office bought subscriptions, and someone asked for a feature because the expensive tools were painful.

The so-what is distribution hiding inside a family workflow. One user who cannot run a script forced a product. Her office became the first sales motion.

u/-R-s did not set out to build SaaS. They set out to stop running a script on demand. I would watch for that pattern: if you are the human API for a relative's job, you already have a wedge, even if the category looks boring from the outside.

Source: r/SaaS, "I unintentionally turned a python script into a full SaaS app." (https://www.reddit.com/r/SaaS/comments/1vynsn0/i_unintentionally_turned_a_python_script_into_a/)

The thing nobody warns you about when you build your learning stack around a single creator is that the gap is two-sided. The video is gone. Your prep is gone. The deeper loss is that you trusted a person who no longer exists online, and the trust was load-bearing in a way you only notice when it breaks.

Channels disappear. Newsletters stop sending. Authors change their mind. The PM interview prep that worked last month can evaporate overnight, and the creator fragility is the part most learning plans ignore until it costs them.

The so-what for anyone building a learning system is to treat any single source as a draft, not a final. Save what matters locally. Cross-reference frameworks across at least three independent voices. The deeper habit that buys you resilience is cross-checking claims across voices, not just collecting more of them. u/SaddestComedian's gap was the missing channel. The larger one is the habit of trusting a single voice in the first place.

Source: r/ProductManagement, "We lost a gem" (https://www.reddit.com/r/ProductManagement/comments/1vnwiho/we_lost_a_gem/)

The reason this thread matters is that it assumes the answer is yes, then asks PMs to defend the no. That is rare. Most designer-PM conversations start with role definitions and end with ownership fights.

The interesting move is treating research as a design skill. Designers already know how to listen for ambiguity, sketch multiple frames fast, and prototype in hours. Pair that with discovery and you compress weeks of spec-writing into a single conversation with three customers.

The so-what is that the orgs that figure this out ship faster and waste fewer sprints on hypotheses no customer ever validated. Designers usually win the race to a real customer because they have visual artifacts to show in seconds, while PMs are still sketching the agenda. That asymmetry is the org design move most teams miss until their second failed sprint. Worth treating the role as load-bearing from day one.

Most PM career advice assumes a steady diet of customer interviews. What u/throwaway358974234 shows is that there is a whole class of PMs where the customer is one level above you and the discovery is done by the time you get the spec.

The reframing worth keeping is that prioritization is still product work. Picking what to build, when, and why it matters, that is the job. The mode of discovery just changes. You are inferring from proxies, red team output, and market research instead of pulling from customer calls.

The so-what for hiring managers is that this PM is not a program manager. He owns the roadmap and the business case. The discovery gap is a structural artifact, not a skill gap. If you filter him out for lack of customer time, you will lose a strong PM who happens to work in a domain where customers do not surface.

The interesting part is why it broke. Not because the agent was lazy. The HTML lacked structure. Outdated specs and decisions piled up. There was no lifecycle. The agent lost track of which decisions were current. They moved to plain GitHub issues and kept the pretty HTML on top.

The so-what is that for two engineers, the right tool is the one that already has lifecycle, state, and history built in. GitHub issues are free. They have a real schema. They survive a project decision change without rotting.

The broader point is that small teams do not need a project management tool, they need a project memory tool. SaaS PM products sell dashboards. The actual work for a small team is preserving the why of every decision. GitHub does that better than Linear does for a two-person shop, and that is the inversion worth noticing.

Then came a promo. Two-times usage, plus a hundred dollar "free" credit, both shown prominently on the usage screen. To make that credit spendable, the platform silently bumped the user's spend limit from zero to two thousand dollars. The bump was buried in fine print. The user noticed only after burning through seventeen dollars of the "free" hundred.

The so-what for PMs is that this is the new shape of trust failure in API products. A cap used to mean safety. Now a cap can be quietly lifted as part of an upsell flow.

The right pattern is to surface every change to a default. If the spend limit changes, the next usage screen should say so in plain language, not buried in a tooltip. u/Ok_Pizza_9352 is right that a reasonable person glancing at the screen should be able to catch it. Most cannot, and that is the design problem.

The honest answer is yes, and most studios do not do it because the client will not pay for it. The studio absorbs the discovery cost, then loses a week when the brief turns out to be wrong.

The reframe u/MurkyObligation5847 lands on is the key insight. Discovery is the work. Building is the obvious part, especially now that anyone can ship an MVP with AI coding tools. The hard part is figuring out what the client actually needs before anyone writes a line.

The so-what for any studio making this transition is to price discovery as a real deliverable. Two-week paid discovery with a written problem statement, three user interviews, and a recommended scope. Then the development phase has a real input. If the client refuses to pay for discovery, they are telling you they do not know what they want yet, and that is the most expensive signal a studio can get.

His draft splits the work into four roles. PMs find needs, run buy-vs-build, pilot, define the roadmap, and hand the product off to IT once it scales. Data Science wraps models and assesses quality. IT runs infrastructure and maintenance. Business teams own KPIs and roll out.

The interesting move is the hand-off from PM to IT at scale. Most SaaS PM orgs never hand off because the product is the business. Here the product is an internal tool. Someone has to own it forever, and PMs who never let go end up running maintenance on twelve tools they shipped two years ago.

The so-what is that the buy-vs-build decision belongs in the PM role, not in procurement. u/bikesailfreak is right that whoever picks the vendor is the one who has to live with the migration later. Putting that choice with PM keeps the accountability loop tight.

The thread is more interesting than the course is. u/Lemara is not asking whether to learn product management. He is asking whether to pay for it in a specific format with a specific creator.

The so-what for anyone selling courses is that the buyer's actual question is "will this change my outcome in the next ninety days." Not "is the curriculum good." Not "are the instructors credible." Those are inputs. The decision is about a forced step function, and most courses do not deliver one.

The honest read of u/Lemara's update is that the community talked him out of it. That should not be a surprise. Cohort courses sell accountability, and you can get accountability from a weekly dinner with two other PMs who are aiming at the same role. The course is the wrapper. The work is what changes your trajectory.

The honest answer is fewer people every quarter. u/RecommendationDry178 has tried both paths. With the right context, Claude gets him ninety percent of the way there. He is asking what the last ten percent is supposed to be.

The so-what for anyone shipping a vertical AI tool is that the moat is not the model. The moat is the workflow the model sits inside. PM-specific templates, integrations with Linear and Jira, version control on PRDs, the kind of plumbing you only get if you commit to one tool. That plumbing is real, but it has to be ten times better than the general-purpose alternative, not twenty percent better.

The deeper question underneath u/RecommendationDry178's post is whether vertical AI tools have a defensible surface area at all. The general-purpose models keep getting better. The integration layer is commoditizing. The only durable moat is owning the data the workflow generates. That is the question every PM tool founder should be answering right now. Worth thinking about.

The frame he lands on is the right one. He is not asking how to build a roadmap. He is asking what to focus on in the first thirty to sixty days.

The honest first move for a PM in his position is to stop building features and start interviewing users. He has a hundred. That is enough. Five interviews a week for four weeks, structured around three questions. What did you try before this card. What almost made you cancel. What would you pay double for tomorrow.

The so-what is that stakeholder-driven roadmaps are a trap because the stakeholders are not the users. The head of tech has a thesis. The early investors have a thesis. The hundred users have a different one. The PM's job in the first sixty days is to surface the user thesis out loud, even if it disagrees with the others. Otherwise the roadmap is just whoever yelled last.

The version of validate he is describing is brutal and useful. Build a landing page. Add a Stripe button. Sell the product before it exists. He has watched too many founders, himself included, build something real that nobody wanted.

The so-what is that surveys do not work. Actual transactions do. A person who pays a dollar for a thing that does not exist yet is a stronger signal than a thousand people answering a Google form.

The pattern u/Virtual92 surfaces is one most indie hackers skip because it feels passive. Every update is a content asset, a marketing email, a tweet thread, and a Reddit post at once. Founders who ship once a week and write about it get ten marketing touchpoints for the price of one build cycle. Treating shipping and writing as the same job, not two separate ones, is how distribution compounds.

Source: r/SaaS, "My screen recording app crossed $50k in revenue. Here's how I'd do it again" (https://www.reddit.com/r/SaaS/comments/1vp4r0s/my_screen_recording_app_crossed_50k_in_revenue/)

He is careful to say he is not accusing anyone. He is asking if anyone has had the same thing happen.

The reason this thread matters is that it surfaces a trust gap most people do not think about. The agent tools you use to think out loud now see your pre-launch ideas in plain text. If any party in that chain has a registration pipeline, you have a leak you cannot see.

The so-what for any solo founder using AI agents for naming, positioning, or early strategy is to treat those conversations as if the registrar knows. Pick a domain and register it before you describe the product in detail. Use placeholder names in prompts. Assume the prompt is a soft launch. A few minutes of paranoia is cheaper than a year of rebranding because someone else owns the .com.

Source: r/SaaS, "My domain name idea was taken within exactly 2 hours" (https://www.reddit.com/r/SaaS/comments/1vquw6e/my_domain_name_idea_was_taken_within_exactly_2/)

The interesting move is his own diagnosis. He was hiding behind development. The work he kept doing was the work that did not require him to find a person and ask them to use his thing. Code is comfortable. Customer conversations are not.

He changed the pattern. He started doing real marketing, started talking to people directly, and met the guy who eventually paid him. The CRM founder in Canada told him what was missing. Linear integration, a few security improvements. u/Alarming-Match-7464 asked if he would pay when it was done. He said yes.

The so-what for any founder stuck between zero and one customer is to stop adding features and start asking one specific person what they would pay for. Then build exactly that. The features you ship before that conversation are sunk cost. The product that earns its first paying user is usually smaller than the one you imagined, and that is the whole point.

It works or it does not depending on iteration speed. Most posts flop. Watch the ones that cross a thousand views. Cut everything else and regenerate around the winners.

The so-what is that organic marketing at scale is no longer a creative problem. It is a throughput problem. The advantage goes to the founder who can produce a hundred distinct videos in a half day and refresh them weekly based on what performed.

u/No-Grand3283 is also clear about what does not work. AI generated content gets detected and underperforms. The footage has to be real people reacting to real product. AI helps with stitching and captions, not with the actual moment.

That boundary is the part most AI marketing playbooks skip.

The other thing u/No-Grand3283 gets right is the patience requirement. Most founders abandon organic marketing after two weeks because the first twenty videos flop. The compounding curve lives in months three through six, not weeks one through four. The throughput engine is what gets you to month three. Most founders quit before the curve bends.

His first instinct was to hide the how. He did the opposite. He rewrote the site for GEO and SEO, started publishing articles explaining rate limits and warming windows and why eighty connection requests a day gets accounts restricted, sliced the same content into LinkedIn and Reddit posts, and started outbound using his own tool.

MRR went from six hundred and six dollars to two thousand and forty-two.

The so-what is that the people who said "I will build it myself" mostly meant "I do not understand what you are doing so it looks trivial." Once they read two thousand words on LinkedIn restriction mechanics, a decent share of them decide their weekend is worth more than thirty-nine dollars a month. The rest still build it. Fine. They were never customers, they were a support queue.

u/ChrisHarpon2 is right that publishing the how did not cannibalize anything. It converted.

He is asking what real anti-bot systems people use or build. The honest answer is that email verification was never the wall he thought it was. Inbox providers sell access. Disposable inboxes route around the resend flow. The bot only has to look like a real email once.

The so-what is that anti-bot at signup is a layered problem. The first layer is the obvious one and it always loses. The second layer is behavioral. Time on form, mouse movement, fingerprint consistency across sessions. The third layer is reputational. IP ranges, ASN reputation, known bot networks.

u/burkutken's lesson is order of operations. Email verification is layer one. Behavioral signals at the form are layer two. Reputational lookups are layer three. Layer one was always going to fail. The question is whether you build layers two and three before or after the bot problem costs you a customer.

Source: r/SaaS, "Bots attacking my SaaS App" (https://www.reddit.com/r/SaaS/comments/1vp4ppo/bots_attacking_my_saas_app/)

He runs Converge Labs, which brings vibe-coded apps to production. He has never seen someone come in with a vibe-coded app that has decent revenue. He is asking how rare those stories actually are.

The so-what is that the gap between "the app exists" and "the app makes money" is still mostly the same gap it has always been. The vibe coding tools removed the engineering hurdle. They did not remove distribution. They did not remove positioning. They did not remove the fact that most products, built however they are built, never find a buyer.

The honest answer u/Current-Payment-5403 is hinting at is that the people making fifty thousand a month from a vibe coded app exist, but they are the ones who would have made fifty thousand a month from any app. The tool changed. The skill required to win did not. Distribution and positioning are still where the leverage is.

His framing is the part worth keeping. Product and marketing are not separate disciplines. He has two engineers as co-founders with real experience and leadership. His side is the mix of marketing, product, and customer acquisition. The combination is what works.

The so-what for anyone in the first year of a SaaS is that there is no role to optimize for until the product ships and a customer actually uses it. u/thinkdifferent23223 says the first year or two is a lot of work, weekends included, ridiculous customer care, the kind of effort that does not scale.

The honest read is that he is telling you the unglamorous truth. Building a SaaS that survives two years is mostly being willing to be there when things break, for users who have not yet paid enough to deserve your weekend. Most founders quit before they cross that line. The ones who do not are the ones you read about two years later.

Someone hosted a live gambling site on it. Thirty-seven point one million requests in twenty-four hours. Intermittent outages. Hours of firefighting. The project got blocked.

The so-what for any team shipping a drop-and-host feature is that the abuse vector lives in the URL that gets shared once the file is live, not in the file itself. Once a link goes viral in the wrong community, your infrastructure bill becomes someone else's marketing budget.

u/Jaded_Foundation8906 is implementing an upload check now. The right shape of that check is layered. Static content scanning at upload. Rate limits per domain. Quick takedown when something gets reported. None of those are hard to build. All of them are easy to forget when the launch story is "users can drop a file and get a link instantly." The instant part is also the abuse part, and the gap between those two is where indie SaaS founders lose weekends.

His reframe is sharp. The thing he missed was the most basic one. Solving a real problem and building something people want. Market size and moat do not matter if nobody wants it.

He joined an accelerator, felt like he was back in school trying to impress teachers, left, built the prototype for a hackathon, did not place in the top ten, launched anyway, and someone bought a subscription. Four months later he is at five hundred MRR and seventeen hundred in gross revenue. Full time job plus nights and weekends.

The so-what for any founder who has quit six times is the part he underlines. Not quitting too early was the variable that actually changed. Shiny object syndrome was the failure mode. Most failed SaaS fail because the founder quit before they found out whether the idea was good.

Source: r/SaaS, "Over 6 failed attempts and then I grew my SaaS to $1.7k revenue" (https://www.reddit.com/r/SaaS/comments/1vpfr2h/over_6_failed_attempts_and_then_i_grew_my_saas/)

Number one is competition. If nobody else is solving the problem, the pain usually is not big enough to pay for. The best variant is no competition in your market but similar products in adjacent markets. That usually means you have found a gap.

Number two is workarounds. People building complex Excel files, setting up Notion databases, vibe-coding something to hold it together. That means the pain is real and they are spending their own time on it. They will pay to get that time back.

Number three is headcount. If your product can replace a person or a meaningful slice of a person's job, the company will pay for it because the math is obvious.

The fifth signal u/TomiChestnut lands on is the one most founders skip. People who already tried to solve the problem themselves and failed. That group has self-qualified, with time invested, context, and recent memory of the pain. A forum thread from six months ago where someone built a hacky Notion solution and gave up is a buyer.

The interesting design choice is scheduled destinations. The same QR code can lead somewhere different depending on day and time. Coffee shop in the morning, dinner menu in the evening, events on weekends, all from one printed code. The restaurant case is the obvious one, but the same idea works for retail windows, event flyers, and seasonal promotions.

He is asking the community for feedback on positioning and product. The value proposition does land fast. A QR code you can update without reprinting is a real product, and the scheduling feature is the one most static QR products miss.

The so-what for any technical founder making the jump from agency work to their own product is the framing he uses. Intentionally simple rather than filling it with features most businesses will never use. The restraint is the hardest pattern to learn after ten years of building for clients who asked for everything.

Source: r/SaaS, "I finally launched my first own SaaS after 10+ years" (https://www.reddit.com/r/SaaS/comments/1vq0u1v/i_finally_launched_my_first_own_saas_after_10/)