This series will embark you in a journey through the creation of an app for at least Android and the web. The aim is to show you not only the technical aspects but also the strategies and the choices to enhance the probabilities of success.

I’m Joël a Senior software engineer, I’m mainly a full stack developer but tend to be more focused and expert on the backend.

When I talk about the success of an app, there are quite a few key indicators that can be covered. The popularity of an app could be one of the first indicators that comes to mind but this is not the only one. This is also not the one that will be covered the most in this series. Before becoming popular there are at least two keys that need to be tickled :

• Developing the project until a defined end and publishing it
• Operating the project

Developing the project until an end

This is somehow very obvious, thanks captain. If a project is not built until the end it’s gonna end up in the pile of ongoing projects that haven’t been updated for years. Every developer knows that too well 😉 How many better mail server that will revolutionize de universe or calendar app that will reshape the world are their in our pipelines ?

But we shouldn’t be too harsh on ourselves those projects have been helpful to help us gain experience and knowledge. They have been useful to get a job and earn a good living.

Nevertheless, this is essential to be realistic with the resources that we have when we start a new project. Even if we understand the key technical element of a project, for instance the SMTP protocol, it means that we can create a Proof of Concept that shows the communication between our dear little SMTP server and any clients. It’s great, we can be proud of ourselves. But it’s not yet a mature product with all the desired functionalities. It’s gonna take months or years, depending on the resources, to build all the required features. Let’s be true: we tend to underestimate the time a task is going to take.

To build a project until an end, it has to correlate with the resources we have. If you work alone like me, at that point, it’s not possible to be too ambitious. It’s better to set a goal that is achievable, even if it’s not going to change the course of history (yet!).

Operating the project

As soon as the project is done, it’s not over, it’s the beginning of a new journey: operating the project. It’s myth to believe that the project will just run by itself without intervention. The users will need some assistance, bugs will be discovered, the servers will need to be maintained, updated and scaled. All of these could lead to a nightmare if you don’t have the resources to address them. A vicious circle could take place and force you to shutdown the project completely.

This is very important to choose wisely from the get go the technologies, libraries, frameworks, tools and so on. Every piece of software that you may use can be very exiting at the beginning cause the “Getting started” of the documentation is very simple to follow and provide fantastic results but in the long run you’ll need to be an expert with almost every component of your splendid architecture.

Every component may require advanced configuration for production, adjustment to optimize the performance, constant monitoring, well though design to scale. I can already feel the pain and the sleepless nights 🙁

Choosing what is right

Meaning take the red pill !

During this series my aim is to build an app and set the right goals and choose appropriate technologies. It doesn’t mean that I’m 100% right and I’ll drop the mic with a 42 answer 😉

Those will be my choices based on my experience and preferences. Other options are also fine.

My attempt to try to develop a project until the end will be a simple app that won’t necessarily revolutionize de world. Other apps offer very similar features but with the resources that I have (me), the time I don’t have and the motivation as versatile as a plastic bag flying in the wind. I’ll introduce you to the requirement of this app in the next episode.

Here come the technologies !

As I’m doing this project alone, I can’t do everything from scratch it’s gonna be to wide and I won’t have the time. I have to find good shortcuts and reuse the wheel, an existing one, as is. Not a one that exists but would be super cool with a home made tire.

What often worries me as a developer is the operational part. How much time what technology to choose to just run my project in a cloud or any infrastructure as long as it works 99.999% of the time.

For this reason I decided to use a low/no code backend where the operational part will be mostly covered for me. As a backend developer it hurts a bit my feelings when I see all that I could do if I would do it myself but I know that at that point I don’t have the resources. In a near future, hopefully yes but not now.

The second reason to choose a low/no code backend is because most users are primarily focused on what they see on their screen and the feature the app offers. They don’t care at all about why event driven development and Kafka are a game changing or why functional programming will be the new standard. For now I want to focus more on the app itself rather than the backend. If my app works, I’ll be looking forward to developing a state of the art backend with more resources.

No more suspense ! I recently discovered Supabase. It offers a backend based on PostgreSQL with all the basics functionalities I need to start. I’ll cover much more about it in the next episodes.

For the app itself, I decided to use Dart/Flutter to create on that is compatible with Android, iOS, the desktops and the web. More will be said on that topic as well.