When it comes to building a web application, many tech-savvy founders will decide what technologies to build with by looking at current trends and picking the latest, most popular technologies. But there are some surprising reasons why going by these factors alone could be a pitfall for your project.

1. The labor pool should be deep enough to support your project’s dependencies.
   When considering the longevity of a project, we often have our eyes on the latest technology, like cutting-edge libraries, frameworks, and APIs. This intuitive approach helps ensure a project is future-proof and enjoys the leverage afforded by the latest methodologies. But when building an MVP, our primary concern should always be to deliver value, and that value is reduced if the cost to develop the MVP is inflated by the expense of hiring specialists. It’s much easier and cost-effective to find a WordPress developer than a SiteCore specialist, for example. Technologies with a long history and wide adoption tend to have a deep pool of talent to draw from, which can be important if you’re relying on temporary workers or need to scale your labor force quickly.
   
2. Popular all-in-one services often under-serve and over-charge.
   Cloud services can be a one-size-fits-all solution for everything from data management to authorization. While it is possible to meet all your needs for scalable infrastructure this way, often the cost savings of an all-in-one solution are dwarfed by related expenses. Founders and project managers are often frustrated by the hidden costs hidden in the complex billing agreements and specialist hours, and proprietary tooling is required to support these solutions. Knowledgeable engineers can recommend a few separate providers that will be more flexible, easier to support, and scale better than an all-in-one solution, often at a fraction of the price.
   
3. Longevity is proof of viability.
   Around 78% of the web is powered by Linux, an operating system built on an architecture older than the web itself. It’s natural to wonder how a newer operating system might offer an improvement on this, by leveraging ideas and methodologies that weren’t available at the time. And newer alternatives are available. Plan 9 and Redox, for example, offer features better adapted to current computing. But these newer technologies also lack the deep roots grown by Linux over decades of refinement. It’s unlikely the advantages afforded by a newer operating system could compensate for the opportunity cost of choosing it over Linux. And the same principle applies to other technologies, too. In general, “newer” means less feature-complete and more unstable. Unless there are compelling reasons to do otherwise, it makes sense to stick with proven solutions. When building an MVP or an ambitious feature, there’s already enough uncertainty involved in development. So it’s a good idea to ensure the dependencies that form your project’s foundation are solid.
   

22 years of software development has given me ample opportunity to make mistakes in choosing dependencies. And in some cases, to make the same mistakes repeatedly. These points are condensed from that experience. I hope they can help you avoid making those mistakes yourself! If you’re feeling uncertain though, I’m happy to meet with you and offer my advice about choosing a tech stack for your project’s particular needs.