Choosing a web application stack: frontend, rendering, backend, database, hosting

For most business web applications, the right stack is the one your team can hire for and maintain for five years: a mainstream frontend (React, Vue, Angular or Svelte), a rendering model chosen by who the pages are for, a well-supported backend (Django, FastAPI, Node.js, or Odoo if the app is really an ERP extension), PostgreSQL as the database, and hosting close to your users. Decide the rendering model and the data model first; the framework names matter less than people think.

Frontend options for business web apps

Four frontend ecosystems cover almost every serious business application today. All are mature, support TypeScript and can build a large admin panel or portal; they differ in hiring, conventions and how much the framework decides for you.

• React, usually with a framework such as Next.js or React Router, or on its own with Vite. The largest ecosystem and the easiest to hire for. See React and Next.js: when to choose them.
• Angular. A complete framework from Google with routing, forms, HTTP and testing built in, now signal-based and zoneless by default. Strong for large internal applications built by several teams.
• Vue, with Nuxt for server rendering. Gentle learning curve, single-file components, a clear official stack for routing and state.
• Svelte, with SvelteKit. A compiler-first approach with very little framework code shipped to the browser and a small, readable component syntax.

We compare the last three in Angular vs Vue vs Svelte for business apps. And a fifth option is often overlooked: no JavaScript framework at all, with the backend rendering HTML and a little progressive enhancement on top.

Rendering models: SPA, SSR, static and server-rendered HTML

The rendering model decides performance, SEO, hosting and a good share of your complexity. Pick it before the framework.

• Single-page application (SPA). The browser downloads a JavaScript bundle and renders everything; the server only serves an API. Simple to host and excellent for logged-in tools kept open all day; poor for public pages that must rank in search.
• Server-side rendering (SSR) with hydration. A JavaScript framework renders the first view on the server, then the browser takes over. Next.js, Nuxt, SvelteKit and Angular's SSR work this way. Good for public, interactive pages, at the cost of a server runtime and more moving parts.
• Static generation. Pages are built ahead of time and served from a CDN. The cheapest and fastest option for marketing sites, documentation and blogs. Most SSR frameworks can do this per route.
• Server-rendered HTML. Django templates, Rails, Laravel or Odoo's own QWeb render full pages, optionally enhanced with small scripts or tools such as htmx. One codebase, little build tooling, and still the most productive choice for many CRUD-heavy internal tools. If users need it on a phone, PWA vs native app vs responsive website covers that choice.

Backend, database and API choices

The backend holds your business rules, so optimise for correctness and maintainability over raw speed. Python (Django or FastAPI) and TypeScript on Node.js are the common choices for new builds; Java, .NET, Go and PHP are all sound where the team already knows them. The trade-offs are in Django vs FastAPI vs Node.js backends, including when Odoo itself should be the backend.

For the database, our default is PostgreSQL. It is open source, handles relational data, JSON documents and full-text search well, supports row-level security for multi-tenant designs, and every major cloud offers it managed. Reach for something else only for a specific reason, such as a time-series store for sensor data or a dedicated search engine.

For the API between frontend and backend, plain JSON over HTTP (REST-style) with an OpenAPI description is the least surprising choice. GraphQL earns its place when many different clients need very different shapes of the same data. If frontend and backend are one TypeScript codebase, typed RPC or server actions remove a layer altogether.

Hosting and where your data lives

Hosting follows from the rendering model. Static sites and SPAs can sit on any CDN; SSR frameworks need a server runtime, either a platform that specialises in them or containers on a cloud. Backends and databases usually run as containers or managed services on AWS, Azure, Google Cloud or a smaller provider.

For Indian users, all three large clouds have Indian regions, which keeps latency low and makes data-residency conversations simpler. If you sell to regulated customers, ask early where they need data stored; changing regions after launch is a migration, not a setting. Multi-tenant products have more to decide here, covered in multi-tenant SaaS architecture basics.

The order we make the decision in

Teams go wrong when they start from a framework they like and work backwards. This is the sequence we use instead.

1. Write down who uses it and how. Public or logged-in, desktop or phone, minutes a week or hours a day, online always or sometimes offline.
2. Pick the rendering model per area. Marketing pages, the app behind login and any public listings can each use a different model.
3. Model the data. Entities, ownership, tenants, what must be auditable. This drives the database and backend far more than traffic does.
4. Decide what already exists. If Odoo, a CRM or an accounting system holds the master data, the new app may be a portal or extension rather than a new system of record. See customer portals: Odoo portal vs custom build.
5. Choose languages your team can maintain. One language across frontend and backend (TypeScript) or Python on the backend for data work. Hiring matters more than benchmarks.
6. Choose frameworks within those languages. Only now compare React, Vue, Angular, Svelte, Django, FastAPI or Node frameworks.
7. Choose hosting and data location. Where users and regulators are, and what your team can operate at 2 a.m.
8. Build one thin vertical slice. Login, one real screen, one real write to the database, deployed. It exposes wrong choices while they are cheap to change.

Choose the rendering model and the data model first. Most regretted stack decisions are really regretted data decisions.

Where teams go wrong

• SSR for an internal tool. A server-rendering framework adds a runtime to operate and a class of hydration bugs, for pages no search engine will ever see.
• An SPA for public pages. Search and link previews suffer, and the fix later is a rewrite of the page layer.
• Too many services too early. One well-structured backend is easier to change than five microservices.
• Rebuilding what the ERP already does. Invoicing, stock and GST logic already exist in Odoo; duplicating them in a custom backend creates two sources of truth.
• Ignoring security until the end. Authentication, authorisation and dependency updates are architecture, not polish. Our web application security essentials post covers the minimum.

If you are weighing whether to build at all, start with build vs buy, and for budgeting, what drives web application cost and timeline. If the decision is live, our web application team is happy to review your options with you.