Building Was Never the Bottleneck. But It Was Quietly Doing Three Other Jobs.
August 5, 2026
12 min read
Startup Strategy
August 5, 2026
12 min read
I read the top threads in r/SaaS and r/startups most weeks. Usually they are a grab bag — a launch, a churn post-mortem, someone's first $9. This week they were not. Three separate threads, from three completely different vantage points, turned out to be describing the same thing without any of them noticing.
A builder posted that he can ship anything and cannot find a single idea worth shipping. An employee posted that when a vendor brags about building something in a weekend, they hear a warning. And a consultant whose business is now rescuing vibe-coded products described watching a founder with eighty paying customers open his own app and click around to discover what it did when someone cancelled mid-month.
Read separately, those are an idea problem, a marketing problem, and a quality problem. Read together they are one problem, and it is not the one the comments sections landed on.
Here is what each one actually said, before I put any interpretation on it.
| Thread | Written by | Points | Comments |
|---|---|---|---|
| “I'm tired of the ‘I built this in a weekend with AI’ founders” | A buyer's employee | 306 | 102 |
| “I can build almost anything. I cannot find one SaaS idea worth building.” | A strong builder | 129 | 200 |
| “I can build anything. I have no idea how to get people to care.” | A shipped-but-silent founder | 84 | 108 |
| “The biggest problem with vibe coding isn't security” | A rescue consultant | 81 | 51 |
Two of those are the same sentence typed by two different people in two different subreddits on two different days: I can build anything. Nobody in either thread disputed it. The disagreement was entirely about what comes next, and the top comments split cleanly into “you have an idea problem” and “you have a distribution problem,” with a recurring third camp insisting that no, actually, building is still the hard part and anyone who says otherwise is bad at it.
All three camps are describing a symptom. The thing they share is more useful.
Building software used to be slow and expensive. Everyone agrees that was bad, and mostly it was. But slowness was doing three jobs beyond producing the software, and it was doing them invisibly, for free, whether you wanted it to or not.
It filtered your ideas. It signalled your maturity to buyers. And it taught you what your own product did.
AI removed the cost. It did not replace the three by-products. That is the whole shape of this week's complaints, and it is why the advice in the comments keeps missing — you cannot fix a missing by-product by working harder at the thing that used to produce it.
When a build cost you six months or ninety thousand dollars, you did not get to have thirty ideas. The cost did your selection for you. You picked the one you could defend to yourself at 2am, and the sheer weight of the commitment forced a level of scrutiny that felt like judgement but was mostly just fear.
Remove the cost and the forcing function goes with it. The builder in that thread described his loop precisely: brainstorm, land on something clever, discover ten companies already do it or nobody searches for it, build a quick version, realise he does not understand the users at all, repeat. He called the result a graveyard of half-built clever things. What is notable is that he diagnosed it correctly himself — he wrote that he is inventing ideas from his chair instead of stealing them from a problem he lives inside.
That is exactly right, and it is worth being precise about why. Building is the comfortable part. It has a definition of done, it produces visible progress, and nobody says no to you while you are doing it. Two hundred comments arrived to tell him to talk to customers, and he already knew. The reason founders hide in the build is not ignorance. It is that the build is the only part of the job that reliably rewards effort with output, and when it costs nothing you can hide there indefinitely.
The single sharpest comment in the thread reframed the search entirely. Do not build a problem inventory, it argued — build an annoyance inventory. Not “what is missing” but what people quietly tolerate and never mention, because it does not feel like a real problem. The 20 minutes of dread before a client review. The spreadsheet somebody rebuilds every Monday. Those never show up in a competitive analysis, because nothing is technically broken. They are where willingness to pay actually lives.
This is the one founders are least prepared for, because it inverted rather than disappeared.
Buyers never had a way to inspect your engineering. What they had was a proxy: half-built software looked half-built. Rough edges, missing states, an ugly settings page — those told you roughly how much work was left, and buyers read them fluently without ever articulating that they were doing it. The polish was the receipt for having survived the edge cases.
Now the finished-looking shell arrives on day one. The proxy broke, and the market did what markets do when a signal breaks: it substituted a cruder one. The 306-point post is that substitution stated out loud. The author, an employee who gets tools dropped in their lap and told to make them part of the job, listed what their company actually pays for — you were still there in month six, you did not lose our data, the thing did the same thing every time — and then delivered the line the whole thread agreed on: stop bragging about the speed, because to the people paying you it reads as a warning.
The honest caveat
A large fraction of the comments on that post accused it of being AI-generated engagement bait, and asked the author to name a single real product that had failed them. They may well be right. But that is not a reason to discount the thread — it is the same phenomenon one layer up. The reason the accusation lands is that polished-looking output no longer certifies effort anywhere, including in a Reddit post. The trust proxy broke for software and prose at the same time, for the same reason.
The practical consequence is that speed has stopped being a marketing asset and quietly become a liability you have to offset. Nothing about your launch copy should lead with how fast you built it. What buyers are now looking for is evidence of duration and consequence: how long you have been running, what happens when something breaks, who answers, whether their data survives a bad release. One founder in the thread offered a metric worth stealing — count how many support conversations are the same issue coming back a second time. Not ticket volume. Repeats. It is a ruthless read on which parts of your product are held together with tape, and it does not care how fast you shipped them.
The rescue-consultant thread is the most valuable of the four and got the least attention, which is usually how it goes.
The story: a founder brought in a booking product he had vibe-coded over a few weekends. It was genuinely good, polished, with around eighty paying customers. Then a customer asked what happens to the unused portion of a plan when you cancel mid-month, and the founder opened his own product and clicked around to find out. He was not embarrassed. As far as he was concerned, that is simply how you find out what your product does.
The consultant's framing of why this is different from technical debt is the part worth carrying around: debt assumes somebody can read the books. Here, the moment a customer disputes a number, the founder has to change behaviour he never understood, and no refactor closes that gap because the gap was never in the code. Commenters converged on calling it understanding debt.
The mechanism is worth stating carefully, because it is not “AI writes bad code.” The code was fine. What happened is that a decision got made and nobody knew a decision was being made. Somebody — something — had to decide what a mid-cycle cancellation does to a prorated balance. The model decided, confidently, in a way that looked plausible on screen, and the founder never saw a decision point at all. As the consultant put it in a follow-up: write the decisions down first, or the model makes them for you.
His diagnostic is the single most actionable thing in any of the four threads, and it takes about twenty minutes:
The five-questions test
Write down the five hardest questions a customer could ask about how your product behaves. Answer them without opening the app. The ones you cannot answer are the parts of the business you do not own yet.
One more detail from the same thread, from someone who has done several of these rescues: on billing there are usually three versions of the truth floating around — what is in the code, what is in Stripe, and whatever the founder has been telling people in support emails. Getting those three to agree is the rescue, most of the time. The code work afterwards is the easy bit.
The r/startups founder — product works, few users love it, no idea how to make anyone care — got 108 comments and most of them said the same three words: find twenty people. It is correct advice and it did not help, and the reason it did not help was named by one commenter with unusual precision: most founders cannot actually name who those twenty people are. Not the industry, not the persona. The specific situation that makes someone need this today rather than next quarter.
The difference between “ops people at SaaS companies” and “ops people who just hired their first SDR and realised they have no process” is the difference between a channel you can go find cold and a category you can only advertise into. Everything downstream — copy, channel, timing — is secondary to that.
There was also a good answer to the founder's real objection, which was that posting feels like performing and he does it badly. Two commenters, independently: stop broadcasting and start replying. Go where the problem gets discussed and answer questions, mostly ones with nothing to do with your product. Replying is not standing on a stage. And separately — ask the handful of people who already use your thing which thread, forum, Slack or subreddit they were in at the moment the problem annoyed them enough to go looking. That gives you three real places instead of a content strategy.
If the diagnosis is that three things you used to get for free now have to be purchased deliberately, then the work is to schedule each purchase. Concretely:
The comment sections spent the week arguing about whether the hard part is building, ideating, or selling. It is a bad argument because the answer keeps changing and it was never the interesting question. The interesting question is what a cost was silently paying for before it fell.
Six months of building used to buy you a filtered idea, a credible product, and a working mental model of your own business. You paid for one thing and received four. Now you pay for nothing and receive one, and the other three have to be acquired on purpose, by people who mostly do not know they are missing.
That is the actual founder skill in 2026. Not prompting, not shipping speed — noticing which of your old free by-products stopped arriving, and going and buying them back before a customer works out you never had them.
