3 Essential Lessons Learned From Building an App
On our journey of launching our first app, we made many mistakes but learned even more.
Cue the celebration music! Today, we — Mathias and Jan — officially released our first app. For the past six months, we’ve been working on our task management app on nights and weekends (honestly, mostly weekends).
There were days where we’d spend several hours on a single feature and plenty of weekends where we thought the app would be launched by the end of that month. Now, almost a year later, we’re finally done.
It all started with an idea: to build our first app. Since we had no app development experience and watching endless tutorials is pretty dull, we decided to follow the project-based learning approach right from the start. This meant going through the whole process, from design and implementation to launch, while learning the necessary skills on the go.
We had a goal, but one thing was missing: an idea of what to build. You might have a great idea for an app or an amazing skill to bring it to life, but if you don’t actually like it and if it isn’t helpful for your daily life, you’re not going to see it through.
Since time and productivity management are essential for us as students, we decided to build a task management app that embraces the timeboxing method.
Timeboxing means you define a fixed block of time for your tasks on a daily basis.
At that time, we were using Trello to keep track of our personal to-dos and plan our week. But we didn’t like the mobile experience and the lack of features in the free version of Trello. All the other to-do list apps weren’t quite what we were looking for either.
So, we chose to create Aikoa, an app that combines the timeboxing method with task management in a minimalistic app. Aikoa is Finnish for “purpose”. The purpose of the app is to store your tasks and notes in a minimalistic and non-distracting way with the possibility to plan the day using timeboxing.
Reaching our goal took us longer than expected. During our journey, we learned valuable lessons about app development and working together as friends.
Three lessons we learned
Starting is easy. Finishing is hard.
Having a clear goal in mind and being committed to learning a new skill provided us with the necessary motivation to start the project. Our Python and machine learning background were enough to quickly set up the development environment and write our first lines of code.
At first, we didn’t encounter any challenges. We made good progress, and let’s be honest, programming with immediate graphical feedback is far more rewarding than tweaking some machine learning models. This feeling of fast prototyping and the relative ease of basic functionality implementations kept us motivated for a while.
We spent a lot of time discussing UI/UX designs, colors, and white space ratios. The only thing we lost track of was the basic idea of what our app should do and what we actually need to achieve it: algorithms, business logic, database structure, and more.
For us, starting was easy, the motivation was right, and we began dreaming of building a beautiful, useful, and powerful task management app. That was precisely the point when reality hit us.
We designed and imagined features and workflows but underestimated what kind of complexities we would encounter implementing them. Additionally, we overestimated our app development skills after watching a handful of Youtube tutorials and creating our first customized buttons.
In terms of the Gartner Hype Cycle, we had reached the peak of inflated expectations and now hit rock bottom in the valley of disappointment. This was the most dangerous point for our project, and we thought about quitting several times. To overcome disillusionment, we needed to understand that an app project is much more than just a graphical interface.
So from our experience, this is the moment where you either quit or start learning. And by learning, we mean to solve the minor problems first, face more significant problems, start from scratch and rebuild the codebase several times.
In the beginning, we did not separate the UI, business logic, and back-end sufficiently, leading to hacky solutions and lots of dirty bug fixes. Reading about design patterns like Clean Code helped us to abstract our code. Even in this stage, the path of enlightenment, we thought about giving up more than once. This is only the tip of the iceberg.
Additionally, creating a website for advertisement, registration of websites, thinking about a fitting name, and all the other organizational and legal things we had to think about were obstacles on our way to finish what we had committed to. After all, this is why starting is easy, and finishing is so much harder than we imagined.
Dream big, but don’t do it.
Scrolling through the web searching for ideas for our app, we read tons of “start small and learn to crawl before you try to walk” suggestions. Most of them recommended building a generic checklist or quiz app. While we knew we wouldn’t create the next Instagram or TikTok, the idea of making a generic app that we wouldn’t use anyways wasn’t that motivating at all.
Building something that boosted our productivity inspired us right from the start. Therefore our brainstorming sessions resulted in a firework of ideas. We wanted to add time tracking, habit tracking, long-term goals, and much more. And to top it all of, we even thought about building a synchronized web app as well.
As you can imagine, most of our ideas were entirely out of scope for building our first app as a side project. We started focusing on cool features too early, leading to multiple features (recurring events, icon picker, …) we had to discard in later design iterations. No doubt this iteratively failing and adjusting taught us valuable lessons on how not to solve things.
In retrospect, it would have been much wiser to concentrate on nailing a few features first before getting lost in details. We experienced how crucial it is to acknowledge how much time you can spend on a side project. This brings us to the second part of the catchphrase: Don’t do it.
While we still believe it was right to pick a meaningful project, we should have discarded more ideas in the beginning. Although we have given a lot of thought to how we prioritize things, we have to admit that we worked on more inspiring features from our nice-to-have list before finishing the required ones.
Because of misjudgments and continually growing knowledge about app development, we restructured our requirements several times, and lots of our feature ideas turned out to be out of scope. Nevertheless, planning ahead helped us to reach our goal with small steps in the right direction without knowing the best approach in advance.
Don’t make it feel like work.
Did we think about quitting? Of course. Did we think about it more than once? Of course we did.
Sitting down after a workday programming or working on your master thesis to spend time on your side project is challenging. Especially when your primary work is demanding and requires a lot of brainpower, there is often not much willpower left. From our experience, forcing yourself to work on your side project will harm your overall mood, and you’ll feel burnt-out after a few weeks.
For us, the only solution to this problem was not to let the side project feel like work. Working together as a team helped us a lot. Although in the beginning we studied in different cities, Moscow and Taipei, regular Zoom sessions helped us to experience the positive effects of a team and made it feel like just catching up with a friend.
Since our final goal was to launch the app on Android and iOS, quitting was not an option, even on days when it felt more like work. We wanted to experience what happens when you launch yet another app to the millions of other apps in the app store.
Although the learning curve flattened towards the end of the project, we couldn’t quit because learning the necessary programming and technical skills wasn’t the only goal. But looking back, it’s crucial to set regular check-ins to call it quits if you decide it’s no longer worth the extra time and energy.
For our next project, we will probably put more importance on the skill and not the finished product. We will also formulate sub-goals that allow us to terminate the project early and still call it a success.
Conclusion
The journey showed us it’s more about getting started and completing a project than anything else. We are not experts in what we tried to do, neither will we be anytime soon, but learning from our mistakes put us in a better position to start our next project (whatever it will be).
It taught us to spend more time thinking about which problems to solve than how to solve them. If you’re going to spend your free time on a project for the next 6 months, challenge yourself: What do you really want to work on? Don’t commit too early. Find out what gives you the purpose to keep going.
It was only through writing that we deeply thought about the most important lessons for us. Reflecting on the journey and what we would do differently was probably as valuable as the project itself. Although the finished app is far from what we planned to achieve, it served its purpose for us. So here’s the fourth lesson that even we didn’t anticipate when we started writing:
Reflect, learn from it, and write an article.
In the next part, we will reflect on our learning related to programming with Flutter. Hope to see you there!
Links
AppStore
https://apps.apple.com/app/id1553344471
Google Play Store
https://play.google.com/store/apps/details?id=com.betasonly.aikoa
Website
Github
We open-sourced the code for the app, which you can check out in our GitHub repository: https://github.com/betasOnly/aikoa
