“So, you need a working app a month from now for a live test? Ok, let’s do this!” That’s loosely how our mobile developer Jan Růžička responded to a challenge from another colleague—the founder of our internal app Fandoor, which offers small and medium sports clubs a platform to engage and communicate with their fans.
We sat down with Jan and asked him about the process: How do you plan a project on such short notice? How do you decide on architecture and allocate resources? And what are the differences between Google Play (Android) and App Store (iOS)?
You can also listen to the whole episode of our Innovation Spotlight podcast on Spotify and Google Podcasts or Apple Podcasts.
Jan joined Applifting in 2022 and works primarily as a native Android, iOS, and Kotlin multiplatform developer while still studying. He already has four years of experience in Android development and a few projects with tight deadlines under his belt.
The starting shot: Planning the project
If you are on a tight schedule, there are several key factors you need to address. The “store” deadline, the budget—which also goes hand in hand with the feature list—and technology.
The store deadline is crucial from the business perspective—it’s when your app is publicly available for download. This deadline, however, is slightly different from the one the developer works with. You should allocate a week at minimum to address possible issues Apple or Google might have with your app since the approval itself can take up to two days. Of course, you can also get lucky and get approved in a few hours, but are you prepared to risk it?
Where Google Play and App Store differ
While it's common for both platforms to have longer initial reviews and faster subsequent reviews, there are some differences in the process.
Every time you submit a new version to the App Store, a real person reviews it on various devices and tests the basic functions and whether it looks good. On Google Play, it’s sometimes so fast that it’s probably done automatically.
Apple also has slightly more strict guidelines. For example, the Fandoor app had to be resubmitted because it was missing the option to delete the user account.
The feature list is another important factor. It’s mostly dictated by the deadline and the money, in that order. Even a million-dollar budget won’t guarantee you will make a full-fledged app in a week. You still need to prioritize and consider “must have” and “nice to have” features.
Platform or hardware-specific features in turn dictate the technology requirements. The big questions usually are: Do we need those features now? If not, is it possible that we will need them in the future?
The first turn: Choosing the right tools
With only one month and one dev working on the app, it was quite obvious we couldn’t go the native way. It would simply take too much time. So, we had to look at some multiplatform solutions and decide on the one we would use. In the end, the choice fell on a fairly new framework called Kotlin Multiplatform for three reasons:
- It allows you to share only parts of the logic. You can do the UI or specific screens natively to ensure they look appealing but share the networking logic, which is the same on both platforms. Then, the third question—will we ever need the hardware or platform-specific features—becomes moot.
- It’s more future-proof. The shared part of the code written in Kotlin is also native for Android development. So if we ever decide to rewrite it natively, we can do it with relatively little effort.
- The integration with platform-specific APIs is really easy compared to other solutions.
Obviously, as with every new framework, you will run into some issues but nothing you can’t hack your way around.
The race is on: Proceeding with the development
The best thing about being the only developer, or working in a really small team, is that you are basically in charge of everything and can proceed much faster. You don’t need to discuss the changes with a large team and explain them to your superiors.
The worst thing about it is that you have a lot of responsibility. You also run the risk of falling behind when you, or someone else, gets sick. That’s one thing you just have to accept.
According to our developer Jan, the benefits of working alone or in a smaller team still outweigh the negatives when you're doing a project like Fandoor with a tight deadline and a small budget.
The development process itself was pretty straightforward. We knew the core features we wanted to implement, specifically: registration, login, becoming a fan of a club, guessing the final result of a match, game schedule, and applying rewards. The most difficult part was getting it all working in time.
The finish line: Testing and release
When we were finishing the app, we toyed with the idea of not using testers. In the end, we did use them, and it proved to be the right decision. Usually, the core functionality works well because you spend a lot of time on it, but you tend to neglect little things. You just don’t notice them, but the users will, and it hurts the experience.
For example, in the very first version of Fandoor it was possible to register without a username—the app let you fill in just the email and password. Then you had a blank space in the app instead of your name. Having dedicated people who pull your app apart is really helpful for spotting these small mistakes and oversights.
The closing ceremony: What is our takeaway?
Building an MVP mobile app from scratch in a month is no small feat, but being the only developer on a project can be empowering—and more fun. You are in the driver’s seat and decide which way to go and what architecture or frameworks are going to be used.
It does come with several challenges, though. You have to be responsible, not afraid to put in the hours, and ideally make it your sole project and not multitask. Otherwise, it can get overwhelming pretty quickly. Last but not least, don’t neglect testing. It can uncover tiny slip-ups that ultimately hurt the user experience.
Still, we made it happen! From an idea into a fully working iOS and Android app in a month that was stress tested during an actual live match. Now, with hundreds of downloads, we are getting the first feedback from users and can iterate and keep improving the app—thanks to the heroic effort of Jan!
Listen to the whole episode of our Innovation Spotlight podcast on Spotify and Google Podcasts or Apple Podcasts.
