Let’s imagine you have a great startup idea for an online marketing tool. You’ve validated the market for it, you’ve pitched your product to many of your friends and it seems great, in theory. Your next step is to build a minimum viable product (MVP), but there are suddenly so many technical decisions to be made that just researching which of them even matter seems too time-consuming. Clearly, you just need to make sure that your project’s requirements are met and no features are skipped, and let a programmer decide any technical aspects, they must know better, right?
All developers will promote their prefered technology stack as the best choice for your project, their purpose is to sell you as much as possible, as fast as possible. You must also do your own, separate research, but the amount of knowledge needed feels overwhelming, with many technical buzzwords and details, if you’re not a software engineer.
In this article, we’ll shortly analyze the technical structure of a web/mobile MVP, we’ll detail our tech stack and explain our thought process when we chose it over the alternatives.
Why it’s important
Short term, it isn’t. But somewhere along the line, you might consider working with other programmers for various reasons. Or, at least, have the option to, so you can have some leverage for negotiating lower prices. If your product’s technology is too obscure, you’ll find it hard to replace the dev team. If it’s too old, the candidates are old seniors, which are also hard to find and don’t justify the cost. Young programmers are cheaper, easy to find and usually prefer new stuff, made for developing faster. New programming languages usually become popular only if they are better or faster than their predecessors with the same purpose. You want new, popular technologies.
What if you later decide you want to also launch a mobile app along your website? Having a website codebase which translates well into mobile highly reduces your app’s development time and costs, because your developers will be able to reuse already implemented and tested components. Facebook provides a great tech option for this: React is a tool for making websites, while React Native is a tool based on React for making mobile apps. Having cross platform tech not only ensures lower costs and faster dev, it also allows a programmer to easily transition between platforms, making your dev team more versatile and easier to replace.
A study by EPFL shows that 73% of start-ups must pivot to another market over time as their initial market did not provide the fertile ground for the product or service that the founders had hoped for. What happens with your project if, after some time, you decide to heavily modify its specifications? If the product’s tech and architecture are not versatile enough, it might cost and slow you down to the point where rewriting everything from scratch becomes more feasible.
Choosing a tech stack is the kind of issue that seems insignificant initially, but hurts more the more your project advances. The more complex your project becomes, the more it costs to migrate to other technologies, because most parts must be rewritten.
What defines a tech stack
There are 3 big, main components which will dictate your project’s tech stack. In short, whenever you send your best friend a text message:
- frontend lets you type and read the message,
- backend sends it to whom it’s destined,
- a database stores it so you can both read it later.
We’ll further analyse available options and choose a tech stack for our product.
It represents anything you visually see on your device. It defines the look and feel your app has.
WHAT ABOUT MOBILE ALTERNATIVES?
React allows us to easily port from web to React Native (iOS and Android) and vice versa. Most of the codebase is cross platform, with main differences on small components involving hardware functionalities, like accessing the phone’s video camera or getting its current GPS location. Maintenance will also be easy long term: fixing one bug on iOS will probably also fix it on Android and web, if it’s there. And React Native is also popular,currently being used by Facebook, Instagram, Bloomberg, Skype, Pinterest, Uber, Tesla, and the list goes on. So how does React Native compare to other alternatives?
- React Native has a proven production usage, being used by many tech giants, unlike Nativescript
- React Native is more popular
- NativeScript is backed by a small company, while React Native is made by Facebook.
Flutter’s first stable release (Flutter 1.0) was in December 2018. In comparison, React Native launched in 2013. A general rule of thumb is that cutting edge tech cuts you first. While we recommend using technologies which are new and popular, always research the team’s experience with said technology. If the framework has been recently released, chances are they’re still experimenting with it. Flutter might be a better alternative in the next few years, but currently, it’s not. It looks very promising, but it’s too new and Dart is too obscure.
- React native’s popularity is on the rise, while Xamarin’s is declining
If your product will never care about web, Xamarin is a strong alternative. If it does, however, React Native is a better long term solution.
You can’t see it, it’s under the hood, and it manages communication between devices, your database and other third party services. It’s responsible for stuff like push notifications, credit card payments, security, user sessions, password recovery, among others.
So how should you proceed on choosing this tech? It’s far easier, really. Most popular programming languages can be used for writing backend logic and also have tools with proven production usage to do so. And each of them has small advantages over specific use cases.
Because we’re using React/React Native with Node.js, most of our developers eventually became full stack, meaning they are able to develop both frontend and backend functionalities.
Apart from this advantage Node.js has in our scenario, as long as you choose something popular enough and your developers have experience in using it, you should be fine.
It saves relevant information for later use. Your users’ accounts (emails, profiles, photos), messages, and even this post, its likes and its comments are all stored on databases. If their sole purpose is reading and writing data, there must be not many choices and it shouldn’t even really matter which one you use as long as it works, right?
As of January 2019, there are 343 databases to choose from when starting a project. Each database is built around specific use cases and it differentiates in terms of performance, scalability and development time for the initial version and later project updates. Big software companies tend to use multiple databases for their products for maximizing performance. This approach is, however, an overkill if you’re not sitting on a goldmine, and the database’s performance only begins to matter once your startup reaches 10k simultaneous users or terrabytes of data.
So what should you look after when deciding on a database? I’ll shortly present our thought process behind choosing databases for our projects.
It’s a NoSQL, document based database. In short, unlike the older SQL relational models, MongoDB scales cheaper and is more flexible. It makes architectural and requirements changes easy to implement, and chances are you’ll request many revisions before entering the market.
According to db-engines, it’s the most popular NoSQL database, and it continues to grow. It’s beaten in popularity only by 4 SQL, relational databases, and that’s mainly because those 4 are much older and had more time to be integrated in products and university courses. MongoDB launched in 2009, while the 4 alternatives ahead of it in popularity were all launched between 1980–1995. MongoDB is currently used by Google, Facebook, Ebay, Adobe and Nokia, among others.
Ok, we get it, it’s popular. But how well does it synergize with your backend? Let’s say we’re using Node.js for our backend, a simple “node js mongodb packet” google search shows us that there exists an official MongoDB driver for Node.js, is downloaded 1.000.000 times per week and was last updated 4 days ago. This screams stability.
Chances are you’ll heavily modify or even pivot your product before it becomes successful, how well does MongoDB handle this? Incredibly well. MongoDB has a flexible schema, which makes schema migrations very easy. In example, if we want to add new properties to user accounts, like their phone number, their instagram pages and their monthly revenue, we can do so without having to update old users. In comparison, traditional relational databases require schema migration scripts for all users whenever you add new properties, rollback scripts must also be developed in case updates fail on production servers, all these scripts require maintenance and they can even result in downtime, when run. All this trouble is gone with MongoDB.
MongoDB provides you full control over your data and is also open-source, which means its original source code is made freely available and may be redistributed and modified. A more in depth, but simple to understand analysis of differences between MongoDB and other traditional relational databases can be found on their website.
GOOGLE’S FIREBASE DATABASE
Like MongoDB, it is a NoSQL document based database with a flexible schema. Unlike MongoDB, it’s not open-source, it’s paid, Google has full control over your data. You can’t even run it on your servers and you can’t use it without internet, Google hosts the database and only allows you to manipulate the data from it.
Okay, but with so many disadvantages over MongoDB, why would you ever use it? If you’re a small or medium startup, some of those points are also strong advantages, and Firebase is designed for your type of business. Yes, it’s hosted on their servers with their backend which you have no control over, but this also means you’re no longer required to implement a huge part of your backend. Google will also handle stuff like maintenance, scalability, uptime, DDOS attacks, encryption, to name a few.
Ok, but what about data privacy? One user is usually restricted access to other user’s data in the Backend. And what about more complex database functions, like sending welcome emails everytime an user registers on your website? You can’t do these on frontend, it’s a huge security issue! And you don’t have to. Firebase provides database security rules to ensure your users only have access to their data and cloud functions to run backend code in response to events triggered by Firebase features and online requests. And a list of more other products to go along with your database. They won’t completely get rid of your backend, but they can replace most of it.
One thing Google’s “Firebase Realtime Database” does very well is the simplicity of implementing realtime events on it, hence the “Realtime” from its name. You can develop realtime notifications or messaging with few lines of code. Because of this, a common practice is using MongoDB (or other database) for the majority of the project, while implementing push notifications and chat functionalities using Firebase.
Firebase’s database is only 48th in popularity according to the same ranking, but this is because it only addresses a more specific and smaller market than MongoDB. Big companies who afford to throw money around won’t rely and expose their data to Google, implementing their own solutions is a no-brainer. Projects not relying on internet requests also don’t work with Firebase, because you can’t run your own database. So Firebase is built specifically for small and medium companies with web and mobile apps.
Firebase is paid, unlike MongoDB, which is free. But heavily reducing your backend work saves a lot more money than what you pay, so Firebase’s prices are designed to justify using it.
It’s also not open source, but do you really care? Your product is not yet popular enough to justify modifying the database’s source code in order to optimize some very specific corner cases. That kind of efficiency is only relevant to huge workloads, like Google has.
There are many tech stacks available on the market, each brings their own advantages and disadvantages and some are more suited than others, depending on the project. This article’s sole purpose is to give non technical readers a better understanding of the thought process of choosing a tech stack for a new project, and which decisions can impact it in the long run.