Choosing a tech stack for a B2B SaaS MVP

In short: choose the stack your team can hire for, maintain and ship in, not the most fashionable one. For a B2B SaaS MVP, five criteria decide: how easily you can hire developers, how mature the ecosystem is, how well it fits your data, how it supports server-side rendering if you need search traffic, and who will maintain it in two years. Below is the checklist, and the stacks I have actually shipped products on, so you can see how the choices played out.

Five criteria that matter more than the framework

1. Hiring and handover. Can another competent team take it over? A mainstream stack with plenty of developers beats an elegant one that only the original builder knows.
2. Ecosystem maturity. Authentication, payments, file handling and testing libraries should be boring and well documented.
3. Data shape. Relational data with clear relationships (customers, invoices, permissions) fits a relational database. Choose a document store only when you can say why.
4. Delivery channels. Do you need a web app, a mobile app, or both from one API? Decide this early, because it shapes the backend.
5. Search and speed. If organic search brings you customers, the public site needs server-side rendering or static output. If it is a logged-in tool, it usually does not.

Stacks I have shipped on, and why

Product type	Stack	Why it fitted
Multi-portal business platforms (insurance, residence management, CRM)	Angular + Node.js/Express + MySQL, Flutter for mobile	One API serving several web portals and a mobile app; relational data with strict roles.
Multi-tenant SaaS for garages	Angular, PrimeNG and Tailwind; Node.js/Express; MySQL 8 with versioned migrations	Complex quotes and invoices, five roles, tenant management; 59 sequential migrations kept the schema honest.
Marketing site plus admin with bilingual content	Angular SSR frontend, Node/Express API, separate Angular admin	Server-rendered pages for search, language-prefixed URLs, role-based admin for non-technical editors.
Real-time queue app	Angular + Node.js, Flutter patient app, Firebase real-time backend	Instant synchronisation between practice dashboard and patient phones.
AI-assisted internal tools	Node.js services, Angular dashboard, a swappable AI provider behind an interface	The model can be replaced without rewriting the product.

The pattern across them is deliberately dull: a mainstream web framework, a relational database and a typed API layer. Novelty went into the product, not the plumbing.

Decisions to make explicitly

• Database: relational by default; pick something else for a specific access pattern you can name.
• Tenancy model: decide before the first table exists. See multi-tenant architecture explained.
• Structure: start with one deployable. See monolith vs microservices.
• Authentication: use a proven approach (for example HttpOnly cookies with signed tokens and permissions resolved on the server) rather than inventing one.
• Migrations and CI/CD: versioned database migrations and an automated pipeline from the first week, not after launch.
• AI features: put the model behind an interface and add a spend cap, so a provider change or a bill spike is not a rewrite.

Red flags in a vendor's stack proposal

• A technology chosen because the vendor "likes it", with no answer to "who else can maintain this?".
• A proprietary framework or in-house platform that only the vendor has.
• Several databases and a dozen services for a product with no users yet.
• No mention of tests, migrations or deployment.

A one-page way to decide

1. List your must-have requirements, ranked (see the PRD template).
2. Write down the channels (web, mobile, API for partners) and the roles.
3. Ask two vendors for their stack proposal and the reasons for each choice.
4. Check each choice against the five criteria above.

If you want an independent opinion before committing, the Architecture Power Hour reviews a proposal in one prepared hour and returns a one-page decision record, including the runner-up and why it lost.