Engineering · 6 min read
Choosing a tech stack for a new product in 2026
Published 26 May 2026 · Updated 11 September 2026 · By Sam Fourie, Niddo
For most new products the right stack is boring on purpose: TypeScript end to end, a React framework with server rendering, a relational database with row-level security, managed authentication and payments, and a host that deploys from git. Choose for hiring, longevity and how much you can buy instead of build, not for what is new this month.
What the decision is really about
- Hiring. Can you find people to maintain it in five years, in your market, at a sane rate?
- Longevity. Is the framework backed by a company or foundation that will still be shipping releases?
- Buy versus build. Does the ecosystem let you buy authentication, payments, email and hosting instead of building them?
- Ownership. Can you take it to another team without a rewrite, and leave any single vendor?
- Cost. What does it cost to run at your scale, and does that cost grow with users or with seats?
Our default, and why
| Layer | Default | Why |
|---|---|---|
| Language | TypeScript, end to end | One language for the whole team, typed contracts between interface and server, the largest hiring pool there is |
| Framework | Next.js with React | Server rendering for speed and search, one codebase for site and app, installable as a PWA |
| Database | PostgreSQL (MongoDB where the data is document-shaped) | Relational integrity, row-level security as the tenant boundary, managed hosting everywhere |
| Auth | Firebase Auth or Supabase Auth | Solved problem: passwords, MFA, sessions, recovery, bought for dollars a month |
| Payments | Stripe, or Paystack in South Africa | Subscriptions, invoices and webhooks you should never write yourself |
| Email and files | Resend with React Email; S3-compatible storage | Deliverability and durability are not where your product wins |
| Hosting | Vercel, with AWS where data residency or heavier infrastructure demands it | Deploys from git, previews per branch, regions you choose |
| Styling | Tailwind CSS with a small design system | Fast to build, consistent, easy for the next team to read |
When we deviate
- Real-time is central (live operations, chat, presence): a managed real-time service such as Ably alongside the stack.
- A native app is genuinely required (deep hardware access, background processing, app-store distribution): React Native on the same backend.
- Compliance dictates regions or key management: AWS in Cape Town, London or Frankfurt with a managed key service, as in ARC Legacy.
- You already have a platform and a team: we build in what they can maintain.
Buy these, do not build them
Authentication, payments, email delivery, SMS, file storage, search, error monitoring, analytics. Every one of them is a vendor problem with better security and uptime than a custom version will ever have, and every one of them has swallowed months of budget at companies that tried. Spend the build on the workflow, the data model and the interface your users live in.
Red flags in a studio's stack
- The stack is whatever the studio already knew, regardless of your constraints.
- A framework or database chosen for novelty, with a small hiring pool.
- Vendor lock-in with no exit path, or code that lives in the studio's accounts.
- No automated tests, no continuous integration, no staging environment.
- Custom versions of solved problems: their own auth, their own billing engine.
How it plays out in our builds
One Journey runs on Next.js, MongoDB, Firebase Auth and Ably for live operations, installed as a PWA on guides' phones. PanelDesk runs on Next.js, MongoDB and Paystack. ARC Legacy runs on Next.js, PostgreSQL with row-level security, AWS KMS and Firebase Auth with multi-factor authentication. Same grammar, chosen per product.
Questions
People also ask.
Is Next.js the right choice for a SaaS?
For most products, yes: one codebase for the marketing site and the app, server rendering where it matters, a huge ecosystem and hiring pool. The exceptions are heavy native mobile requirements and teams already invested elsewhere.
PostgreSQL or MongoDB?
Postgres by default, especially when tenant isolation, reporting or compliance matter, because row-level security and relational integrity do real work for you. MongoDB when the data is naturally document-shaped and the team is fluent in it.
Should we start with no-code?
To test an idea or run a simple internal workflow, often yes. The move to a real build comes when permissions, data volume, integrations or ownership start to bite.
Will another team be able to take over?
That is the point of a boring stack. With documentation, tests and everything in your accounts, any competent TypeScript team can pick it up.