Decoding Failure: Insights from my failed startup

One of my startups, which had both a co-founder and CTO, failed after about a year of survival. After a few productive years, I think it's time to make an in-depth analysis that would be very helpful for the community. Yet the first person this analysis points to is me before the community, as I'm trying to embrace all the faults and learn from them.

What we're building?

I won't dive deep into the details of a startup, as we are currently working on a second iteration of it. On the surface, the product was a platform where technical students could complete some technical tasks to improve their knowledge and experience. You can think of it as a LeetCode-like platform, not only with algorithm tasks but also some projects as frontend mentors.

Unanticipated fail after investment and revenue.

I remember the day when I saw the first notification from my custom-built Slack payment notifier bot that made me feel very different, but happy. Yes, we were getting a small amount of revenue from customers. However, there are points to mention before revenue. Investment...

When we started working on this startup, we got approved by one of the valuable acceleration centers in Azerbaijan, which organized extremely important events, lectures, and many more during acceleration. All in all, we got some investment from the acceleration center itself after successfully completing and pitching in the final event. The money we got as an investment was a cure for the majority of our problems; hereby, we could invest some money in onboarding some mid-level members both in development and business teams.

We couldn't see the end of the tunnel at budget allocation.

As I said, the whole investment amount is planned and split between both teams for new employment, marketing, etc. We were trying to be highly precise and dedicated to what we wanted while making a multitude of interviews. After these exhausting interviews and the onboarding process, we could get started with new team members who were trying to take over and help us with the overwhelming stuff. What went wrong? We saw the bottom of the budget bucket. Yes, the money is finished. Did we move the needle relatively? No.

Unplanned products wasted our money on experiments.

We thought that we could now easily implement what we wanted since we had new team members. During these few happy months, we held a bunch of critical meetings — features, plan changes, more features, more changes, a bit more features. In the end, we had a really big product (the quality is debatable). But did we need that? Absolutely not. As a startup, we absolutely needed to stick with the core MVP, yet our product was bloated with a multitude of features that new users even couldn't get all of as the context of our project was significantly different and could not be used intuitively and freely. Though we are getting some small revenue, that was only enough for us to make lunch for a few days, not even with the whole team. Thus, we needed to go with the dismissals of most of the team members. After this enormous failure, we learned that we shouldn't waste our money on experiments but on core features. Well, we didn’t know that we were wasting money on experimenting, but we’re building our very important features. But after taking a deep breath from the overwhelming stuff, I saw that we actually spent on features that we called “optional” after a while. That’s why I named this situation experimenting.

Robust MVP matters

As mentioned above, now we have a few core team members again, as before our investment, but the product with more features, with the help of a strong junior front-end developer, just left the team. Yes, now we have a better product. Better? No, it's not the right word. We have large products that we users even lack in usage. Nevertheless, we could get some traction and new users, and they were really using and some of them were actually enjoying the product. But did the majority pay? No, the product was very buggy, and not everyone was sure to pay. After we saw that they were not paying, we tried to gather some feedback from active users. Based on that feedback, we dramatically understood that if we had built a very robust and real MVP without feature-bloated products, the product would have been noticeably successful. That was a very terrible way of experiencing the importance of the actual MVP.

Didn’t we know what an MVP is?

We knew what MVP was by the book. We didn’t fail at knowing what an MVP is, but planning required features that are limited to the MVP. In my eyes, it would be absolutely better if we invested money in a better product owner than a marketing person or even a front-end developer. During the work, that was not obvious to us, and we thought that we were sticking to the MVP limit, and these features are very critical for the users, yet our opinions changed after we needed to make a break from the project. Now it’s clearly seen that we failed at making initial plans for MVP.

Lessons Learned, Paths Forward

This question is kind of weird to answer directly—in short, both yes and no. For sure, I’m not happy that I failed at one of the projects to which I gave my priceless time and effort. But from another perspective, I learned very valuable lessons that I would call dramatic ones. If I were to list them below:

Spend more than is required for initial planning. There will always be new challenges to consider along the way, but it is better to have a broad view of your plans before starting. Stick with MVP, and hardly try to change the scope of it. Or you’ll find yourself in my situation. Heartbreaking lesson, but do not invest the whole investment amount in experimenting. Split money between core MVP features and A/B testing. It's better to decide if you need that feature before spending a noticeable amount of money on it.

It’s already been years since I worked on that project above, but I think it's worth mentioning cases. Hence, I wrote this article for myself and for those who could be in my position in the future. I have started applying the points I mentioned above to all my personal projects and have no regrets so far.

Writing is not easy, but planning to write more case studies and blogs from my experience.