Choosing a stack in 2026 — a decision framework

Every kickoff call, someone asks “what stack are we using.” The wrong way to answer is naming a stack. The right way is answering six questions, and letting the stack fall out of the answers.

Question 1: Are you shipping mostly to Android, mostly to web, or both?

• Mostly Android with a smaller web → Flutter for the app, small Next.js marketing site
• Mostly web with an optional mobile view → Next.js + a mobile-optimized responsive site
• Both, roughly equal → Flutter for mobile, Next.js for web, shared backend
• Web only → Next.js or SvelteKit

We ship Flutter + Next.js because 70% of our clients need both. Reactive Native and web-native are viable but Flutter has better performance on low-end Android which is 60% of India’s device market.

Question 2: Who’s going to maintain this in 24 months?

• A junior team at the client → boring stack. WordPress, Next.js Pages Router, Laravel — mature tech with wide talent pools.
• A senior team at the client → modern stack. Next.js App Router, Supabase, TypeScript-heavy.
• You / your studio forever → your favorite stack. But say so upfront.
• Unknown / nobody thought about it yet → boring stack. Optimize for hireability.

The single biggest source of pain: shipping a client a stack they can’t hire for.

Question 3: Do you need real-time features?

• Yes, hard real-time (chat, live cursors, live dashboards) → Supabase Realtime, Pusher, or Ably
• Soft real-time (order status updates, notifications) → polling every 30s or WebSockets
• No → REST API is fine

Don’t over-engineer for real-time you don’t have. A polling loop every 30s handles more use cases than founders expect.

Question 4: What’s your database shape?

• Structured relational data (users, orders, inventory) → Postgres. Always. Everything else is an argument.
• Document / semi-structured (chat, activity feeds) → Postgres with jsonb columns still wins vs Firestore
• Time-series / high-write logs → TimescaleDB or ClickHouse
• User content / files → Supabase Storage, S3, R2

Postgres is the boring answer that wins 8 out of 10 builds. If you’re using Firestore because “it’s easy,” you’re paying it back in query flexibility later.

Question 5: Where’s the money coming from?

• Bootstrapped / cost-sensitive → Supabase, Cloudflare Workers, Neon serverless. Pay per request, not per hour.
• Funded / cost-tolerant → AWS, GCP, dedicated resources. More control, more cost.
• Enterprise client with existing infra → whatever they run. Kubernetes, on-prem, big cloud.

For 80% of Indian D2C and SME clients, serverless (Supabase, Cloudflare, Neon) wins on TCO for 24 months.

Question 6: What’s the surface area of the product?

• 1-5 screens — WordPress or a static site
• 5-20 screens with a login — Next.js + Supabase
• 20-50 screens with roles and admin — Next.js + Supabase + a custom admin panel
• 50+ screens across mobile and web — Flutter + Next.js admin + Supabase
• Multi-tenant SaaS — Next.js + Supabase with row-level security, or Cloudflare Workers with Durable Objects

The decision grid

Here’s how it maps to actual stacks we ship on:

Project type	Frontend	Backend	Deploy
Marketing site (5-10 pages)	WordPress or Astro	—	Cloudflare Pages / Hostinger
Marketing + lead flow	Elementor or Next.js	Custom PHP or API routes	Cloudflare Pages
Dashboard / web app	Next.js 15 App Router	Supabase	Vercel or Cloudflare Pages
Mobile app	Flutter	Supabase or Firebase	Play Store + App Store
Superapp	Flutter + Next.js admin	Supabase + Cloud Functions	Full pipeline
SaaS multi-tenant	Next.js + Turborepo monorepo	Supabase with RLS	Cloudflare Workers + Neon

The stacks we don’t ship on (and why)

• Ruby on Rails — mature, still good, but harder to hire in India in 2026 than Node or PHP
• Django — same as Rails
• Laravel — solid PHP, we ship on it if the client’s existing team runs it
• Angular — legacy, we don’t start new builds on it
• Vue — good tech, smaller ecosystem than React, we ship if the team knows it

The one framework question

“React Native vs Flutter?” — we ship Flutter. Two reasons:

1. Impeller renderer is better than RN’s Fabric on low-end Android where 60% of India’s users are
2. Dart’s null safety + strict typing catches more bugs at compile-time than RN’s TypeScript setup does

That said, if the client’s team knows RN, we ship RN. Both are viable. Neither is dying.

The one database question

“Supabase vs Firebase?” — that’s the next post. Short answer: Supabase for anything relational, Firebase for real-time-heavy consumer apps where you don’t care about SQL.

The one thing that beats every stack decision

Ship, then iterate. A boring stack shipped on time beats a modern stack that ships six months late.