Your product is live.
You've shown it to a few people. Some said "this is really cool." A friend shared it in a group chat. You got a handful of signups — mostly people you know.
And now it's quiet.
You're not sure if the problem is the product, the pricing, the messaging, or just that you haven't found the right channel yet. So you open your backlog and start working on the next feature. Maybe that's the one that makes it click.
I've watched this pattern play out with almost every early-stage founder I mentor. Not because they're lazy or naive — but because building feels like progress. Talking to users feels like slowing down.
Vibe coding made this worse.
The friend problem
A friend of mine built an app. I'm exactly her target user. She sent me the link, and I tried it; it was beautifully designed. I gave her honest-sounding feedback — "really interesting idea, I can see this working."
I never opened it again.
Not because the UX was broken. Because building a new habit is hard, and I wasn't in enough pain to push through the friction. I didn't tell her that. I didn't want to hurt her.
This is the trap that was always there — people tell you what you want to hear, especially people who care about you. What's changed is that now founders can build something beautiful in a weekend, show it to ten friends, collect ten "this is great," and feel like they've validated something. They haven't. They've collected politeness.
What my mentee did instead of talking to users
I worked with a founder who had this exact situation. Enthusiastic friends, early signups, zero retention. The metrics were clear — people came once and never came back.
Instead of going to talk to those people, he went to his backlog. Maybe the app icon wasn't right. Maybe there were two features missing. Maybe the onboarding flow needed another screen. He spent six weeks optimizing things that weren't the problem.
The hardest moment in our work together wasn't identifying what was wrong. It was getting him to sit with what the numbers were already saying. People said they liked it. People didn't return. Those two facts can't both be true in the way he wanted them to be.
It took time for him to accept that "people like the idea" and "people have a problem painful enough to build a habit around" are completely different things.
The question I ask every founder
When a founder comes to me with "the product is ready, but it's not growing," my first question is always the same: Where did this idea come from, and who did you talk to before building it?
Almost always, the answer is some version of: I had this problem myself, it seemed important, I talked to a few people who agreed it was a real problem, and I built it.
That's not enough. And here's why:
- There's a version of customer discovery that feels like research but is actually just collecting agreement. You ask people, "Would you use something that solved X?" They say yes. You build X. They don't use it. People are very bad at predicting the future.
- The real signal isn't what people say in an interview. It's what they do with their money and their time right now, before your product exists. Are they paying for something that partially solves this problem? Are they building workarounds in spreadsheets? Are they complaining about it repeatedly to anyone who will listen?
If the answer to all of those is no — if people aren't spending anything, including time, on this problem today — that's already telling you something important. And no amount of "this is a great idea" from friends changes that signal.
What vibe coding changed — and what it didn't
For years, the barrier to building a startup was the build itself. Customer discovery and product development competed for time and attention, and that competition forced some natural slowing down.
Vibe coding collapsed the cost of building. A non-technical founder can go from idea to working prototype in a weekend. That's genuinely powerful, but it removed the last forcing function that made founders pause. When a prototype took three weeks, you had time to ask: Should I actually build this? When it takes two days, that question gets skipped.
The result is a new kind of failure that happens faster. Not a failed product — a ghost town. Something that looks real, maybe even works well, but has nobody in it.
When everyone can ship in a weekend, the question is no longer can you build it? It's do you understand the person you're building it for well enough to build something they'll come back to?
That question hasn't gotten easier. It's gotten easier to avoid.
So what to do?
The founders who are getting traction aren't the ones shipping the most. They're the ones who can describe one specific person — their job, their day, what they've already tried, why it didn't work — and build exactly for that person.
That knowledge doesn't come from a prototype; it comes from a conversation where you stop explaining your idea and start asking about their life.
One conversation that makes you uncomfortable — where you hear something you didn't expect — is worth more than twenty that confirm what you already think.
Before you open Lovable or Cursor, write down the one assumption you most need to be wrong about. Then go find someone who might prove it. Not to validate. To learn.
If you're in this place right now — something is built, traction is unclear, and you're not sure what question to ask next — I'd genuinely like to hear what you're working on.
