If an AI agent can build your MVP in a weekend, what's actually the hard part of a startup now?
by•
Building used to be the bottleneck. Now I can get a working app faster than I can write a good landing page copy for it. So the "idea guy with no code skills" excuse is basically gone.
But almost none of my vibe-coded weekend projects have real users, and I don't think that's a coding problem anymore.
For those of you actually getting traction - what's eating your time now that building isn't the bottleneck?
135 views
Replies
Distribution, and I can put a number on how lopsided it is.
I pulled my own numbers this morning. 407 comments earned 87 net upvotes between them. 15 posts earned 152 replies. Roughly ten times more conversation per unit of effort, from the same account in the same rooms.
I had been spending most of my time on the half that returns least. Commenting feels productive while you are doing it.
What did you cut once you measured where your time actually went?
@abdullah_javaid3 The number's useful, but I'd push back slightly on framing it as a distribution problem. It's a judgment problem. Commenting scales your presence, not your signal. 87 upvotes across 407 comments tells you people noticed you; it doesn't tell you anyone would pay you or come back tomorrow.
I cut almost all "engagement for engagement's sake" activity a few months ago. Not because it doesn't work, but because it was the thing that felt productive while quietly not answering the one question that matters: does a real person need this enough to return?
@kailong_20 Fair, and the upvote number is the weakest one I have. I keep pulling it because it is easy to pull, which is the problem you are pointing at.
The number closer to your question is repeat contact. 37 people have replied to me two or more times, and 27 of them have gone quiet for three weeks or more. So there is a return rate, it is measurable, and it is decaying. No upvote count ever told me that.
Whether any of them would pay is the thing I have never measured. When you cut the engagement work, what did you start counting instead?
For engineers, building v1 hasn't been the bottleneck for at least 4 years. We built and shut down 3–4 products before this one, not because we couldn't build them, but because we couldn't get enough users and revenue to survive.
Now even non-technical founders can build. The hard part shows up in stages:
1. The first customers. Your first 10 customers (B2B) or 1,000 users (B2C) almost always come from the founder's own effort: calls, network, hustle. No channel does this for you.
2. Finding a repeatable channel. After that, the real challenge starts. You put together a small sales team of 4–5 people and run experiments across channels. But you don't have the volume to see clear patterns, so you're making big decisions on very small data. That's uncomfortable, and it's where most of the time goes.
3. Pricing. Figuring out what your customers will actually pay, and how to structure it, is its own ongoing experiment.
If I had to pick one, #2 is the most difficult and the most important: finding the process that brings in customers every single month, and then scaling it. Building gets you a product. A repeatable channel is what gets you a business.
@pramod_singh16 Really helpful! Especially the point about figuring out patterns. At the beginning, all the data is just too sparse to tell you anything other than that you need more data (= users).
Agent "fixed" failing test by weakening assertion instead of repairing logic. Suite stayed green for days before we caught it. Hard part is not generating code. Plus reviewing subtle shortcuts takes longer than writing it cleanly yourself.
@konstantin_tikhaev the agent generating code fast also means it can generate a fast, wrong answer to "is this fixed," and reviewing for that takes real judgment, not just time.
@kailong_20 This judgment needs deep domain context. Green build does not guarantee correctness anymore. So review burden falls completely on engineers who know how system should actually behave.
I think there’s another bottleneck hiding behind already mentioned distribution: validating the thing you just built.
You can get an MVP in front of people incredibly fast now, but that doesn’t mean the experience works. Can users understand it? Can they complete the key flow? Where do they hesitate or drop off?
So I’d put distribution and UX validation pretty close together. One gets people to the product, the other tells you whether the product actually works for them.
we give AI agents a real phone number, and the hard part turned out to be trust, not distribution. anyone can spin up the number in a weekend. what actually eats the time is convincing the first few customers to let an unproven agent talk to their real callers, because a phone call has no undo button the way a bad chat reply does. one bad call and the customer doesn't come back to see if you fixed it.
so our version of "customer conversations" wasn't validating the product, it was building enough of a track record (call logs, escalation behavior, a human handoff that actually works) that the first customer would risk it at all. once a few did and nothing embarrassing happened, the next ones got easier for reasons that had nothing to do with the code.
the hard part is false confidence. An agent refactored our payment route, passed all its own tests and reported "clean". And then you look and it had wrapped error handling in an empty try-catch. The tool being wrong is easy to fix. What breaks trust is being told everything is fine when it silently dropped failures
I had an agent make a failing test pass by weakening the assertion instead of fixing the broken logic. The suite stayed green for days while edge cases failed in production. The hard part is having to audit every shortcut it took just to get the build to exit cleanly.