# Choosing a tech stack for a SaaS product in 2026 > Pick boring, well-supported tools your team can maintain: TypeScript, PostgreSQL, Stripe and managed services, with tenant isolation and security designed in. Source: https://hidook.tech/insights/saas-tech-stack/ · Published by Hidook (https://hidook.tech) · 2026-10-20 For most SaaS products in 2026, the right stack is a TypeScript front end and back end (or a single full-stack framework such as Next.js), PostgreSQL as the main database, Stripe for billing, managed services for everything that is not your product, and a modular monolith deployed on a major cloud. Choose tools your team already knows or can hire for, because the stack that wins is the one you can still maintain in three years. ## Key takeaways - Pick boring, widely used technology for everything except the one area where your product is genuinely different. - Hiring pool and maintainability matter more than benchmark differences: a stack nobody on the market knows is a business risk. - PostgreSQL covers an unusually large share of SaaS needs, including relational data, JSON, full-text search, queues at small scale and vector search through pgvector. - Decide the multi-tenancy model on day one, because moving from shared tables to separate databases later is expensive. - Start as a modular monolith; split into services only when a team or a scaling constraint forces it. - Buy commodity features (auth, billing, email, file storage) and keep a thin layer between them and your code so you can swap providers. - B2B buyers will ask for single sign-on (SSO), audit logs and a security overview, so plan for them early. - At small scale, people cost far more than servers. ## What principles should guide the choice? Choose boring technology, favour a deep hiring pool, and make sure the team that will run the product can understand every part of it. **Boring is a feature.** Mature tools have documented failure modes and predictable upgrades. Every unusual technology spends from a limited innovation budget; spend it on what customers pay for, not on your message queue. **Hiring pool.** TypeScript, Python, Go and PostgreSQL are easy to hire for; an obscure language is not. **Team fit.** Three TypeScript developers should not adopt Rust and Kubernetes because they are fashionable. Match the stack to the skills in the room. **Reversibility.** Be deliberate about decisions that are expensive to change (data model, tenancy model, primary language) and record them as short architecture decision records (ADRs). **One language where possible.** Sharing TypeScript types between browser and server removes a class of bugs and lets engineers move across the codebase. If you are at the stage of deciding what to build first, [How much does an MVP cost?](/insights/how-much-does-an-mvp-cost/) is a useful companion to this article. ## What does a sensible default stack look like? A sensible default is TypeScript across the stack, PostgreSQL, a managed identity provider, Stripe, and a mainstream cloud, with one proven choice per layer. | Layer | Sensible default | Alternatives and when to use them | |---|---|---| | Front end | React with Next.js (or Astro for content-heavy marketing sites), TypeScript, a component library such as Radix | Vue/Nuxt or SvelteKit if the team knows them | | Back end | Node.js with TypeScript, in the same codebase as Next.js or as a separate API | Python (data/AI heavy), Go (high-throughput), Django or Rails if the team knows them | | Database | PostgreSQL, managed (RDS, Cloud SQL, or a managed provider) | MySQL if already in use; add specialised stores only for proven needs | | Auth | Managed identity provider (Auth0, Clerk, Cognito, WorkOS) or a well-maintained library | Never hand-roll password storage | | Billing | Stripe Billing for subscriptions, invoices and tax tooling | Merchant-of-record services to offload VAT and sales tax | | Email | A transactional email provider (Postmark, SendGrid, Amazon SES, Resend) | Keep marketing email separate | | File storage | Object storage (S3, Google Cloud Storage, Cloudflare R2) with signed URLs | Not the database or app servers | | Background jobs | A queue backed by PostgreSQL or Redis (BullMQ, pg-boss) | Temporal for complex flows; Kafka only for an event backbone | | Search | PostgreSQL full-text search, plus pgvector for semantic search | Meilisearch, Typesense or OpenSearch when search is a core feature | | Product analytics | An event tool (PostHog, Amplitude, Mixpanel) plus your own database | Server-side events for billing metrics | | Observability | OpenTelemetry, Grafana, plus error tracking such as Sentry | Managed platforms if you will not run the stack | | Infrastructure | Terraform on AWS, GCP, Cloudflare or Vercel | Kubernetes only with people to run it | | CI/CD | GitHub Actions: tests on every pull request, preview deploys | GitLab CI or CircleCI if already in use | A few comments on the more contested rows. **Front end.** Next.js gives you routing, server rendering and API routes in one place, which suits most SaaS dashboards and marketing sites. A plain single-page app with Vite is fine for a logged-in product with little public content. **Billing.** Subscription billing has more edge cases than it appears: proration, trials, failed payments, tax, plan changes and refunds. Use Stripe Billing, store the Stripe customer and subscription IDs in your database, treat webhooks as the source of truth for entitlements, and make handlers idempotent, because events can be delivered more than once. **Auth.** A managed provider saves months and handles multi-factor authentication, password resets and social login. Check how it handles organisations, roles and SSO before choosing, because retrofitting them is painful. **Observability.** Put error tracking in before the first user, and add structured logs, a few meaningful metrics and traces once there is traffic. [Cloud & DevOps](/services/cloud-devops/) work is much cheaper at the start than during an incident. ## How should you handle multi-tenancy? Multi-tenancy means serving many customers (tenants) from one system while keeping their data separate; the common options are shared tables with a tenant ID, separate schemas, or a separate database per tenant. ### Shared schema with a tenant_id and row-level security Every tenant-owned table has a `tenant_id` column. Queries must always filter by it. In PostgreSQL you can enforce this in the database with row-level security (RLS) policies, so that even a buggy query cannot read another tenant's rows. The application sets the current tenant on the connection or transaction, and the policy does the rest. This is the usual default: cheapest to run, simplest to migrate and easy to analyse across tenants. The risks are the "noisy neighbour" problem (one large tenant slowing everyone) and a bug that bypasses the filter, which RLS is designed to prevent. ### Schema per tenant Each tenant has its own PostgreSQL schema in a shared database. Isolation is stronger and per-tenant restore easier, but migrations must run once per schema, and thousands of schemas complicate tooling. ### Database per tenant Each tenant has a separate database or deployment. This gives the strongest isolation, per-tenant data residency and independent scaling, but costs more, complicates cross-tenant reporting and needs automation for provisioning and migrations. | Model | Isolation | Cost at small scale | Operational effort | Per-tenant restore | Best for | |---|---|---|---|---|---| | Shared schema, tenant_id + RLS | Logical, enforced by policies | Lowest | Lowest | Hard (needs targeted export) | Most B2B SaaS, self-serve products, many small tenants | | Schema per tenant | Stronger | Low to medium | Medium: migrations per schema | Moderate | Tens to hundreds of tenants with moderate customisation | | Database per tenant | Strongest | Highest | Highest: provisioning, fleet-wide migrations | Easy | Few, large or regulated tenants; strict data residency | Practical advice: - Start with a shared schema and RLS unless a contract or regulation says otherwise. - Put `tenant_id` in every table, cache key and file path from the first migration; retrofitting is the painful part. - Write automated tests that try to read tenant B's data as tenant A. - Allow a hybrid: shared infrastructure for most customers, dedicated databases for a few enterprise accounts that pay for it. ## Monolith or microservices? Start with a modular monolith, and split into services only when a specific team, scaling or reliability constraint makes it worth the cost. A modular monolith is a single deployable application with clear internal boundaries (billing, accounts, notifications, reporting), so one module can be extracted later. It is simple to run and debug, and transactions work as you expect. Microservices split the system into separately deployed services. They help when many teams must ship independently, but bring network failures, distributed transactions, more infrastructure and slower local development. A team of five with ten services is mostly maintaining plumbing. Signs it is time to extract something: 1. One component needs a very different scaling profile, such as video processing or a heavy AI workload. 2. Different teams keep colliding in the same code and deployment. 3. A component has different reliability or security requirements, or needs a different runtime. Extracting one service from a well-structured monolith is a normal move; rewriting a tangled one is not. If you inherit a system that has gone wrong, see [taking over a software project](/insights/taking-over-a-software-project/). ## What about mobile? If you need iOS and Android apps, React Native with Expo lets one team build web, iOS and Android from largely shared TypeScript code. For many SaaS products the first mobile version is a companion to the web app: notifications, quick actions, capturing data in the field. React Native with Expo suits that, because you reuse TypeScript types, API clients and some business logic, and Expo handles builds, over-the-air updates and many device APIs. Choose native development (Swift, Kotlin) for heavily platform-specific features or top-tier graphics performance. If your users mainly work at a desk, start with a responsive web app, which avoids app-store review and a second release process. Version your API, because old app versions stay in the wild for months. ## When should you choose Go or Python? Choose Python when the work is data- or AI-heavy, and Go when you need efficient, concurrent, long-running services; otherwise stay with TypeScript. **Python** is the natural home for machine-learning pipelines, data processing and AI libraries, and a fine web back end with Django or FastAPI if your team knows it. **Go** compiles to a single binary, uses little memory and handles many concurrent connections well. It suits high-throughput APIs, streaming and workers that process large volumes of events. **Stay with TypeScript** when the work is mostly forms, dashboards and integrations, which describes most SaaS code. A second language doubles tooling, CI, onboarding and on-call surface, so add one only when the benefit is clear. ## What security basics should be in place? At minimum: enforce tenant isolation, encrypt data in transit and at rest, manage secrets properly, log administrative actions, and be ready to offer SSO to business customers. - **SSO and SAML.** Enterprise customers expect to log in with their identity provider (Okta, Microsoft Entra ID, Google Workspace) using SAML or OpenID Connect. Choose an auth provider that supports it and model organisations so SSO can be switched on per organisation. SCIM provisioning (automatic user creation and removal) often follows. - **Roles and permissions.** Start with a few roles (owner, admin, member, read-only) and check permissions on the server, never only in the UI. - **Audit logs.** Record who did what, to which object, when, and from where, for sensitive actions such as logins, permission changes, data exports and deletions. Store them append-only and make them exportable by tenant admins. - **Encryption and secrets.** TLS everywhere, encrypted storage and backups, and secrets in a managed secret store, not in the repository. - **Backups.** Automated, with a restore test you have actually performed. - **Least privilege** for engineers and services, with separate development, staging and production environments. - **Data protection.** For EU or UK customers, know where data is stored, which sub-processors you use, and how deletion requests work. - **Questionnaires and certifications.** Larger buyers send security questionnaires, and some require SOC 2 or ISO 27001. Good habits make that easier; the certification itself is a separate project. ## What does hosting cost at small scale? At small scale hosting is a minor expense compared with salaries, and an early SaaS can run on a few managed services. The bill depends on provider, redundancy and usage, so it is better to know the components than to quote one figure. Imagine a hypothetical B2B SaaS with a few hundred users: | Component | What you pay for | Typical shape of the cost | |---|---|---| | App hosting | A small container service or a platform such as Vercel | Small fixed amount plus usage | | Database | Managed PostgreSQL with backups | Usually the largest infrastructure line; scales with size and availability settings | | Object storage and CDN | Per GB stored and transferred | Small at first | | Error tracking, logs, analytics | Often free tiers early on, then per event | Grows with traffic | | Auth provider | Often free up to a number of users, then per user | SSO is frequently a paid add-on | | Stripe | A percentage and fixed fee per transaction, not a hosting cost | Scales with revenue | | AI/LLM calls (if any) | Per token | Depends entirely on usage; measure cost per answer | Check current price lists, since pricing changes. Three habits keep costs sane: start with one region, not multi-region; set budget alerts on day one so a runaway job shows up in hours, not at month-end; and choose managed services for undifferentiated work. Engineering time is the real cost. Every week an engineer spends patching and babysitting infrastructure is a week not spent on the product, which is the case for managed services and a simple architecture. ## How Hidook approaches this Hidook is a remote-first product engineering studio that builds and runs SaaS platforms. Our typical stack is TypeScript, React, Next.js, Node.js, PostgreSQL and Redis, with Go and Python where they earn their place, React Native with Expo for mobile, Stripe for subscription billing, and AWS, GCP or Cloudflare with Terraform and GitHub Actions. In the Blueprint week we settle the architecture, the data model and the tenancy approach, and record the decisions as ADRs so your team can see why. We keep the defaults simple: you own the repository and the cloud accounts from day one, tests run on every pull request, every change gets a preview URL, and error tracking is live before the first user. See [Web app & SaaS development](/services/web-app-saas-development/), or [MVP development](/services/mvp-development/) if you are at the first-version stage. If you already have a stack and doubt it, an architecture review through our [Fractional CTO](/services/fractional-cto/) service gives you a written opinion without committing to a rebuild. ## Frequently asked questions ### What is the best tech stack for a SaaS startup? There is no universal best, but a safe default is TypeScript with React and Next.js, PostgreSQL, Stripe, a managed auth provider and a major cloud. It is easy to hire for, well documented and cheap to run. Deviate only where your product has a real, specific need. ### Should I start with microservices? No. Start with a modular monolith, which is simpler to build, test and operate. Extract a service later when a team, scaling profile or reliability need justifies the extra complexity. ### How do I handle multi-tenancy in PostgreSQL? The common default is a shared schema with a `tenant_id` on every tenant-owned table, enforced with row-level security policies. Use schema-per-tenant or database-per-tenant for strong isolation, data residency requirements or a few large customers. Decide early, because changing the model later is costly. ### Is Stripe enough for SaaS billing? Stripe Billing handles subscriptions, invoices, trials, proration and retries well for most products. You still need idempotent webhook handlers, a mapping from subscriptions to entitlements, and a plan for VAT or sales tax. ### When do I need SSO and audit logs? Usually when you sell to larger businesses, whose security teams ask for SAML or OpenID Connect SSO and audit trails. Modelling organisations and logging sensitive actions from the start is far cheaper than retrofitting. ### How much does it cost to host a small SaaS? Usually little compared with people cost, though it varies by provider, redundancy and usage. The database is typically the largest line. Check current price lists, set budget alerts and keep the architecture simple. If you want a second opinion on a stack or an architecture before you commit, write to no.bs@hidook.tech or book a call at https://hidook.tech/contact/.