Entrepreneur Guide: Choosing Technologies for a Startup
A startup in itself is a great display of the values it pursues. The word “startup” tells us about conceiving an idea and getting it up to higher levels. Both of these factors, however, fully depend on a technology that will be picked as a powerful start and further scalability can’t be achieved without a proper toolkit.
In broad terms, a tech stack is a list of software plus programming languages that operate in the same environment to create websites and mobile apps and maintain their activity via server-side and client-side support. It also includes libraries, frameworks, and databases that will help the teams manage the products at any moment in their lifespan.
When I start working with a new startup, especially in alpha and growth stages, the issue of choosing a good, solid technology that will meet all product objectives will not become obsolete in a couple of years is rising ubiquitously. Over the years, I gathered a brief list of advice that will help entrepreneurs put their money on the right horse.
With a huge number of these tools available on the market, the stack choice can become quite a debate and should depend on a competent unit in this case. Such a decision should be delegated to an experienced architect and not to the team of developers as the developers may suggest a tech stack that is the most suitable for them instead of the most effective for the project.
But bear in mind that this shouldn’t be taken as the gospel. You should try to find a middle ground based on the time and costs you have — replacing a team member can be costly and time-consuming. Therefore, it’s worth asking team members about which tools they prefer before making the final decision.
Of course, putting a .NET developer into a Java-based stack wouldn’t make sense. But if it were some minor utilities where he/she had no experience, then that won’t be an issue.
The good thing is, dedicated team model allows for adjusting their roster based on your needs and can keep the project relevant at any stage.
Like in a Shakespearean play, there are currently 2 major, rival houses: web and mobile. This topic is good for another dozen articles and will probably never be solved; moreover, the first option doesn’t negate the second one as they can coexist within modern-day gadgets.
The only right answer is to know your end-product well. You need to be fully aware of what it stands for and how to make great use of it: does it naturally feel like a neat mobile app that can be used via simple swipes (messengers, authenticators, taxi services, etc.). Or maybe it is a convoluted mess that requires tons of options, data filling, or precise clicks to allow for the best experience (forums, movies platform, torrent tracker, etc.)? If so, then “web” is the clear winner.
Although both of these platforms can coexist, you still get to decide which should be conducted first as it will define which audience will use your product.
As a rule, it’s a safe bet to make a web app first: such solutions are more forgiving towards mistakes thanks to the greater opportunities for the user to avoid a product’s bugs (mouse availability, bigger screen). Furthermore, web-based products aren’t as dependant on the cross-platform availability: they’re usually accessible via numerous browsers. The updates are also much easier to deliver when you have direct access to your app and don’t have to wait for mobile app stores to deploy it for you (at least 2 weeks, as a rule).
Unlike the rivalry between Android and iOS, the web is a safe place for any type of apps to be fully functional. When you opt to go the mobile path, you will have to choose between the native app and its cross-platform option. Although multi-platform apps provide a wider audience grasp and can be tempting, they almost never reach the quality level that native apps bring upon themselves. As a rule, Swift (a common iOS tool) language isn’t the best for Java (a common Android dev tool) developers and vice versa, making backward compatibility a serious challenge.
The choice here is crucial and you should always pick the right path — remember that it’s always cheaper to make the right choice at the very beginning than to modify your product at the later stages when the tech stack has already defined its route.
Type of project
There are a ton of different tools, and the way your product is supposed to run will be dictated by which tech stack you pick. From a more technological standpoint, there’s a strong dependency towards, for example:
- projects that prioritize speed over high traffic loads, which would make the best use of Ruby or Node.js. Both of these technologies grant a sizeable boost thanks to the well-rounded syntax and the overall terse design. Open-source libraries are also what makes it appealing for the devs to choose.
- projects with a high emphasis on machine learning and data science, which will be a fine match for Python powered by SciPy, NumPy, or Pandas libraries. Python can give you an edge when dealing with large data clusters thanks to the blistering processing speed.
- Java, on the other hand, is a universal soldier among the programming languages and can be utilized by almost any type of project. In fact, it is compatible with numerous side-tools or libraries that make it an obvious choice for the vast majority of top companies, especially when they want to develop an Android-app.
- C/C++ would probably be the go-to choice when crafting complex IoT solutions or even a graphics engine, let alone a full-blown AAA game.
When talking about the frameworks, this is up for debate, depending on how convenient it is for the developers’ team. Depending on each project, it pursues the same goal of aggregating the practices within the project but can be adjusted by the devs. It also helps unite the different components of large projects yet still grant some flexibility by implementing user extensions and modifying its code to a various degree.
The web-server area used to be a battlefield of ideas but is currently a place for two major competitors: Apache and NGINX.
Not only is Apache free, but it’s also easy-to-grasp with the APR function that helps in creating modules. It also has remarkable compatibility and a large source of data knowledge to support its products. SSL and TLS encryption are also at your service to allow for improved security online.
On the contrary, NGINX is a fine option when the performance is set to become a cornerstone for the project. It also requires much less memory and reduces the load when supporting the clients by utilizing a minimum thread or none at all.
This, however, doesn’t mean that both of these options cannot be used: by simply moving NGINX in front of Apache as a reverse proxy, it will help you get the best of two worlds: NGINX for the static content and Apache for the dynamic content to be further returned to the rendered page.
Despite a hefty variety on the market, we can still see the tendencies for certain tools to be picked over the others when it comes to full-blown successful projects. Judging by the data, top companies lean towards:
- Programming languages: PHP, Python, Java, Go, JS
- Frameworks: Node.js, Angular.js, Django
- Databases: MySQL, PostgreSQL
- Server: NGINX, Apache
- DevOps: Docker, GitHub
- Utilities: Google Analytics
- Business tools: Slack, Trello
These general remarks can only touch a fraction of the possible software combinations when forging a system that will run your product. Whether it is .NET, RAR, LAMP, or MEAN, you should also take into account the size of a future project — sometimes it’s even more important than the actual perks of each of the aforementioned stacks.
Reliability is also a key factor when picking a tech stack. As a rule, the more mature tools prove to be the most consistent in terms of performance and bring a bigger toolkit to make developers’ lives easier and more time-efficient. If an ecosystem has a wide range of continuous integrations and bug-tracking systems, it will be a large performance boost for your developers when crafting your end-product.
This article is created with the help of X1Group.