What I Learned in 120 Days of Indie Hacking

#devjournal #productivity #watercooler

Hi Devs, long time no see.

Around 120 days ago I started my journey as an indie hacker. I started building Cow Pilot, a task management app where every task has a due date. Since then I have learned a lot about coding and met a lot of great people.

Summary

find your schedule and work on it every day
talk to users, their feedback is invaluable
maintain your existing codebase, don't only add new features
plan new features properly
there is a great community of indie hackers online

Work on it Every Day

Building a product takes a lot of time and work. But if you want to succeed in building a product, you don't need to have a lot of spare time. All you need is discipline and a good schedule. I have a full-time job and two young children. The only time I can work on my project is when they sleep. That's either after they go to bed or before they wake up.

I used to work in the evening. But often I did not accomplish much, because I was too tired after a long day. Nowadays I wake up at 5 AM before everybody else. That gives me up to 2-3 hours to work on my projects. I am refreshed in the morning and cannot wait to get started. This time is much more productive than in the evening.

You can build a product even if you only have 1 hour or 30 minutes every day. The time compounds and before you know it you have written thousands of lines of code or written dozens of blog articles.

As Benjamin Franklin said:

Little strokes fell great oaks.

Talk to Your Users

When I started building Cow Pilot, I shared the initial version on Dev.to. I received a lot of helpful comments. You mentioned things I had not considered or bugs that I had not noticed.

The same thing happened after I released the app on Producthunt. The most valuable feedback came from users that told me that they like the idea, but would not switch from their current app (yet).

I have made it a practice since then to send an email to a random user from time to time. I just write something like

Hi, this is Marian. I hope you're having a great day. I just wanted to check in and see if you have any questions or remarks about Cow Pilot. Thank you so much for using my app.

It took me a long time to send the first email.

I felt so awkward writing it. I was so worried about finding the right words. But what was the worst that could happen? In the end, I just sent it. Everything is a learning experience. After all, when was the last time you wondered why a newsletter or email has strange wording? The second email was much easier than the first one.

It's important to maintain your existing codebase, not only to add new features

I have written a lot of code in this project. Sometimes it takes me a while to understand what I have written or I ask myself "Why did I make it so complicated?". I guess it means that I am growing as a developer.

Nowadays I try to comment my code as much as possible. I write down in plain English what I want to accomplish and what I had to consider at the time of writing. It helps me a lot when I come back a few weeks later.

It is easy to neglect proper formatting and commenting when trying to build as fast as possible. Releasing a new feature is more important to me than having a perfect folder structure. After all, I am the only person working on it. But as the codebase grows bigger it also becomes harder to find what I'm looking for. It is the perfect time to think about improving the codebase and make it more maintainable.

“If you are unable to understand the cause of a problem, it is impossible to solve it.” – Naoto Kan

Plan new features properly

Every new feature has countless angles, how it can affect existing code. I believe that too much planning can negatively affect your productivity, but so can not enough planning.

Let's look at an example: In February I added Projects to Cow Pilot.

What was on my list:

add selector in sidebar and in task modal
add new field in task on database
add new routes in backend to handle CRUD (create, read, -update, delete)
handle CRUD in frontend
handling tasks in bulk edit

What I did not plan in advance

handling tasks without projects
removing a task from a project
selecting multiple tasks to move them to a project, but some of them already are in that project
handling "undo" for one task and multiple tasks
etc.

In the beginning, I did not account for "negative" actions like removing a project. This led to a back and forth of fixing and testing. I would have been faster and the code would have been cleaner if I had taken it into account from the beginning.

The indie hackers community

There is a big community of indie hackers out there. Everybody is very supportive and they are very active on Twitter. There are also dedicated communities like Makerlog and IndieHackers.com.

I have met new interesting people and friends. A lot of them build in public, which means sharing their ongoing process of building their product. There is a lot to learn from their insights. The most valuable lessons come from mistakes they have made.

Conclusion

It has just been four months since I started working on this project. I have learned more in these four months than I could ever learn from any course or bootcamp. I have come very far already when I compare my MVP to where I am now. But I am far from finished.