On this page
I've been developing an app since February 2023, but it's never seen the light of the App Store. An idea sparked early in the year, and development began, but along the way, there were mistakes and some lessons I learned. Today, I want to share with you those mistakes and an indie developer mindset reflection.
I was still a student finishing my last year of the computer science master's program in Paris. I was still learning iOS development, architectures, and best practices. Previous freelance experience in iOS development gave me a lot of value and knowledge to develop and publish my app on the Apple Store.
Nonetheless, I was hesitant and sometimes frustrated not to have a day time to work on my side project. I have either the morning or the evening and the weekends, and I still have to take care of my health and personal relationships. It gave me limited time to work on those projects truly.
Moreover, I was taking time to build the perfect architecture and best practices for those apps. It was beneficial to acquire technical knowledge, for sure.
However, I know that something needs to change in my development process if I want to ship my apps and make them useful to people.
I hoped to develop apps that help people
I follow a lot of indie hackers and developers on Twitter (yes, it was still Twitter at that time), and it gives me a lot of inspiration to develop apps myself, too.
It was important as I wanted my apps to be useful for people and learn more about other business aspects like marketing, communication, ASO, etc... Also, I was trying to acquire technical knowledge as I was still learning advanced iOS concepts.
I was mixing goals into one, but I knew it would benefit me in the future and that I could reuse the learned concepts with my clients, for example.
That's true, but the goal is to develop an app that helps people begin falling into oblivion.
I was wrong about mixing those two objectives because one (learning new concepts) took advantage of the other (shipping apps that help people).
Ship first and develop after
I needed to work on the core feature of the app. I was creating secondary features that would be less valuable for the users. I was not sure if the user would need it. I lost a lot of time. We are at the end of the year, and the app just reached the App Store doors.
I asked myself, "Do I need to spend six months on a project before it sees the world?".
As you probably guess, the answer is "NO". Therefore, I changed my mindset.
"Don't give a f*ck about code quality, clean architectures, unit testing, and all that fancy technical stuff. The user doesn't see it".
All right, but if I let down the code quality to be faster, will it slow me down at some point? Will I be less efficient in developing features or fixing bugs? Will it impact the users as I will take more time to develop? From my own experience, I was sure that would be the case (but of course, it will depend on the complexity of your app and its core feature)
However, there is a middle point. First, we can go all in and not care about code quality to verify the technical feasibility and market fit. Once those two points are confirmed, we can start producing something technical solid to help us. Developers gain development time and scalability.
Of course, that depends on the level of effort I want to push through the apps, but sometimes, you only need one project that is well executed to win the game.
Shipping 10 apps working is better than shipping 1 app with fancy technical stuff
Initially, I would instead create something to find a product market fit. Therefore, it is something that sees the App Store quickly. I will not fall into the trap of technical eternal madness preventing me from shipping projects.
I will tell you about those experiments and what I learned soon.
