Ups and Downs of A Side Project

Jeremy Greze

I started to work on my side project 4 years ago, in November 2018. At the time, I knew how to code websites, had experience in product, sales and marketing, and most of all I liked to read the posts of people talking about their side project. My goal was to experiment the full picture on my own, make a micro SaaS from scratch. I suppose I like learning by doing.

This post is about what I have learned.

Don't project too much from your experience

I worked as a Product Manager, so I know that solving users problems is the root of a product. For Sheet.chat, I wanted to solve a pretty simple problem that I had in my job. We use shared spreadsheets, Google Sheets, to organize our work, and we use Slack to communicate and collaborate. Combing the two, with for example change notifications happening in our important spreadsheets in a Slack channel, seems valuable to me. I created my side project to solve my own problem.

While building my product, I envisioned every single person of my current company being a user. I’ve learned later over the months that the real audience is different. I projected too much. The users of my side project are digital startups, but also teachers, garage owners, no-code freelancers. I figured out that my messaging and user interface were not really adapted to my users. It is too complex for a good number of them. One simple example: for the configuration of a spreadsheets, users are supposed to copy/paste the URL of the source spreadsheet, and this action that seemed obvious to me is not for a part of the audience.

Although I was prepared that my users would not be the one I expected, I was still surprised. I guess you just need to accept it and learn to know your audience.

Focus on a narrow product

We all read that it is easier to build a niche software product, an industry-specific software. Was I building a generic or niche product?

At first look, I was definitely on the side of a simple and integrated software. Sheet.chat solves a narrow problem between two services with 3 main features. Seems simple and integrated, right?

The thing is, as a coder, you will be more attracted by generic product. Generalizing is more elegant, and if, like me, you like to solve problems, you will want to try to figure out a bigger problem than your initial scope. Also, when building something simple, you will keep asking yourself "Is this product too simple? Too bare-bones? Would anyone pay for this?".

This happened to me as well as. Among the 3 big features of Sheet.chat, I really needed one (notifications) more than the 2 others (search and add) but took the decision to integrate them in the initial scope. It was not too much extra work and the problem they solve seems legitimate. Looking back, I think part of the reason was that I was too ashamed to launch a product that was too simple.

I had plenty of other ideas, for example I spent some time on generalization to integrate with other services such as Airtable or Salesforce. Which I never did at the end.

You need to stay focused. Write a few user stories, like 1 or 2 or 3, and start with them. You have probably two good reasons for this: you prefer a niche product, and you want to solve a not too wide problem because you have limited time. Side benefit : Your product will most likely have a better user experience than you would have if you were to build a generic product.

Spend some time organizing your code

On the coding side, I was worried enough that my project could fail (never be public) that I kept everything very simple. I've read so many stories of developers wasting their time into fine-tuning their code but ultimately their project never launch or don't get any user. At this point, I was determined to make it happen, to release it.

It took me 6 months to build a usable version and get my first user. Then, I improved it bit by bit with a little work every week or so. Onboarding messages, better integration with Slack, payment system, etc. Overall, it took me a year to get a product I was able to sell.

My stack is Python, using the Flask framework. I took this stack because that's the one I'm the most used to. It was a good decision. However, on the structure and organization, I believe I oversimplified it. I kept postponing the idea of organizing or structuring my project. My app.py file is today 1500 rows, my sheet.py 700 rows, and few other files of 100 lines.

Even though my code is good enough that it works, I feel that the project seriously needs a better structure and a better separation of concerns. This lack of organization is preventing the development of new functionalities.

If I had to start again, I'd spend more time from the beginning to organize a better structure for my project, or pick a more opinionated framework such as Django.

Find happiness in other things than revenue

Generating income, no matter how small, with your own project is very rewarding and satisfying.

My first sale was a joy, but most of all, I think it was a great relief to know that I could do it. I immediately bought a bottle of champagne (much more expensive than the first sale, obviously :) ). But that’s very ephemeral, you quickly forget and move to the next step.

In terms of income, my side project brings me little besides my salary: between 100 and 200 euros per month (MRR). Let's say it paid for my last MacBook.

You need to find something else than revenue to pursue. For me, I like the idea of building a product useful and actually used. What really pleases me is to receive thank you messages.

You may also want to focus on the outputs rather than on the outcomes. The process, the struggle, the day-to-day… you can try to see all that as the fun part. I find coding is also a satisfying activity. But coding is only a portion of the work building a micro-SaaS. Marketing, maintenance, support are also important. So pick wisely your side project depending on the tasks you are willing to have.

User onboarding is key

Onboarding is making it easy for new users to get started with your product and get to the point where they achieved value from it.

When a user signup, it means that your SaaS is probably solving one issue they have. But that's only half of the way. Users need to get up and running with your product, to actually solve their issue.

Having a clean, intuitive, and easy-to-use interface is definitely key here. I'm not a big fan of interactive product tours or in-app messaging, so I added in the first months a quick product walkthrough with 3 steps for all users (it goes away when the 3 steps are done). It really helped most of my users to actually do their first steps pretty quickly.

But there are tons of little edge cases that your users will fall into. What really helped me to improve the product is having a direct chat on the website and also session recording. I don't like the idea of invasion of privacy that this entails, but it has been a big change for me. Some users will encounter a block and never contact you; it's very difficult to detect.

Running some analytics will help you to have a global picture, such as the percentage of users that reach a certain point in the onboarding process. This is usually called a funnel analysis. Running your own SQL queries on your database is fine to get started. Otherwise, you can use an additional service for this.

Every small improvement you do to facilitate the onboarding of your users will be valuable in the long term. I didn't know it was that important. My advice is to start early and proactively with appropriate tooling. Of course, if you can discuss with your users, that's even better.

Accept waves

It is okay to have productive waves. I find myself doing 2 weeks of super productive work with shipping things and then suddenly my motivation drops for several months. I believe it is normal. You probably have also a main job, a family, social life, sport, etc. and you can't have a mental energy to do all of this at the same time. Play the long-term goal with your side project.

If I look back, I realize that it was every little step that got me there. The times when I've been able to work a whole day on it have been so rare. What counts 4 years later are the hours spent here and there, regularly.

It's never perfect, and that's OK

You’ll find your product never good enough. The marketing. The code. The logo. It can be the whole thing.

For example, I've not changed my homepage for the last 4 years. I'm ashamed of it. I want to change the screenshots, the text, add testimonials, tell a better story, but haven't figured the time yet.

On the side of the code, I had to convince myself already several times that a full rewrite is a bad idea. If I do this, it is like starting a new side project, with the risk of never ending. Instead, I do small iterations to improve real users problems.

So, I guess you need to learn to live with this feeling. Done is better than perfect.

Near future

Looking back, I can say that the initial goal was reached, as I learned a lot of new things and built something that is useful for a few people.

I haven't thought too much about the future of the project for now. I'd like to keep the product alive as long as it is useful for some of my users and the costs are low for me.

I don’t plan to develop it further. I'll keep the current functional scope. I prefer to focus on other things.