The business implications of picking your tech stack

There are, broadly, two different but similar ways of building modern web applications. The first I’ll call the “full stack” approach, and the second I’ll call the “specialized” approach.

The “full stack” approach tends towards using an integrated framework for providing the front-end templates that users see and interact with, the layer that handles browser requests and serves up the appropriate pages, and the layer that connects to the database and handles requests to do. Popular frameworks you may have heard of are Rails (for the Ruby programming language), Django (for Python), and Laravel (for PHP).

The “specialized” approach tends towards using different tooling for the front end (React, Vue, and Angular are popular), the middle tier request/response layer (Express is popular), and backend. Tools in this model are theoretically plug and play - most front end tools can work with most middle tiers, which can work with most backends. In practice there’s often some wrangling.

Full Stack Pros

The pros of the Full Stack approach are:

  1. Time spent configuring and wrangling tooling to play nicely together is minimal as this approach is designed from the ground up to work together nicely.

  2. Development time is usually faster. These frameworks are designed to build web apps, so the main use cases are paved or there are mature plugins that can be used (user authentication, sending email, rendering a UI based on data in the database, etc).

  3. Ramp time for new devs is usually faster because there’s a lot of conventions about where files are stored, where configuration is, and how files hang together, etc

Full Stack Cons

Cons are:

  1. It’s harder to build web apps with heavy UI interactivity (like Trello or Asana). It’s still possible to build apps with lighter UI interactivity. I’ll cover this below in more detail.

  2. If having a native mobile app (listed in the iOS or Android App stores) is important to your business, you’ll need to take a more “from the ground up” approach to building it. This is because code is not really reusable across web and mobile platforms like they are in some specialized approaches. Note you can still build a mobile optimized version of your app that users can access in mobile Safari.

  3. This approach is falling out of favour with some developers. My theory as to why developers like this is because they want to learn new tools and enjoy the intellectual challenge of a new framework. From the data I’ve seen, I don’t believe this will impact your ability to hire if you build using a “full stack” approach.

Specialized Pros

The pros of the specialized approach are:

  1. If you’re building an app with a heavily interactive UI (like Trello, Asana, or Gmail) you’ll want to use this approach. You could do it with a full stack approach, but it would be less maintainable and more expensive.

  2. If you want to reuse code across your web, iOS, and Android platforms AND you need iOS and Android native apps listed in the Apple and Google Play store, then this approach will likely be cheaper and faster.

Specialized Cons

Cons are:

  1. Time spent configuring and wrangling tooling to work together is longer than the full stack approach. This can be mitigated if the development team has used the stack before and understands how to quickly configure tooling to play nicely together. .

  2. You’ll likely pay more for developers who can use these tools. This is for three reasons. First, there are almost certainly fewer developers who are using the combination of tooling and languages that you’d select vs. choosing a full stack approach. Demand is often high because developers seem to end up choosing the stack even though there are massive business consequences to maintaining an app built in one stack vs. another. Low supply + decent demand = higher prices. Second, you may actually need more bodies on your team to get things done, a front end developer and a backend developer. This adds cost and communication overhead. Note you may need this too with the full stack approach, though it’s less likely. I don’t call this the specialized approach for nothing. And finally, the types of developers who use these tools come from FAANG companies and well-funded startups who have different business reasons for using this tooling, and the capital to pay developers salaries they expect to make when they leave.

  3. Because there’s less convention about how these tools work together, it’s probable that new developers will have a longer ramp up time to understand the code base when coming on to your project.

  4. Unknown unknowns. “Full stack” frameworks like Rails, Laravel, and Django are mature by web standards (over a decade for Rails and Django, 8 years for Laravel). They’ve run into and have solutions for all major issues that developers run into when building modern web apps. It’s difficult to know the limitations your team will run into when using a combination of tools and languages that are not as tested.

What about hiring? You’ll be able to find good developers who do both. I think you’ll pay more for specialized developers for the reasons cited above.

A possible middle ground?
Assuming you’re building a typical web app that isn’t a Trello, Gmail, Asana, or similar, one possible middle ground that I think is a viable if you’re starting from scratch is:

  1. Starting with using a full stack framework. This ensures minimal time to delivering features for the business.

  2. To integrate and use a front-end framework on the pages that really demand heavy interactivity where using a full stack approach just won’t work.

With this approach, you get the best of both worlds: you get well understood technology and to market quicker, and get heavy interactivity only on the pages where it’s necessary.

So what should I use? A major factor in the tech you use is what your devs are good at with. You want happy developers.

But when building something new I recommend being conservative and choosing technology that’s well understood. Shipping software is a well-trod path and I don’t recommend clients spend their handful of limited “innovation tokens” on things that their development team thinks is new and sexy unless there’s a clear business reason.

Personally, I want something that is fast to set up, enables fast development, is well maintained and supported by a large community and potentially a corporate sponsor, is easy to find developers to work on, is easy for new devs to ramp up on, works for the job, can be scaled, and is practical.

If those factors are important to you, and you:

  1. Are not building an app that needs desktop-like levels of responsiveness and interactivity
  2. Do not need to invest or are not sure about how much you’ll want to invest in a downloadable version of your mobile app
  3. Have developers who know (preferably) or want to learn one of Rails, Django, Laravel (or similar) and accompanying programming language

Then I would use an existing full stack framework.