The only rule that matters
Boring where it doesn’t matter, opinionated where it does. Your stack is not your product. Users don’t care. Investors don’t care. The only thing a stack should do is let a small team ship fast now and not rewrite at 10,000 users.
Here is what we ship most products on, and the rules for when to break from it.
The default stack (2026)
| Layer | Default | Why |
|---|---|---|
| Framework | Next.js (app router) or Astro for content-heavy | Largest hiring pool, best hosting story, React ecosystem |
| Language | TypeScript everywhere | Catches a class of bugs AI tools love to introduce |
| UI | Tailwind + shadcn/ui | Fast, consistent, not a design system you have to maintain |
| Database | Postgres (Supabase or Neon) | You will never regret Postgres |
| ORM | Drizzle or Prisma | Typed migrations you can read |
| Auth | Clerk or Supabase Auth | Never hand-roll auth. Ever. |
| Payments | Stripe (+ Stripe Tax) | Or Lemon Squeezy / Paddle if you want a merchant of record |
| Resend + React Email | Deliverability plus templates in code | |
| Background jobs | Inngest or Trigger.dev | Retries, schedules, and visibility without running a queue |
| AI | Vercel AI SDK + OpenAI / Anthropic | Provider-agnostic; swap models in one line |
| Hosting | Vercel (app) + Fly / Railway (long-running) | Preview deploys change how teams work |
| Errors | Sentry | Non-negotiable from day one |
| Analytics | Plausible / Umami (site) + PostHog (product) | Privacy-friendly and actually used |
Decision rules
Use Astro instead of Next.js when the product is mostly content: marketing sites, docs, blogs, directories. It is faster and simpler. Add React islands only where interactivity lives.
Use a mobile framework (Expo / React Native) only when the core loop needs the camera, push notifications or offline. Otherwise a responsive web app plus “Add to Home Screen” gets you to 1,000 users.
Add a separate backend (Node / Go / Python service) only when you have long-running jobs, heavy AI pipelines, or a second client (mobile, partners) hitting the same API. Until then, server actions and route handlers are enough.
Use Python only for data or ML-heavy work. Not for the web app. Two languages in an MVP is a tax.
Use a no-code / low-code tool (Bubble, Webflow, Airtable) when you are validating and expect to throw it away. Say that out loud so nobody is surprised at month six.
Never hand-roll auth, payments, or email sending. Never start with microservices. Never pick a database because a blog post said it was fast.
What it costs
Rough monthly infrastructure cost for the default stack:
| Users | Hosting | DB | Auth | Errors / analytics | AI (light) | Total | |
|---|---|---|---|---|---|---|---|
| 0–100 | $0–20 | $0–25 | $0 | $0–20 | $0 | $10–50 | ~$50 |
| 1,000 | $20–50 | $25–70 | $25 | $20–40 | $30 | $100–300 | ~$300 |
| 10,000 | $100–250 | $100–300 | $100–250 | $80–150 | $80–150 | $500–2,000 | ~$1,500 |
People cost 20–50× this. Optimise for people.
Questions to ask a developer who proposes something else
- “What breaks at 10,000 users with the default, and does your choice fix that?”
- “How many developers in our city / on Upwork know this well?”
- “How do we migrate off it if we need to?”
- “Have you shipped it to production before, or is this the project where you learn it?”
Good deviations have crisp answers. Bad ones have vibes.
Stack smells
Signs a rebuild is 12 months away:
- A custom auth system “because we needed flexibility”
- MongoDB for relational data
- No migrations, schema edited by hand
- Business logic in the frontend
- A microservice for each feature at zero users
- Secrets in the repo
- The only person who can deploy is on holiday
What to do next
Copy the default table into your brief. Circle anything you want to change and write one sentence why. If the sentence is hard to write, keep the default. If you want a 30-minute stack review before you commit, book a call.