Note: I have also published the second part of this topic - Modern Product Teams Setup for Startups Leaders. Should be a nice read after this article.
From time to time, I meet people with a business background trying to lead a technology startup or participate in some way in a technical project. The typical case would be a company that wants to move online or expand to new markets by building an online platform. This sounds good, but there are some challenges.
The first thing a startup CEO usually does is to find someone with some technical background and ask him about the technical implementation of the solution.
This often ends up not as expected, due to:
- This guy may not necessarily be an expert, even if you think he is.
- This guy may offer you the solution that is most interesting for him personally, but not for your business.
The same applies if there is no tech guy nearby and the request is sent to a technology company that someone has recommended.
If you have little or no tech skills, you have to blindly trust every solution presented to you. Unfortunately, there is no such book as “Modern Software Development for Dummies” nor will it ever be written, as the modern tech stack is too dynamic for a standard book publishing cycle.
Therefore, this article is an attempt to give a high-level non-technical overview of some of the architectural concepts and development technologies in the modern world. You will unlikely become a tech guru after reading it, but you should be able to challenge the technical solutions presented to you.
This article will be most useful for commerce, marketplaces and other classical types of businesses. Innovative tech companies doing self-driving cars or drone delivery have a very specific tech stack that can hardly be shared with the other type of companies.
The diagram of what we will talk about is in the article header image. If you want to view a high-quality image or print it, you can download it in PDF format.
I will describe each part of the diagram below, namely the following key concepts:
- Frontend (Web)
- Mobile app
- Backend (REST API)
- (Cloud) Hosting
Disclaimer: It is possible to build a solution with the different technologies as mentioned below. Just make sure you understand why you do it differently.
Frontend is responsible for building a User Interface (UI) and making sure a User has a positive experience (UX) when using your web site. Some time ago, a typical developer was building both UI/UX and a server logic (backend). Now, as the user interface becomes more complex, it makes sense to have dedicated frontend developers to make sure your app still works as you continue to add new features and increase traffic.
There are three main JS frameworks for frontend development:
Frameworks and the ecosystem around them are quite different from each other, making it unlikely that one person can be a guru in more than one framework. Don’t try to google which framework is better as you will get random results.
I would advise you to follow this logic when choosing a framework:
- If you are serious about the project and would like to build both the web app and the mobile app, pick up React.
- If you want a quick web prototype, choose Vue.
- If you want a strict structure rather than freedom of choice, use Angular
- If you are not sure, pick up one for which it is easier to find the developers. In some regions, one framework may be more popular than others. React developers generally tend to be in higher demand and more expensive.
There are two main approaches to building a mobile app. One is a good old native development where you build a separate app for each mobile platform using a specific language for that platform. Another is using a cross-platform language that somehow works with or compiles to the native code.
Although the first option has been around for quite some time, the languages recommended by the platform vendors have recently changed. Google, the vendor of the Android-based operating system, now recommends using Kotlin instead of the previous Java option. Apple suggests using Swift instead of the former Objective C. However, you can still build the app using the old languages, as it might be easier to find developers with that language skills.
As for the second approach of cross-platform development, it allows building mobile apps cheaper and faster. But it comes at the cost of reduced performance, sometimes a slower user interface, and a larger app size. Unless you plan to use some advanced hardware features or need your app to be super performing, I still recommend using the cross-platform approach.
The primary player in cross-platform mobile development is Facebook with its React Native solution. If you have built your web app with React and backend with Node.js you may ask the same developers to build the mobile app for both platforms as well. That’s pretty good if you lack resources. Alternatively, you can use Google’s recent solution — Flutter. It uses the Dart language, which is rarely used anywhere else, so it might be difficult to find a Flutter developer at the moment. The Flutter may be a good option if you care about high performance but still want to save some money using cross-platform development.
Backend (REST API)
The backend is probably the most complex area to choose the right technology for. It has a long history with Java being the oldest language that survived until now. There are also relatively new players like Node.js, which attract developers with simpler language structures and shorter development times. Since backend development covers a wide range of products, not necessarily web applications, we focus only on what you need to build the REST API.
The REST API, in plain English, is the server that gets the data from some sources, such as the database, and sends it to a web browser or a mobile app using some well-defined data formats. Contrary to the old approach when a server was responsible for the data and the UI, the REST API only cares about the data, while frontend developers and JS frameworks are responsible for UI.
The most popular languages to build the REST API currently are:
Taking into account the complexity of the language, Java may be a bit overkill for the simple REST APIs. There is also some confusion about Java licensing, as some versions of Java are free, while others are not.
Python, the third option, is generally used for Data Analysis, Machine Learning, AI, etc. Not many people choose it as the language for the REST API, but still, some do. If you need to use Python in other parts of the solution, no one will blame you for using it for the REST APIs as well.
To be a bit more objective, I should also mention C# from Microsoft. Many big companies use it. This is not the best option for a startup, but there are a lot of C # developers who can build a good REST API. The problem is that the Windows-based infrastructure is largely more expensive than a Linux based one. Although you can try using C# with Linux, I still haven’t seen the success stories with that combination.
Unfortunately, the decision-making process does not stop with choosing the language, because, as with the frontend, you have to choose a framework.
Below is the list of the most popular frameworks split by languages. The most used is highlighted in bold:
As with frontend, each backend developer has a preference for one framework over the other. There are also some frameworks that are not listed here, but these are safer to use.
Database is the heart of your app, so making a good choice here is important. Before picking up a database brand you need first to decide on the database type: Relational(SQL) or NoSQL. There was much hype about NoSQL databases so don’t try to google which one is better. NoSQL databases are not intended to be generic data warehouses. They should be used for specific purposes or when your data has little or no structure.
Not all databases are free. Most of the well-known commercial relational databases are Microsoft SQL and Oracle. They come with a set of good tools for database design and management, but today there are good tools for the free databases as well.
Two main options for the free relational databases are:
I would say they are more or less the same. Due to competition, each vendor tries to copy the good features of the other vendor. PostgreSQL is often chosen by many developers as it also has better features for working with the NoSQL data types. Personally, I prefer MySQL since it has better tools to manage the data and the database itself. You may also have heard about MariaDB. It is still far behind in usage compared to the other two, so I wouldn’t be using it right now.
After choosing a database, you need to decide how your backend will communicate with it. The basic option is just to use SQL itself. This works well, but some people think it is a bit complex and offer other approaches, ORM being the most popular one. ORM stands for Object-Relational Mapping and helps you avoid writing SQL queries. It can be a lot easier for simple things, but as soon as you have complex data selections and insertions, it can become a huge bottleneck. Professional developers generally do not recommend using ORM and prefer to stick with the native SQL.
A few words about NoSQL databases. If you want to store some unstructured data you can safely pick up MongoDB, the best known NoSQL database. If you need any caching solution, look at Redis. NoSQL databases are a complex topic, so I would not go into more detail. Just challenge your developers if they offer to store your primary data in these types of databases. You may be tempted to use a NoSQL database if you sell products of completely different types that have few overlapping features, but it is still better to try putting some core data into the SQL database so that you can use all the benefits of data consistency and reliability of classical relational databases.
Choosing a hosting provider may seem like a simple thing, but today it is not, because, in addition to outsourcing a computer power and disk space, you must now think about outsourcing scalability, resiliency, and security concerns, as well as database management and infrastructure monitoring. Additional complexity also comes from the fact that hosting companies are now good enough at marketing new services that may seem great but which you probably won’t need.
The top 4 players in the global hosting market are:
In addition to the above global companies, you can go with your local hosting providers, but they will most likely offer less convenient tools and a reduced set of services. Some companies still prefer to turn to local players because of the legal issues around keeping user data locally.
The first three companies in the list above offer a wide range of services with complex billing. Chances are, you don’t need 95% of what they offer. If you start completely new, I would advise you to start with the Digital Ocean. They have a clear interface, easy to use tools and offer practically everything a startup needs. If you want to try someone from the Big3, go to Amazon. It is a bit more expensive than Google, but it has better tools and UI. I can’t say much about Azure, as they still play more in Microsoft technology niche and apparently have no clear advantages over Amazon or Google.
To be efficient and competitive today, you not only have to outsource infrastructure but also some of the business services. Those services were internally managed about 5 to 10 years ago, but are now generally outsourced:
- Sending emails (Sendgrid)
- Storing and managing images (Cloudinary)
- Chats, video and audio communication (Twilio)
There are many companies that offer these types of services, and the leaderboard changes every year. I just gave an example of the companies I would go with, but describing the benefits and making a comparison would probably require another article like this.
DevOps is a generic term. Usually, it means, among other things, setting up a release pipeline which is often referred to as CI/CD (Continuous Integration/Continuous Delivery). Sometimes team structures and different agile practices are also considered part of the DevOps, but I will keep it out of scope.
The idea behind CI/CD is to move the code from the developer to the production server as fast as possible without much human intervention.
The typical development cycle looks like this:
- Product manager presents the new idea
- Designer turns the idea into a visual prototype
- Developers code the prototype
- Developers push the code to the code repository (GitHub)
- GitHub triggers tools that run automated tests
- If automated tests are successful, the code is moved (deployed) to the test servers for manual testing
- Quality Assurance team manually tests the code
- If the tests are successful, the release manager pushes a button to deploy the code to the production servers.
20 years ago, moving code to the server and between them was done through FTP, either manually or with some scripts. Now it is a little different and there are many tools to automate it. There is no absolute leader in this area, so it is quite difficult to name a go-to solution. A couple of brands you might want to check out are Jenkins and GitLab CI/CD. If you start small, I would advise trying a new tool called GitHub Actions. It does not require any additional servers, as it is part of GitHub, where you store the code, but it can do almost everything you need at least in the early stages of the project.
Before pushing the code to the server, the current best practice is to wrap it in the Docker container. You can get away without it, but it would take a lot more effort later to build a scalable and resilient infrastructure. The Docker was created with the idea of isolating the application environment from the hosting environment so that any code runs on any server. It’s still the good benefit of Docker, but probably the biggest one is the option to easily scale the entire solution by deploying Docker to the Kubernetes cluster. Kubernetes is a container orchestration system. It’s a pretty complex technical topic, but it basically scales and replicates your Docker containers, so they work reliably and according to the load. If you choose the managed Kubernetes cluster from global cloud hosting providers, this complex topic can become quite easy but still a bit expensive.
There is one thing that does not just fit into one topic but encompasses areas of database, hosting and DevOp. That is the database hosting. You can host it as a classical Docker container like the other parts of the solution, or you can use a managed database hosting service from the hosting provider. The first option is cheaper, the second is easier and more scalable. If you decide to use the second option, check to see which databases are supported, as not all providers support all databases.
Most people familiar with the modern world of software development have heard the word Microservices. Microservice is not a piece of the diagram like the topics above, but rather the architectural approach to make your system more scalable and resilient. Scalability and resiliency are definitely the good things, but what is not always clearly mentioned is the cost you have to pay for it. And the cost is really high.
If you choose to use microservices, the first challenge will arise very soon when you decide to have an authentication service as one of the microservices. The problem is that authentication is used by all microservices and how to share authentication among them is a big and complex topic. The next challenge will appear when you have a transaction that spans different microservices. This easy thing with the single service, it immediately turns into a big headache with microservices. Therefore, unless you have a professional (and well paid) team of backend and frontend engineers, as well as a dedicated DevOps team, I would highly recommend starting monolith (without microservices). A good working monolith is much better than poorly functioning microservices. Also with Docker and Kubernetes, you can achieve scalability and resiliency with much less effort than using microservices.
Anyway, if you start monolith and one day hit the performance issues, you will be able to peel off some service to a microservice.
This was a brief introduction to the modern application development world. Each topic mentioned in this article is a large and complex technical area in itself with many books and other articles describing it, but I hope this article was a useful summary. The more you understand the technology, the greater the chances you have to succeed. As most investors say, the idea itself is worth nothing, proper implementation is what makes it successful.
As we now know, offline businesses can go away when a new virus arrives. Your online business will have a much better chance to survive.