Sharing Lessons Learned as a Technical Solo-Founder

Hello everyone! I am Fabio, a data scientist who from Spring of 2021 has decided to follow his dream to become a successful indie hacker, starting a path certainly not without unexpected events and lessons learned.

I would like to share with you a retrospective I made after about six months of work and to know your lessons learned during your first projects if you want to share them. In a later post, I intend to organize them as food for thought for future founders.

Why I chose to start the first project as a technical solo-founder

Like other technical founders, I knew I was strong on software development (backend, frontend, infrastructure) and data science, while I knew I was weak on business modeling, design, and marketing.

It would have been best for my first project to look for a person who would dedicate his brainpower exclusively to these aspects, enhancing the time and skills of each person, thus maximizing the quality of the project and therefore its probability of success. Instead, I decided to take advantage of this opportunity to fill my gaps in business, design, and marketing, considering the first project more like a learning experience. My goal was therefore to get my hands on and acquire the basic skills that will allow me, in the future, to at least participate in business, design, and marketing discussions, following the advice of someone more experienced than me. I hope these initial efforts will pay off in the future. 🙂

What I built

• An API that categorizes texts with up to 900+ topics: EasyTagger.
• A website and a browser extension that automatically categorizes the articles you want to save in your reading list: EBLA.

Lessons learned

Here are some lessons learned after six months of this adventure, with the MVPs ready and on the verge of launching.

• Validate the idea before you start building an MVP.

  • It's ok to think about business model canvas and to identify the profiles of potential users, but I was wrong in not consulting them enough when defining the first MVP. I started my way and developed at least 50% more than I should.

• Start building an audience early to make your MVP known and tested once it's ready.

  • I did it too late and with the wrong channels. I should have started from the beginning of the project and put more brainpower into it, so I could talk to more potential users earlier and iterate on the product following their feedback.
  • Building an audience takes time and, above all, consistency. As a consequence, you need to start it before or at most during the early developments.

• Release the MVP early, let users try it, develop by solving their problems, iterate.

  • Treat your first users as shareholders of your project and solve their problems, to minimize the risk of creating something not useful.

• The right tech stack allows you to develop and test quickly.

  • This is an aspect on which I recognize that I have done well, as the speed of development has never been an issue and I could iterate fast on users' feedbacks. CICD helps a lot.

• Knowing how to organize your work well and keep yourself motivated is essential for the completion of a side project. I recommend Notion to keep track of all of this. It worked very well for me to:

  • Plan each evening the tasks to do for the next day.
  • Keep an up-to-date backlog.
  • Give myself wide-ranging deadlines for important events, such as user tests and product launches.
  • Do periodic retrospectives of what can be improved.

Let's share the lessons learned

I hope my experience will be useful to others. Remember to also mention what you have built! 😄