Introduction
"If one day, I launch my startup, I will use language X instead of the crappy stack I have in my current job".
I have heard this one more than once. And today I would like to discuss some items that I think should be considered when answering this question ("what stack should I choose for this greenfield project ?"), instead of only focusing on one's favorite language.
So, for this post, please imagine you are in the following situation: you have decided to jump on the bandwagon and co-founded a startup with a friend of yours. He's CEO, you're CTO. He's going to market and sell the product, you're going to build it.
This means your new project starts from scratch ! No undocumented legacy code to deal with. No crazy features that you have to keep alive. No business expectations. You feel like an adventurer, sailing the sea. Nothing is impossible, and you have complete freedom over the project.
So ... you know the product you're going to build, and you are going to decide for a technical stack. Database, backend, frontend, deployment... you can choose whatever you want.
Now are some of items you should consider for this choice that might not be the first you'd think of.
The obvious ones
There are some obvious reasons why you should choose one technical stack. By stack I mainly mean the language although the question is relevant for the architecture, the database, even the tools and libraries. But let's focus on the language.
Example: building an app that needs to run into a webpage ? Javascript it is. Some years ago it could have been Flash too.
You have in mind that some complex mathematical operations need to be performed ? Python is known for dealing remarkably with it. Looking for performance ? You might want to look at Go or C++.
If you are a developer, you probably do not need me to tell you those things :D . These are easy and obvious reasons to pick a language instead of another. You're not going to try to run PHP in a browser, right ?
Answering these simple requirements should help you to eliminate the bad candidates quickly. If only one language is suitable at the end of this round, well, lucky you, you have found your stack.
But if there are still multiple available choices that meet your basic requirements, you are still hesitating. For example let's say you want to build a classic web application. Nothing exotic, something standard ... You might be hesitating between Java, PHP, Python, Ruby, Javascript and Go for the backend, those are all suitable candidates. You need more arguments to choose one among them.
Ecosystem
Tools
In software, there are different programming languages. Then there is also what developers have built on top of it. Each language has some tools that come with it and can be true game changers. The first of them being the package managers. Javascript has npm, Python has pip, PHP has composer ...
Other important tools that will impact your daily life are debugging and profiling tools, IDEs, static analysis tools, linters, testing frameworks ... and I probably forget some.
When you choose a language, you are also bounded to the sets of tools available for it. You probably want to have a look at them and check that they match your needs.
Frameworks
Now come the frameworks. The year is 2020, and unless you love to reinvent the wheel, then you will probably use a framework for your project. For our web application example, we could consider Django for Python or Symfony/Laravel for PHP.
Again, you might want to check whether the available frameworks for the stack you consider suit your project needs.
Libraries
Third come all the libraries. ORMs, loggers, middlewares, API SDKs, bridges ... each language has more or less advanced libraries available for a wide range of topics/needs. All the libraries that you might use could save you days of coding. This is especially important for you who is launching a startup ; time-to-market is a very important KPI in your situation. So please have a look at the libraries available for the language you consider.
However do not forget these libraries have requirements too: if your product is a software that must be installed on Windows Server, this will drastically impact the available options.
Project liveliness
This one is interesting.
All right, maybe you have found the best language, it fits perfectly your need. There is a framework perfect for your usecase and libraries that provide all the critical components you need.
But ... will it still be maintained in 5 years ? The answer is obvious for popular languages like PHP or C++, but what about the "corporate" languages, which evolve mainly thanks to a company ? Companies live and die. A company can also decide to shutdown a language, Apple did it for Objective-C in order to push their new iOS development language, Swift.
There's also the "small" languages. They might be popular right now, but who can tell for 5 years ahead ? This question for examples applies to Javascript frameworks, which tend to become vintage in a few months sometimes. Angular was once the king, and now he has very serious competitors with Vue and React. Will it stay, will it go ? No one can say, but the companies which performed a full rework of their frontend based on Angular are probably not feeling well right now.
As a startup needs a lot of energy and time in its early years, you probably do not want to rebuild your product on a new stack because the previous one was discarded. So have a look at the people behind the language/framework/library that you consider using, and make sure the project is lively and maintained. You want to know that the stack you are going to choose, which is the very foundation of your software project, is solid and will mature safely.
An example of this usecase: if you start using a library who is maintained by a single unpaid developer, you basically rely on someone's motivation to keep it alive. If he gets bored or sick, the project could be halted and rust. You probably do not want to be limited by an obsolete dependency, so choosing libraries with a large maintainer team might be a safe bet.
Licensing
Do you ever read those LICENSE.md files ? Do you know the difference between MIT and GPL ? If not, you should change your mind. Because these licenses actually have a huge impact on your project.
If you're hosting your own product (SaaS) you're probably fine ... but still, you should check your tools licenses as you might discover one day that what you thought free has actually a fee but they did not ask you yet. There's was some turmoil around Redis and MongoDB recently about their usage and how they were sold by cloud providers.
The trouble mainly comes if you are distributing the product as an executable application. Can you use any dependency ? Can you ship them along or can you only ship the executable and require the user to install the dependencies by himself ? All of these questions might become a main obstacle in your road to success if not examined thoroughly.
Also some licenses are not compatible which means you cannot legally use some dependencies together.
To make it short: licenses matter and are an important topic. You need to learn their specificities in order to choose the right stack with the right license for your project. Too many people "just put MIT" as a default choice for their project, unaware of what it actually means for the future of their software.
Deployment
Running your POC on your computer is one thing. Deploying it on a cluster or on a customer's server is another. Do you know how you plan to ship and/or deploy your product ? How you plan to allow people to upgrade ? Will it fit with the current standard ways of deploying an application for the language you have chosen ?
This is another aspect to consider when looking at language candidates. This aspect is actually one of the greatest strengths of PHP: for years people have been deploying PHP applications by simply uploading files on the target server. No need for restart, no need for cleanup, no need for cache invalidation: modify the source code on server and you're done. This deployment procedure seems now completely obsolete in 2020 but its simplicity served well startups who wanted to grow quick and fast.
There are also many companies that now offer deployment as a service (usually a cloud platform), such as Heroku. They will probably welcome you as a customer if you use one of their supported stacks. But if you chose some exotic programming language ... this might be a no-go for them.
Developers market
This is the last and maybe the most important item in my opinion, and yet it's quite often forgotten. It's easily forgotten because all of the previous topics are technical. All of the previous topics are related to features, code, repositories, capabilities. But this one is quite simply ... human.
In our scenario, you are launching a startup. If you're successful, and I wish you to be successful, then you'll probably need to hire. But will you be able to hire people for your stack in your area ? If you launch a great app powered by elixir, will you find elixir devs to hire in the city where you are located, when you need them ?
Well, there's still remote workers, but this might not be the easiest way for a startup that is still fighting its way on a new market.
So if you hesitate between stack A and B, you might want to choose B just because there are more developers skilled in B in your area than in A. Quite simply, this is about resources availability.
If you choose a stack too exotic, you will not easily be able to hire people skilled for it. So it is a safe bet to use a stack that is already being used in your area, as it means there are developers that you can hire around you.
Conclusion
The choice of the stack has obviously a huge impact on how a software project is born, grows and expands. And it would be a mistake to think it only impacts the source code. Your customers, your providers, your partners: your technical stack will dictate a lot of your constraints as a company. That is why I will always suggest not to choose an exotic path. Stick with standard programming languages: Python, C, Java, Ruby, PHP ...and avoid the funny-but-unpopular ones. And more importantly, stick with the standard programming languages being used in your region/country.
It might sound less fun, but it will relieve you from a lot of stress.
Top comments (0)