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.
Frontend
It represents anything you visually see on your device. It defines the look and feel your app has.
We’ll start by choosing our programming language for developing websites. 95.1% of all websites are written in Javascript (at the time of this writing). It’s what most of the frontend developers are used to, so going for something more obscure will only make hiring a pain. It’s also the only supported language for all web browsers. Some new techs, like WebAssembly, are trying to solve this issue, but they’re still far from being as mature and widely used as Javascript. First launched in 1995, Javascript is the most popular language for websites for a long time, and as a result, there are tons of tutorials, frameworks, components and libraries for it. It’s hard to beat that.
Now that we chose our programming language, our next step is a choosing a Javascript tool for building frontend. This is trickier. Simply looking at all live websites and choosing the most popular techs won’t work. 32.9% of all websites are written in WordPress. And there are many other similar, popular platforms, like Wix, Shopify, Weebly etc. Should you write your product in WordPress? If you’re reading this, you probably even can’t. So we now know that looking only at a framework’s popularity is skewed, because the most used libraries and frameworks are found in project types not similar to what we want. We’ll first start by selecting techs that look promising, and then compare their popularity.
Another thing we must take into consideration is writing cross platform code. Sure, it’s easy to write Javascript code that runs on all web browsers, but what about mobile? Maybe you later want to port your website into a mobile app.
As mentioned earlier, a great solution for this is Facebook’s tech: React is a tool for making websites, while React Native is a tool based on React for making mobile apps for iOS and Android. And they’re both over Javascript. But how popular are they? Here’s Facebook’s list of popular websites that use React, where you can find giants like Instagram, Netflix, WhatsApp and Dropbox. But how does that compare with other techs?
Some good alternatives to React are Angular and Vue. All 3 are based on javascript, solve the same problem and are popular. The main difference between them comes to porting to mobile, which we’ll discuss further. As long as you don’t care about mobile, all 3 of them are strong alternatives, each having its pros and cons.
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?
We’ve earlier compared React to Vue and Angular. Vue and Angular also allow easy mobile ports, but using Nativescript. While both are open-source, Javascript based tools for creating cross platform mobile apps, there are few key differences between React Native and Nativescript worth mentioning:
- 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.
Google’s Flutter is another trending option for cross platform mobile apps. But it’s based on Dart, an unpopular programming language launched in 2011. In fact, it’s so unpopular, it doesn’t even appear on some programming language popularity ranking lists. From BuiltWith’s crawled data, they found only 196 live websites built using Dart, which seems irrelevant when comparing it to 225.358 live websites built with React. So if we go with Flutter, we won’t also use something similar for web development. And we’ll still be using Dart for mobile, which is too obscure for now, making hiring painful. React Native lets us program in Javascript, which needs no introduction.
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.
Microsoft’s Xamarin is another option for writing cross platform mobile apps, but its programming language is based on C#. It’s great for writing cross platform code between mobile operating system, and it’s using C#, which, like Javascript, is a popular programming language. Both React native and Xamarin are open-source. While React Native and Xamarin are pretty similar, there are few differences between them:
- React native’s popularity is on the rise, while Xamarin’s is declining
- React Native’s Javascript allows for easy ports between web and mobile apps
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.
Backend
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.
One step further in having cross platform codebase for frontend, is to also use similar techs between frontend and backend. In our case, React and React Native are programmed in Javascript, so choosing a Javascript backend tech makes debugging easier, lets developers to swap roles when needed and allows shared small components between backend and frontend. And Node.js fits our criteria perfectly. It’s popular and used by many giants like Netflix, Paypal, Linkedin, Uber, Medium etc.
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.
Database
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.
MONGODB
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.
Disclaimers
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.
