.png)
In another post I recommended prioritizing development speed and sustainability over performance considerations or using trendy technologies. One very effective way to do this is to pick a value-integrated ecosystem, platform or framework that meets the main business needs. For example, Ruby on Rails is a leading framework for custom web development because of its simplifying standards, full-stack approach and dynamic community add-ons (called gems in Ruby).
Yet Ruby on Rails is only one of several value-integrated full-stack frameworks that simplify web development by providing already packaged tools that accelerate basic app setup. But not all web frameworks are created equal and picking the right programming language and framework for your business goals is a key technology decision in the early stages of a new venture or startup.
But what are the options for custom web development more broadly? They can be separated into two categories: enterprise tech (such as Microsoft’s .NET ecosystem) and community frameworks written in high-level scripting programming languages (and their main web framework) like Ruby (Ruby on Rails), Elixir (Phoenix), Python (Django) or JavaScript (Node).
The main argument I will step through in this post is that you should avoid falling into the trap, no matter how seductive, of using sophisticated-sounding enterprise tech patterns, including and especially ones like microservices or single-page apps. Let us discuss why below.
Avoid old enterprise tech
Enterprise technologies are not where fast growth ventures thrive. These technologies tend to be preferred by large corporations prioritizing stability and the ability to leverage their corporate software capabilities for web development, as well as technologies suited to a corporation’s heavily siloed organizational model. This kind of development would rarely be the right choice for a fast growth venture, unless the founding team has deep know-how with an enterprise stack to offset the incurred disadvantages.
However, founders working with external partners may be persuaded to build their company’s technology using enterprise technologies like C# (controlled by Microsoft) or Java (now open-source, yet preferred by large corporations). External partners may prefer these technologies because they also do contract work for corporate clients, and therefore have trained developers in these technologies.
Nonetheless, startups have a completely different ability to invest and require much greater efficiencies and speed of development than corporate clients. Using tools suited to behemoths is not the way to become one yourself, although many may fall into this trap. In particular, both Java and C# lack web development ecosystems of comparable simplicity and development speed of those found in the higher-level scripting languages like Ruby.
Avoid new enterprise tech
Languages like Java and C# are far from the hype train when it comes to building out a web application for a digital venture. Yet the recommendation to avoid enterprise tech does not end there.
The tech culture promotes technical patterns like microservices and single-page apps along with an excessive use of the word “modern” to adorn JavaScript or web development. In doing so, they persuade many engineers and product creators to embrace these technologies. I believe this is a mistake they are better off avoiding. Let me show why.
Many developers see Google effectively grow and succeed using microservices, and hence they conclude that microservices must be the right technology approach for companies that desire such fast growth. Similarly, some engineers see Meta (the social media startup formerly known as Facebook) developing and using React and they conclude that this technology for single-page apps must be behind the company’s global market share dominance.
The mistake here is in inverting the causality. These technologies are not the reason for success, rather they are the result of a company being so successful that it can undertake the enormous investments to work in such a capital and labor intensive way and nonetheless succeed. Meta built its entire dominance on a modified variant of PHP (not exactly a language known for being modern). Google adopted microservices given the unprecedented scale of their web activities, and the diversity of their offerings — however, it is important to understand that Google’s search algorithm held the key to the kingdom, not their services architecture. And no amount of microservices work invested earlier would have brought about the creation of the golden search algorithm — if anything, it would have made it more difficult to focus on what matters.
There are exceptions when microservices or single-page app patterns are absolutely the right thing to do. However, as a generality, these approaches bloat rather than compress complexity, and thereby reduce development speed and efficiency. As a rule of thumb then, they should be avoided for a company looking to establish product-market fit.
Maximize your probability of success
Startups require different kinds of technologies suited for the specific technical and business problems they will face. In its early days, a startup’s main objective is building a product and finding product-market fit. This happens when the product is highly desired by at least one market segment, so much so, that meeting demand becomes the main problem instead of making product changes fast enough to make product pitches.
Yet most technology is not built by startups valiantly chasing product-market fit but rather by large plush corporations like Google and Meta who can afford to spend near infinite resources on small enhancements. Therefore, the software development ecosystem becomes difficult to navigate, as enterprise-grade patterns become the trendy standard. Chasing this mirage is a terrible mistake that probably breaks the back of many a startup team.
As compared to a stable enterprise, startups require much greater development velocity and lower cost to give themselves a chance at executing sufficient product iterations so that they may establish product-market fit. Startups also have a much smaller team, and they therefore should prefer more effort-efficient patterns which do not require the detailed collaboration of a larger and larger technical team for simple feature delivery.
This is why full-stack open-source tech is the right approach and tool for the job. Frameworks like Ruby on Rails have benefited from many decades of enthusiastic and sustained open source innovation on the unique opportunities and challenges of building software for the web by many companies and individual creators. The clarifying dynamic that has benefitted these technologies is that they have been the product of a small group of visionaries seeking to extend their own powers and solve real tech and business problems, rather than the result of a bureaucratic apparatus seeking to maximize profits. Thus, such full-stack platforms organically seek to maximize the power of the framework and reduce hand-offs and the dependence on other teams. They are therefore the most powerful tools on the market from the perspective of accomplishing the greatest amount of technology functionality with the least effort and time.
Other patterns like microservices require significant overhead to manage many applications and many environments. Similarly, trendy frameworks like React (itself created by an enterprise) are dead in the water unless coupled with a separate server-based app to handle interactions with a database and sensitive transactions which cannot safely be handled on the front-end. A team working in full-stack Ruby on Rails, on the other hand, can create an equivalent feature set without any handoffs to a separate back-end or front-end team, without the need to separately deploy and monitor multiple applications and send data between them all, without an event stream, and other such complex architectures.
Choose open-source but choose wisely
Choosing open-source web development is far from a risky choice, provided it is made with appropriate considerations. I believe it should be the default approach for any high-achieving team.
However, open-source technologies are very diverse, and one should proceed with caution to select software that has sustained the test of time, whose capabilities and default architecture patterns support the business objectives, and that has an active development team and recent history of changes done in a responsible way which will work well with your own future needs.
New enterprise tech like React, as well as infrastructure meant to support complex microservice setups, such as Apache Kafka or Thrift, are all also open source. Yet you would be mistaken to believe they compress complexity enough that they are a good choice for an early-stages startup. Therefore it is important for companies to start out with simple patterns that expedite their creation of a competitive product before it experiments with more complex architectures. For this reason, we recommend a full-stack application built with Ruby on Rails.
The full-stack integrated application pattern built on open-source tech has been such a radically successful feat of collective enterprise, that most of the major tech startups arising out of the last 10 years succeeded because of it: for example, Airbnb, Twitter, Github, Shopify, Gusto, Zenefits, etc. All of these started with Ruby on Rails.
