Mistakes I made that you should avoid as a founder 👇🏼
Sharath Kuruganty
10 replies
Hey PH community👋🏼 I wanted to share some news and lessons from a recent experience of mine that hopefully will help other founders/makers here.
After multiple pivots and not making much progress, I have decided to shut down Blubi AI 😔 Blubi started as a side project, where I wanted to tackle the writer's block problem using AI. For context, here's the announcement.
This is not the outcome I wanted, but it's best to move on and not spend too much on one thing!
Some mistakes I made that you should avoid as a founder and what I’m brewing next 👇🏼
1. Don’t commit to building complex solutions:
After getting a ton of feedback, Blubi quickly became complex. It all made sense in theory, but when building the actual solution, we realized it takes a ton of time - signing up for this makes you lose enormous momentum, which means losing interest from users.
2. Don’t spend too much on the waitlist:
Waitlists are cool, but IMO, they only work when there is sustainable hype - in my case, I lacked that. We had 1100+ people on the waitlist and we never leveraged them. My biggest advice is to spend a short time building hype by letting users in and gaining social proof from them.
3. Ship a simple MVP as fast as you can:
One of the biggest mistakes I made is that we never shipped an MVP when we had a decent one - partly I thought the MVP itself is not valuable. I guess this should come from users. Don’t leave anything for assumptions.
4. Validate with pricing from day one:
We would have saved so much time if we had a paywall with some pricing. This instantly validates whether we are building something people want. You don’t need many paid users. Just 1 or 2 are OK to get the ✅
5. No momentum = Your product is dead:
If you are not talking about your product from day 0, come to the conclusion that your product is dead. Momentum is the oxygen for any startup.
6. Pivot fast:
It’s good to talk to users but balance it out while building what you hear. Move fast and test in public - something I missed big time.
7. Avoid yeses that don’t convert:
Many people signaled that they wanted to become paying customers - while it feels good but in reality, they are either being nice or giving you hope. A complete transaction counts; everything else doesn't - we should have had a pricing page that clears things off.
8. Ideas are enticing, and execution is deal-breaking:
This is the trap and it's an easy one to fall in. Attach to building and detach from ideating.
What’s next for me: Learning from this experience, I want to build small products solving simple problems - and I’m working on one already 🚀 Stay tuned and follow me on X for more updates 🙌🏼 This time, I promise I won’t repeat any of these mistakes 💪🏼
Even after building and selling a SaaS product for 6 figures, I made easily avoidable mistakes.
I’m not perfect, and I’m still learning. I felt I could build a solution that solves writer's block but in reality, it didn’t work out.
I hope this helps. I'm here to answer any questions. I appreciate y'all for reading 🙏🏼❤️
Replies
Steve Lou@steve_lourdessamy
thanks for your insights! I find #7 hard because it gives you false positive signal and keeps you away from validating your hypotheses
Share
WebsitesToolz
@5harath thanks for these valuable learnings and pearls for any startup founder. I have been following you on twitter as well. I just did a launch for Websitestoolz on PH today after two years. After the first launch i got too caught up with the startup and lost out on networking with PH community. So i would like to add one mistake from my side, that startup founders must keep in touch with PH community even after successful launch :)
IXORD
Thanks for sharing, interesting read.
Thank you for the guide. Will take not of it.
Found this extremely valuable, so thank you for sharing your lessons.
Back SEO Marketing Software
Solving a simple problem is a step to solving a complex problem. Having an arsenal of tools that each solve a basic problem will make solving complex problems a lot easier. It's part of the foundation of object oriented programming, and every time I make a tool (usually personal tools), I learn a better way to solve that problem using code or a more organized way to solving that problem.
I learned the same thing when I was trying to get back into OOP, built a complex AI tool for auto generating articles with a finetuning and outputting them into websites, complete with outbound links, inbound links, proper formatting, etc. It was a mess and adding new components to it usually broke something. It worked, but wasn't user friendly at all, and became deprecated once GPT3.5 came out (though, I think I have a use-case for those fine-tunings now, going to have to look into a way to market those while I still can before Curie and Ada go away).
Since then I've gotten more into developing frameworks that don't intermingle everything in one file, and instead build classes that follow a certain pattern (initialize class, create UI components, do functions, handle errors), that way adding new things won't break old things. Code looks cleaner, and the opportunities for collaboration increase (can give people the framework to create a plugin vs giving them the entire source code).
Plus, I think a lot more people share a common small problem than complex problems. More people have the problem of "how can I write an article better" than "how can I build a complete website using AI that is properly SEO optimized while being user oriented". People in the latter group also have the problem of the first group, so building around that, solving that problem, then moving onto the next problem will be easier, and offer more opportunities for upsells.