May 8, 2023

How to Choose the Right Tech Stack for Your Startup

Choose the Right Tech Stack cover image

Choosing the right technology is crucial for the successful growth of a project. However, this topic is broad and depends on various factors. In this article, I will focus on the selection of technology for a specific type of project commonly known as a "startup." By startup, we refer to something unconventional, specifically a web service rather than a blog, online store, corporate website, or portfolio website. This article will revolve around selecting technology for a web-based software product, excluding hardware projects, which will be discussed separately. Additionally, mobile development will not be covered here, as it requires its own dedicated article exploring different frameworks and languages.

Another factor to consider is the stage of the project's lifecycle, particularly in the context of a startup. Let's briefly examine different stages:

  1. The project is in the growth phase, and upgrading to handle increased workload is necessary. At this point, there should be a technical team in place, along with an understanding of the current technology's problems or bottlenecks that need to be addressed. If such understanding is lacking, it's advisable to seek experienced professionals or individuals to assist with scaling.
  2. Starting a startup from scratch with uncertain success requires quickly testing the idea, acquiring initial users and customers, and demonstrating growth. Technology selection is not crucial at this stage; a landing page with a subscription/payment form is sufficient to gauge demand for the idea.
  3. After testing the hypothesis and establishing viability, the focus shifts to building a Minimum Viable Product (MVP), which aligns with our case. Now, what should we choose?

While the first two points deserve a separate, extensive discussion, this article will concentrate on technology selection in the initial stage of a startup's lifecycle, when the idea has been tested, demand has been established, and there is a need to rapidly develop the MVP and continue its growth.

Considering these limitations, I would provide five simple recommendations for choosing a tech stack:

  • Use what you know best.
  • Don't overcomplicate.
  • Think twice before adopting new technologies.
  • Consider the market situation.
  • Seek advice from professionals.
  • Use what you know best

    If you or your co-founder possess strong technical knowledge, it is advisable to choose the tech stack based on your familiarity with it.

    Avoid succumbing to market trends and starting the project with an unfamiliar technology just because it's popular. It's better to leverage your existing expertise and quickly prototype using what you already know.

    Proficient in PHP? Great, start with that! Specialize in Ruby/Node.js? Excellent choice.

    There is no magical language or framework that guarantees a project's success, easy scalability, or immunity to becoming outdated. Each language and technology has its pros and cons.

    You can find examples of both successful and unsuccessful services in practically every language. Success ultimately depends on the implementation and the team. Therefore, it's important to base your decision on what your team excels at.

    What should you do if you are strong in backend but need to decide on the frontend?

    It's simple - find a suitable frontend developer and base your decision on their skills.

    Additionally, I recommend paying attention to the market situation, as mentioned in point 3.

    Currently, the main popular frontend frameworks/libraries are React, Vue.js, Svelte, and Angular. While there are other frameworks/libraries available (such as Ember.js, Backbone.js, and others), they have somewhat become outdated in my opinion. For the frontend, I suggest aligning with current market trends and choosing from the most popular libraries. The specific choice depends on whether you have a skilled specialist in your team for any of them. If not, I recommend considering the first two options, as they have a more straightforward learning curve, well-developed communities, numerous solutions, and an adequate number of experienced developers.

    What should you do if you are strong in frontend but unsure about the backend?

    Similarly, you should first determine who will be responsible for developing the backend and make your decision accordingly. If you have an experienced backend developer ready to join the project, choosing the backend technologies becomes relatively straightforward. However, if such a person is not available, your choice of tech stack will depend on the person you manage to find. In this case, I highly recommend taking into account the advice given in points 2 and 3. Choose something popular, time-tested, with a variety of ready-made solutions and discussed use cases. Also, consider the current trend in terms of finding developers proficient in that language to avoid any issues with expanding the team in the future.

    What should you do if you don't have a team?

    If you don't have a team at all, you have two paths to consider:

    1. If you have some technical experience and understanding of a specific technology (for example, you have worked as a manager on projects using a certain stack), it's worth choosing a technology you are familiar with. However, once again, take into account the current market situation. For instance, if you have extensive experience with Meteor.js + Ember.js, it doesn't necessarily mean you should choose those technologies. I recommend sticking with Node.js but selecting a more popular library like Express + React/Vue.js for the frontend.
    2. If you have no technical experience at all, it's worth searching for reliable partners responsible for the technical aspect. Ideally, find someone familiar or recommended, and aim for a long-term collaboration.

    What options are available?

    1. Hire a freelancer.
    2. Hire a company.
    3. Build your own team.

    The search and selection of a technical team is a separate topic that deserves a detailed discussion. In brief, the following options are available:

    1. Hiring a freelancer: Consider this option carefully, as there is a high probability of ending up with a semi-functional prototype that no one will want to maintain or further develop. Not to mention that half of the freelancers may disappear after receiving a prepayment, while the other half may drop out halfway through the project. Without a good understanding of the technical aspects, it's not advisable to rely solely on this option.
    2. Hire a company: The risks are similar to those associated with freelancers, but there is a lower probability of the company disappearing. If you choose this option, I recommend the following:
    • Approach companies specializing in startup development.
    • Approach companies specializing in a specific technology (more specialization increases the likelihood of adhering to standards and obtaining a maintainable product).
    • Seek recommendations from acquaintances who can recommend a specific company.
    • Find a technically competent person who can review and oversee the company's work. This does not require significant investment and can be a strong technical lead dedicating a few hours per week to review the code, ensure everything is on track, and suggest necessary adjustments.
  • Build your own team: This is the most preferable option for a serious project. Almost all startups I have worked with eventually transitioned to this model. However, this option also requires having a good Chief Technology Officer (CTO) in the team who can build the entire technical team of the project and organize their work. As in the previous option, it is not necessarily expensive or difficult to find. It is sufficient to find a competent technical leader in this field who is interested in the project and can dedicate regular, albeit not extensive, time to overseeing the code, conducting interviews, and more. Ideally, this person should be the full-time CTO of the project.
  • Don't overcomplicate.

    There's no need to try to anticipate every possible use case or plan the entire architecture based on an extremely high load. It's possible that the project may not even reach that level of load. Moreover, spending too much time on implementation might allow competitors to emerge and capture the market.

    Be prepared for the possibility of the project's idea changing, which may require significant rework. Avoid choosing a technology solely because a giant company uses it (for example, don't choose Rust just because Microsoft is rewriting parts of its core in Rust for security reasons).

    Remember that good and bad code can be written in any programming language, and at the initial stage of the project, the differences in performance, security, or reliability may not be significant (assuming a properly designed system - which is much more important).

    In this regard, it's also important to avoid reinventing the wheel for every small task. Instead, utilize proven services to save time and expedite the project's release.

    Think twice before adopting new technologies

    When the task at hand is to deliver something quickly and effectively, it's important to stick with proven technologies. There's no need to experiment with new and unfamiliar tools.

    New technologies are better suited for personal projects or small, non-critical endeavors. However, it's not advisable to introduce them into a new production project with the goal of launching quickly and then developing it smoothly (rather than constantly dealing with questions like "how do we implement X?").

    We had an unfortunate experience with using GraphQL in its early days when the team lacked experience and there were limited resources available to address complex challenges. We had a team lead who was interested in "playing" with the new technology, and we allowed them to apply it in a new project. A large project. The result was six months of pain and frustration, an exhausted and demoralized team (who had to learn a new and relatively immature technology), and several additional months to eventually remove GraphQL from the project.

    It's crucial not to let developers experiment with new technologies in critical projects. Insist on using proven solutions that developers feel confident about. Developers often enjoy "playing" with new technologies and can become quite enthusiastic about them. If given free rein, they may focus solely on improving, optimizing, and rewriting, with no limit to perfection.

    Developers, exercise restraint if you recognize that a technology is still very new and you're uncertain about all its nuances. Avoid introducing it into a new project and trying to convince the manager to adopt it. Spare the manager, as they may not fully grasp its intricacies :)

    Consider the market situation

    When selecting a technological stack, it's important to consider the current market situation, including which technologies are trending and in high demand among developers. This doesn't mean you should blindly follow every trend, but it's worth keeping in mind.

    Try to gather information about the number of developers skilled in a particular stack who are actively seeking employment. Also, pay attention to the prevalence of job vacancies related to specific technologies. If you have connections with recruiters, have a conversation with them to gain insights into the current market dynamics. By the way, most recruiters are responsive and willing to share insights into the current IT job market.

    When assessing the market, consider the trend. For example, if there is a shortage of experienced specialists in a certain language but an abundance of junior developers, it indicates that those juniors will become mid-level developers in 2-3 years. On the other hand, if the number of junior developers in a particular language is decreasing compared to previous years, it may be even more challenging to find skilled individuals for your team in the future.

    Seek advice from professionals

    Don't hesitate to seek advice from professionals. There are many specialized groups and communities where you can ask for guidance. You can also reach out to experienced individuals directly and ask, "Hi! I'm planning to launch a project that will do X. I want to use Y technology, but I have no technical expertise in this area. You seem to be an expert in this field. Could you please advise if it would be suitable? What potential pitfalls should I be aware of?"

    This advice also applies to seeking input from recruiters about the market. They can provide valuable insights into the current situation and market trends based on their experience over the past couple of years.

    In summary:

    What you use for your project is not as important as who you work with. It's crucial to have competent individuals handling the technical aspects. The most significant factor is the team. The choice of the tech stack should be based on the strengths of your team.

    Chasing trends and adopting a particular technology solely due to hype is not recommended.


    originally posted on linkedin.com

    CV