Our React + Node.js stack: why we chose it and when we don't

If you ask us what we build with, the short answer is React on the frontend and Node.js on the backend. That’s our default. About 70% of our projects run some version of this stack.

But “default” isn’t “always.” We also run plenty of projects on Laravel, Vue, and WordPress. The choice depends on the project, not on our preferences. Here’s how we think about it.

Why React

React won the frontend framework war. That’s not really debatable anymore. It has the largest community, the deepest talent pool, the most mature tooling, and the widest range of libraries.

For us, the practical advantages are:

Component architecture scales well. A 5-screen app and a 50-screen app use the same patterns. When a SaaS client’s feature list doubles in year two, we don’t need to restructure the frontend.

Hiring is easier. If a client needs to augment their own team later, finding React developers is easier than finding Svelte or Solid developers. We don’t want to build something the client can’t maintain without us.

The testing story is mature. React Testing Library, Cypress, Playwright. We can ship with confidence.

Where React is overkill: a marketing website with five pages and a contact form. A content-heavy blog. A landing page that just needs to look good and load fast. For those, we use something lighter or skip the JS framework entirely.

Why Node.js on the backend

When the frontend is React (JavaScript), making the backend also JavaScript means one language top to bottom. That sounds like a minor thing. In practice it means:

Our developers move between frontend and backend without switching context. A full-stack developer on a Node/React project is genuinely full-stack, not “I do both but one of them poorly.”

Shared validation logic. Form validation rules, data schemas, utility functions: write once, use on both sides.

The npm ecosystem is massive. For most problems, there’s a battle-tested package. We don’t rewrite what already works.

Node’s event loop is good for I/O-heavy workloads: API servers, real-time features (WebSockets, chat, notifications), and microservices that coordinate between other services. Most SaaS backends are exactly this kind of workload.

Where Node falls short: CPU-intensive computation. Image processing, heavy data transformation, machine learning inference. For those, Python or Go are better tools. We don’t do ML work, so this doesn’t come up often, but we’d say so if it did.

When we reach for Laravel instead

Laravel (PHP) is our second stack. We use it when:

The project is content-heavy. WordPress is PHP. Drupal is PHP. If the project lives in the WordPress/CMS world, Laravel is the natural backend for any custom functionality around it. We’ve built several media platforms this way: WordPress for content management, Laravel for custom APIs and data processing.

The client’s existing codebase is PHP. We’ve inherited plenty of PHP projects. Rewriting a working PHP backend in Node just because we prefer Node would be irresponsible. We improve what’s there.

Budget is tight and the feature set is straightforward. Laravel’s built-in features (auth, ORM, queue system, mail, caching) mean less custom code for standard functionality. A CRUD-heavy application with authentication and admin panel ships faster in Laravel than in Express.js, where you’re assembling those pieces yourself.

Hosting is a factor. PHP hosting is cheap and available everywhere. A Laravel app on shared hosting costs $10/month. A Node app needs at least a VPS or a container. For small businesses watching every dollar, this matters.

When we use Vue instead of React

Vue is our pick for:

Smaller projects where React’s setup overhead isn’t justified. Vue’s single-file components and simpler mental model mean less boilerplate for a 10-page app.

Progressive enhancement. You have a server-rendered site and want to add interactivity to specific components without converting the whole thing to an SPA. Vue slots in nicely for this.

Projects where the client’s team already uses Vue. We match what you have, not what we prefer.

What we don’t do

Go and Rust. We haven’t invested in these for client work. They’re great languages with clear use cases (high-performance APIs, systems programming), but they’re not where our team’s depth is.

Python backends (Django, Flask). We’ve inherited a couple and maintained them, but we don’t start new projects in Python. Our strength is in the JavaScript and PHP worlds.

Machine learning and data science. We build the applications that consume ML outputs, but we don’t train models or build pipelines. If your project needs that, we can work alongside your ML team or recommend partners.

Mobile with Flutter or React Native. We do native iOS (Swift) and native Android (Kotlin). Cross-platform frameworks save time on paper but introduce constraints we’d rather not manage. For apps where performance and native feel matter, which is most of the apps we build, native is the right call.

How we choose for your project

When a new project comes in, the stack conversation goes something like:

Is there an existing codebase? If yes, we work with it. No rewrites for the sake of rewrites.

Is it content-heavy or app-heavy? Content leans toward WordPress/Laravel. App leans toward React/Node.

Does the team have existing preferences? If your developers know Vue, we build in Vue. Your team has to maintain this after we leave (or alongside us).

What’s the budget? React/Node projects can be more expensive to host and deploy. Laravel/PHP projects are cheaper to run. For a small business, that difference is worth considering.

We’re not selling a stack. We’re solving a problem. The stack is whatever solves it best.