Choosing a SaaS technology stack you will not regret
The stack matters less than teams argue and more than they admit. Three decisions genuinely constrain the next five years; the rest can be changed.
Key takeaways
- Only the database, the tenancy model and the hosting location are genuinely hard to reverse.
- PostgreSQL is the correct default; specialised stores chosen early for unreached scale become expensive when you need transactions.
- Confirm your platform has a Saudi or UAE region before building, if residency is in your future.
- Prefer boring technology with a large hiring pool; interesting belongs in the genuinely novel part of the product.
Three technology decisions are genuinely difficult to reverse: the database, the tenancy model, and where the application runs. Almost everything else, the framework, the language for a given service, the component library, the deployment tooling, can be changed later at a cost you can absorb. Spend the architecture argument on the three that matter and take the conventional answer on the rest.
The database
A relational database is the correct default for a business application, and PostgreSQL is the correct default relational database unless you have a specific reason otherwise. It handles transactions, constraints, row-level security for tenant isolation, and increasingly the specialised workloads that once required separate systems. The most common expensive mistake is choosing a specialised store early for a scale problem the product never reaches, and then needing transactions.
The tenancy model
Covered in depth elsewhere, but it belongs on this list because it constrains everything downstream, including whether you can satisfy a regional data residency requirement without rewriting. Design so a single tenant can be relocated to its own database without application changes, even if you never use that capability.
Where it runs
- Managed platforms remove operational work and are almost always right early. The cost per unit is higher and the total cost including salaries is usually lower.
- Regional availability matters here specifically. If Saudi or UAE residency is in your future, confirm your platform has a region there before you build on it.
- Avoid deep dependence on a single provider's proprietary services for core logic. Managed databases and queues are fine; business logic locked into a provider's function runtime is a migration you will resent.
- Container-based deployment keeps the exit option open at modest cost.
What does not deserve the argument
The frontend framework, the CSS approach, the language for a peripheral service, and the choice between two mature options that both work. These consume disproportionate discussion and have limited long-term consequence. Choose what your team knows, because execution quality dominates these differences by a wide margin.
The rule that ages well
Prefer boring technology with a large hiring pool and long support horizons. A stack chosen because it is interesting produces a product that only its authors can maintain, and the moment they leave you discover that the interesting choice was a liability the whole time. Interesting belongs in the part of the product that is genuinely novel, not in the infrastructure underneath it.
Spend the architecture argument on the database, the tenancy model and where it runs. Take the conventional answer on the rest.