7 lessons learned from my side project

Background

Let me quickly introduce you to the first side project that I coded from beginning to end and released in the AppStore and Play Store.

This is not an ad as it’s dedicated to one Polish city so most likely you won’t need it. While I was studying I used an app to check real bus/tram departure times (Google Maps wasn’t available in my city yet), but the app had some bugs, was bad looking, and only had an Android version.

I got interested in Flutter and saw the opportunity to get more into it and create something that I would most likely just use myself. That app is by no means complicated but I spent over 400 hours developing it, so like 10 weeks of full-time work. I had some long breaks, I had times when I wasn’t motivated, and where other stuff took my attention, the whole development process took over 2 and a half years. I reinvented the wheel a few times and switched the architecture in the middle of the process, but that was fine, I learned a lot and I want to share my mistakes and advice with you.

In the end, I learned a lot about Flutter, and it helped me tremendously to find a new job as a Flutter developer. So here are the lessons learned that I will applicate in all of my future side projects.

Keep it simple stupid

It’s probably the most important thing. As a programmer, it is really easy to get carried away and overengineer simple stuff, especially if you are a person that gets fixated on a problem. Of course, if the project goal is to learn new programming styles, then that advice might not be valid, but if you are trying to create a product, then you should focus on the simplest solution possible, as you most likely are the sole developer or at least have limited resources.

Identify the problem and choose the simplest and most effective solution for it that you fully understand. It will save you time and potential bugs.

You may not need any tests

Wait, what? Yes, you might not need them, at least in the beginning. Of course, it depends on the category of product. If someone could lose something of value or any harm could be done, then obviously you should do the TDD, but if you are only displaying the data from an API, then it should be fine. If you go live and are successful and plan to release more often, then it might be a good idea to gradually add tests because you will need to manually go through all test scenarios a lot more and you will waste more time on that.

Anyway, if you choose a framework/architecture/pattern and follow it properly, and if you are the only developer and you do not have to consider someone else’s code or do any rebases/merges, then the chance of a bug popping up is greatly reduced.

I am not saying that it’s a great idea to not have any tests, or that they do not help, but if you are really short on time then maybe it is fine to deliver an MVP without those.

Do not be a perfectionist

I think that a lot of us can be victims of our own perfectionism. Whether you are a backend focused dev and you are trying to create the most optimized solution for filtering data, or a frontend dev focused one trying to pixel perfect animations, you most likely do not need to perfect everything, as the end-user won’t appreciate it anyway. Don’t get me wrong, I get that in the short term it can be enjoyable and fulfilling and that you want your pet project to be perfect, but for sure it will slow you down without having a huge impact on an end product.

Also, it can have horrible long-term effects, where you do not progress your ideas regularly, and instead spend a lot of time on polishing small minor things, then you might get demotivated sooner, as you don’t see any real progress and you don’t feel like getting closer to the goal at all. Finally, the chance is that you still aren’t an expert in your field, or the tech is progressing rapidly, then if you come back to your project after say a year, everything you have done before will seem like poor quality or there might already be some better solutions established.

Noticing flaws in your product over time is great and means that you have made progress! While perfectionism is a great character trait, you have to control it.

Consistency is the key

I find that it is much better to code 7 times a week for one hour rather than 7 hours over a Saturday. Of course, both examples can seem over-exaggerated, it’s better to find a balance. What I mean is that a higher frequency promotes a lot of good things. You are constantly in the loop, you do not need to get back into the project or remind yourself of the thing you left a week ago. It also promotes tasks being split into more granular bits, and I think I don’t need to explain why this is a crucial skill as a dev.

Also, while we are speaking about side projects that are done after your 9–5 job, I find it easier to regularly squeeze shorter time spans into my daily plan, and it is also more realistic that I will in fact be productive during these shorter periods. Finally, a fresh look always helps. It is also worth noting that coding isn’t the only project-related thing you can and should do. When you don’t feel like doing anything technical, you can prepare the translations, think about the marketing, check the competition, split the work into smaller tasks etc.

If you are a person who works on their side project rarely, but for a long amount of time, try to split it into shorter blocks, you won’t regret it, trust me.

Be iterative

There is no need to release a complete product, start with MVP and validate your product and let it evolve based on users' feedback. I always split my project into 3 phases, MVP, post MVP, and “much later”. Start with the first one and then decide what to take from the next ones. The iterative approach does not have to mean features only. You can also iteratively improve UI and do stuff like adding support for other languages, once again, not everything needs to be perfect, at least not at the beginning.

Have realistic expectations

So there are a lot of things that don’t go as well as you plan. Have realistic expectations about the outcome of your project, let the idea sink in for a while, come back to it after some time, and if it still sounds exciting and useful, then do it. Let the ideas crystalize and look at them from different perspectives. If you want to learn something new, note down what it is and remind yourself from time to time. No matter what your ultimate goal is, it is always better to learn something new and treat everything else as an added benefit. A side project can mean worse performance, after all, usually, you are already after 8 hours of work and chances are that you have other responsibilities and hobbies, life, family, or gym, so do not expect to always be at 100% performance, and do not feel bad if you are not.

If you have a roadmap or simply only planned a deadline (I strongly recommend the first one), the chances are that you are going to postpone it, and probably multiple times.

Life happens, and there are periods of time you won’t be at your peak performance and availability, this is fine, really.

App release is just the beginning

You’ve put your app on the AppStore and now what? How will anyone stumble upon your app? If you rely on organic searches then you are either fooling yourself or an SEO ninja. The market is most likely super-saturated, so you need to have a plan for promoting your app unless you are targeting a niche. It would be wise to start creating promotion channels alongside the development. Build your own community, mailing list, produce quality content, build in public, whatever, but make sure you have it all planned.

It might be a good idea to check out paid promotions, but then make sure that you have sufficient knowledge or consult with a specialist, as it is easy to burn through the money on ineffective ads. Creation of the product is only a small step, you will then need to provide support for your product and sell it to others.

I often stumble upon a valuable but underrated and under-appreciated indie product, also upon shitty ones that were marketed well, which proves my point.

More tips and key takeaways

• What is the goal? Keep it in mind
• Be iterative
• It is better to work more often for shorter
• Write clean code the first time, not shitty stuff that needs refactoring later on.

You will not have the time or will to continue in future

• Always be 2 steps ahead and have the next step planned
• You will always learn something new

So that’s it, if you have more advice please leave a comment so we all can learn! If you enjoyed my content follow me on my socials. And if by any chance you like interval training, check out my app and article on how I made it. Android
iOs