How to choose a technology stack

To choose a technology stack, start with three questions: what the product has to do (a web app, a mobile app, real-time features, heavy data processing), who will build and maintain it for the next five years, and which ecosystem already solves the parts every product needs, such as authentication, payments, queues and admin screens. Pick the most established option that answers all three. Trends, benchmarks and what a famous company uses come last, if at all.

We have built and run production software since 2016, and clients bring us this decision for new products and for ones already in production. This is how we think about it.

Start from what the product does

The type of product narrows the field before any preference comes in.

A business web application with forms, dashboards, permissions, reports and integrations is the most common case we see, and almost every mainstream web framework handles it well. Laravel, Rails, Django and the main Node frameworks are all widely used for it.

A mobile app that has to be in the App Store and Google Play adds a choice between native (Swift and Kotlin, two codebases) and cross-platform (React Native or Flutter, one codebase). For most business apps, cross-platform is the practical choice.

Real-time features like live chat, collaborative editing or live dashboards need websockets. Every major stack supports them today, and Laravel has its own server for them in Reverb, so this is rarely a deciding factor unless real-time is the whole product.

Heavy data work, such as machine learning pipelines or large-scale analytics, points toward Python for that part of the system, even if the rest of the product is in something else.

Decide who will maintain it

A stack is a hiring decision. Someone will maintain version one for years, and that person has to be findable. Before recommending a stack, we ask who the client expects to work on the product in two and in five years: their own future team, us, another vendor.

Mainstream stacks win this question easily. There are many Laravel, React and Node developers, and many agencies who work with them. A product built on a niche framework, or on a combination only its original author understood, becomes expensive the day that person leaves.

If the client already has engineers, their skills count heavily. A team of strong Python developers will ship faster in Django than in a framework we prefer, and we will tell them so.

Check the boring parts

Every product needs the same unglamorous pieces: user accounts and password resets, roles and permissions, email, file uploads, background jobs, scheduled tasks, payments, an admin panel, database migrations, tests. The time spent building these from scratch is time not spent on what makes the product different.

This is the main reason our default is Laravel. It ships with authentication scaffolding, queues, a scheduler, mail, file storage and migrations, and its first-party and community packages cover payments, admin panels and search. A stack where each of those is a separate decision, with a separate library and its own maintenance schedule, costs more to build and more to keep current.

A stack is a hiring decision. The people who maintain the product in five years have to be people you can find.

Count the cost of upgrades

Every stack has to be upgraded, and some upgrades are much harder than others. That cost belongs in the decision.

Vue 2 reached end of life at the end of 2023, and moving a large Vue 2 app to Vue 3 is a project in itself. eRank, the SEO and keyword research tool for Etsy sellers, is moving its product from a Vue 2 app to a new one on Vue 3 backed by Laravel APIs, and our engineers work inside its team on that move. Laravel releases a major version once a year with security fixes for two years, and most of those upgrades are routine if the app stays close to the framework's conventions. We moved a US nonprofit's two platforms from Laravel 10 to 12.

For any candidate, read the upgrade guides for its last two major versions and count what changed. That tells you what the next upgrade will cost.

Keep the number of moving parts low

Early-stage products rarely need microservices, a separate API gateway, three databases and a message bus. Each one is something to deploy, monitor and keep upgraded. We start most products as a single application with one database, and split out a service when there is a clear reason: a part with very different scaling needs, a team boundary, or a component that has to be isolated for security.

The same goes for languages. A product with a PHP backend, a JavaScript front end and a TypeScript mobile app is already three skill sets. Adding a Go service and a Python service for small tasks makes the team harder to staff.

Our default, and when we change it

For a new business product, our starting point is Laravel on the backend, React or Vue on the front end through Inertia, MySQL or PostgreSQL, and React Native when there is a mobile app. We are an official Laravel Partner, and this is the stack we know best, so take the recommendation with that in mind. It is also a stack that is easy to hire for, easy to hand over, and well documented.

We change the default when the situation calls for it:

Rewriting a working product in a new stack is slow and expensive, and the old system keeps needing changes while the rewrite catches up. Upgrading the framework, cleaning up the worst parts and adding tests usually gets most of the benefit for a fraction of the cost.

Red flags in a stack decision

Some reasons for choosing a stack should make you stop and ask more questions:

• The developer proposing it wants to learn it.
• It was chosen because a large tech company uses it, at a scale you won't have.
• Only one person on the team has used it in production.
• Routine changes need a specialist.
• Nobody can explain how it will be hosted and what that will cost per month.

None of these rule a stack out. Each one deserves a direct answer before the first line of code.

Write the decision down

Whatever you choose, write a one-page record: the options considered, the reasons for the choice, and what would make you revisit it. It takes an hour and saves a long argument in two years, when a new engineer asks why the product was built this way.

If you want an outside opinion on a stack decision, or a fractional CTO to make it with you, see our consulting services.