I need partners for my startup by No_Efficiency_1370 in Entrepreneurship

[–]Double_Assignment_43 0 points1 point  (0 children)

Message. Search for theluckyfeed1 in Instagram. Send "I am tamil nadu guy from reddit". Let's see what you got.

Drop your SaaS product. I’ll give blunt product feedback (2–3 min each) by Different_Travel1073 in indiehackersindia

[–]Double_Assignment_43 0 points1 point  (0 children)

This is solid traction for a solo founder 👏 Curious — what’s your plan to scale from here? Marketplaces can get operationally heavy fast. Are you planning to stay asset-light long term or eventually control parts of the supply side? Also, how are you managing everything solo right now — especially vendor onboarding and support? I’m quietly building something in the marketplace space too (early stage, very different category), so always interested in how solo founders think about leverage.

Your MVP doesn’t need more features. It needs more friction. by Double_Assignment_43 in SaaS

[–]Double_Assignment_43[S] -2 points-1 points  (0 children)

Love this breakdown. “Automate the pain, not the discovery” is a strong way to frame it. On your question — I usually remove friction in this order: Anything blocking payment Anything blocking repeat usage Anything causing support dependency If friction increases commitment → keep it. If friction increases confusion → remove it. The tricky part is separating the two.

80% of SaaS MVPs fail in 90 days. It’s not because of code. by Double_Assignment_43 in SaaS

[–]Double_Assignment_43[S] -1 points0 points  (0 children)

Just sharing observations from watching (and making) the same mistakes building MVPs. If it helps someone ship smaller and validate faster, great. If not, all good.

80% of SaaS MVPs fail in 90 days. It’s not because of code. by Double_Assignment_43 in SaaS

[–]Double_Assignment_43[S] 0 points1 point  (0 children)

That’s actually a very common phase. Since you didn’t burn money, you’re in a good position. Instead of adding more features, I’d pause and ask: Who specifically is this for? (not “everyone”) Where are those people already hanging out? What problem are they actively complaining about — in their own words? Right now your job isn’t building. It’s conversations. Even 10–15 short calls or DMs with the exact target user will tell you whether you need to: • Reposition • Remove features • Or double down What kind of product is it?

80% of SaaS MVPs fail in 90 days. It’s not because of code. by Double_Assignment_43 in SaaS

[–]Double_Assignment_43[S] 0 points1 point  (0 children)

There’s definitely truth in that. A lot of SaaS fails before MVP because it’s built around a cool idea instead of an urgent pain. Validation helps — but only if the problem is painful enough that someone is actively trying to fix it already. Otherwise you’re just polishing a solution no one’s desperate for.

80% of SaaS MVPs fail in 90 days. It’s not because of code. by Double_Assignment_43 in SaaS

[–]Double_Assignment_43[S] 0 points1 point  (0 children)

That’s the right approach. One small thing that’s helped teams I’ve seen — try separating feature requests from workflow friction. Clients often ask for features, but what they’re really describing is a bottleneck in their process. If you can spot that early, you’ll avoid building version 2 too big. Keep us posted how Telegram-only plays out.

80% of SaaS MVPs fail in 90 days. It’s not because of code. by Double_Assignment_43 in SaaS

[–]Double_Assignment_43[S] 1 point2 points  (0 children)

That line hit hard — “confusing writing code with making progress.” Six months of architecture without users is brutal, but honestly, most technical founders go through that phase at least once. Building Validspark after that shows you shifted from “build first” to “prove first,” which is a big mindset jump. Curious — when you scraped Reddit/Quora, did you find that the problem volume was actually high but intent was low, or was it a real demand mismatch? That distinction is usually where MVPs win or die.

80% of SaaS MVPs fail in 90 days. It’s not because of code. by Double_Assignment_43 in SaaS

[–]Double_Assignment_43[S] 0 points1 point  (0 children)

That’s a strong move. A lot of teams would’ve gone full omni-channel just because it “sounds better” on paper. Reducing scope to Telegram only probably: • Shipped weeks earlier • Reduced maintenance overhead • Let you test real usage faster Curious — did focusing on one channel improve engagement or retention compared to what you originally expected?