"Should we use React or Django?" is one of the most common questions I get from people starting a product, and it's a slightly confused question — the two aren't really competitors. React is a library for building interfaces; Django is a batteries-included framework for building web applications and APIs. You can, and often should, use both. But the question underneath is real: where should the weight of my application sit — in a rich client, or on the server? That's the decision worth thinking hard about.
Having built products across both worlds — React and Next.js on the front, Django and Node on the back — I've stopped answering the framework question and started asking four others instead.
1. How interactive is the product, really?
Be honest about this, because it's the biggest signal. There's a spectrum. At one end are content and transactional products — a marketplace, a booking site, a publication, an internal tool — where users mostly read pages, fill forms, and submit them. At the other end are genuinely app-like products — a design canvas, a spreadsheet, a live dashboard, a chat interface — where the interface holds a lot of state and updates constantly without full page loads.
The further left you sit, the more a server-rendered approach (Django templates, or a lightly interactive Next.js app) will serve you well and cost you less. The further right, the more you'll want a real client-side application where React earns its complexity. Most products are further left than their founders think. "App-like" is aspirational language; look at the actual screens.
Pick the stack that matches the product you're building, not the product you imagine pitching.
2. Who is going to maintain this in a year?
The best stack is the one your team can operate without heroics. A solo founder who knows Python will ship and maintain a Django app far faster than a "modern" React-plus-separate-API setup they're fighting the whole way. A frontend-heavy team will be miserable maintaining Django templates and much happier with a React front end talking to a thin API.
Technology choices are hiring choices in disguise. Before I pick a stack for someone, I ask who's going to be sitting in the codebase at 6pm on a Friday when something breaks, and what they already know. Novelty has a cost that gets paid every single day after launch.
3. Where does the hard logic live?
Some products are hard on the server: complex data models, permissions, background jobs, integrations, reporting. Django is built precisely for this — its ORM, admin, auth and migrations save you months of undifferentiated work, and that value is real and immediate. If the interesting part of your product is the system, lean into a strong backend framework and keep the front end simple.
Other products are hard on the client: intricate interactions, offline behaviour, real-time collaboration, visualisations. There, the backend might be a thin API and almost all the interesting engineering is in React. If you force that complexity onto the server, you end up fighting the browser the whole way.
Put the framework where the difficulty is. Don't split your effort across a heavyweight setup on both ends unless the product genuinely demands it.
4. What does the content need from search engines?
If organic search matters — a publication, an e-commerce catalogue, a marketing site — server-rendered HTML is not optional. This is where the old "React SPA" pattern quietly hurt a lot of businesses: content that only existed after JavaScript ran was content search engines and social previews struggled with. The modern answer is server-side rendering, which is exactly why Next.js exists and why Django templates never had this problem in the first place. If discoverability is core to the business, make sure meaningful HTML arrives in the first response.
A default I actually use
When someone has no strong constraints and wants a recommendation rather than a lecture, here's my honest default. For a content-or-transaction product with a small team, I reach for a server-first approach — Next.js if the team leans JavaScript, Django if it leans Python — and I add client-side interactivity only in the specific places that need it. For a genuinely app-like product with real client complexity, I build a React front end against a focused API, and I choose the backend based on where the domain logic is hardest.
Notice that "React vs Django" never actually got answered, because it was the wrong frame. The right questions are about interactivity, ownership, where the difficulty lives, and discoverability. Answer those honestly and the stack mostly picks itself — and you'll have reasons you can defend a year later, when the initial excitement has worn off and you're the one maintaining it.