Which Specific Technologies Suit Your Startup?
Choosing the right the technology stack is the most crucial part of the early stages of a startup.
Before starting, invest time in deciding which technology stack is going to suit you best.
You can combine technologies in specific and powerful ways — and you should, especially if you’re offering something new to the market. But if you’re hasty, and you assume (for example) Java is going to be your best choice, because it was your competitor’s choice, you’re setting yourself up for failure down the line.
Whatever going to use has to be built to scale — meaning you need a good architecture in place. Nobody wants to end up with a bloated, unusable mess in six months, especially if it could be prevented with careful preparation beforehand.
All of this being said, let’s take a look at several of the most important elements of your technology stack.
What will your project do? How is it supposed to run?
What architecture environment will you use?
This decision will determine which languages will be your “workhorses.” But be careful. Although lots of languages, like Ruby or Python, offer speed, they may come with trade-offs when it’s time to scale. If the architecture isn’t very good from the beginning, it’s going to lead to problems down the road — bloat and sluggishness will be headaches you’ll have to deal with.
Although it’s very common for startups to lean on Java of the majority of tasks, due to Java’s compatible nature and and availability of libraries, it isn’t the only language in existence and it might not be the best for your project. In fact, when it comes to architecture, a more precise language like PHP might deserve your attention.
Other languages you might use include Python, NodeJS, C/C++, Ruby. Each has its strengths. It’s just important that you know which will do the majority of the work for which project.
It’s not necessary to overcomplicate this, and in fact, if you’ve invested the time into choosing the right language, your framework will fall into place. In any case, this decision can easily be left to the developers, who can adjust it as they need to. Just select the frameworks which are compatible with the languages you’re using. For example, if you’re using PHP, you might pick something like Laravel.
Web and mobile platforms are not rivals, although many in Silicon Valley would have you think so. Both are necessary… but it might be in your best interests to start with a web platform, where there’s more room for error.
From a UI standpoint, web platforms are simply more forgiving. It’s just not as frustrating to encounter bugs on a web platform as it is on a mobile platform. Mobile apps mostly have to be elegant, simple, and intuitive. But a web platform can get away with the occasional complexity.
Building for the web will also give you a chance to work through issues with the project and anticipate where you might run into them on its mobile cousin.
However, the user bases for a mobile app and a web platform are different. What your users value on a web platform may not be the same as what they value on an app.
When it comes to the domain of your web server, a clear winner seems to emerge for most projects: Apache.
That’s not to say that NGINX can’t be used. On the contrary, you might choose to use NGINX if you need and utilize less memory and generally reduce the load. In any case, Apache is compatible with NGINX. A good practice is to use NGINX in front of Apache as a reverse proxy and allow Apache to handle the dynamic content while NGINX handles the static.
But Apache is free — making it a go-to option for lean startups. It also has noteworthy compatibility, which will be crucial for whenever you scale.
Finally, we come to the most important factor…
Your Architect and Developers
You wouldn’t trust a non-expert to do your marketing and content or be your CFO. Similarly, you wouldn’t trust a non-architect to help determine and put together your technology stack.
It might be tempting to leave this to the team of developers who will be working on the project, but resist this temptation. Developers usually have a favorite or “best” technology and they’ll be more likely to suggest using that instead of considering the overarching needs of the project. Plus, decision by consensus can lead to compromises which may reduce quality when you need to scale.
Hire an architect to think long-term.
It’s important to note that you don’t have to hire an architect or developers to permanent positions or even in-house. Outsourcing some of your tasks will help keep you on-budget. Plus, outside consultants can give you an unbiased view of what to do in the short term to make ensure success in the long term.
Choosing the best technology stack is foundational for your startup. Getting it right the first time save you a lot of time and money when you decide to scale.
Make sure you’re picking the best language for the job. Look at what you want your end product to be and work backwards from there. Then your frameworks will fall into place, and you can decide if you want to go with Apache, NGINX, or a combination.
There is no one “right” way to do it… the ways in which these technologies can be combined are powerful and almost unlimited. But that makes it even more important to carefully consider which ones suit your project in the short term AND long term.
Finally, hiring an architect — not a group of developers — to put them together will go a long way towards your success.