Background
Let me quickly introduce you to the first side project that I coded from the 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, so 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.
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, then it might be a good idea to gradually add tests, but on the other hand it might be hard to focus on adding tests instead of producing new features or fixing the bugs. I know that it sounds like the Product Manager you don’t want to work with, but your resources are most likely very limited.
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 the victim of our own perfectionism. Whether you are a backend focused dev and you are trying to create the most optimised 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.
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 crystalise and look at it 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 time.
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 to 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, 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 it 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
- 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