★ No framework wars. Just trade-offs.
Tech Stack Picker
Answer seven quick questions about your team and product. Get an opinionated stack for every layer, with the reasoning and what would change my mind.
- Runs in your browser
- No signup
Your stack
Tech stack
9 layers, picked for your answers. Boring where it should be, so your effort goes into the product.
- Frontend
Next.js (React + TypeScript)
Server rendering for SEO, file-based routing and the biggest React ecosystem. TypeScript end to end catches whole classes of bugs before users do.
- What would change my mind
- A purely internal tool with no SEO needs, where a plain Vite + React single-page app is simpler.
- Alternative
- Vite + React SPA, or Remix / React Router
- Backend / API
Next.js route handlers + server actions
No separate service to deploy: the API lives next to the UI and shares types with it. Plenty for an MVP and well beyond.
- What would change my mind
- Several clients (mobile, partners) hitting the API, long-running work, or a separate backend team.
- Alternative
- A standalone Node.js + Fastify service
- Database
PostgreSQL (managed: Neon or AWS RDS)
Relational, transactional and boring. JSON columns cover the semi-structured bits, and pgvector covers embeddings if you add AI.
- What would change my mind
- Truly schemaless, write-heavy event data at very high volume. Add a specialised store for that slice only.
- Alternative
- MySQL, or MongoDB for document-shaped data
- Auth
Clerk
Prebuilt sign-in UI, organisations, roles and MFA. Hours instead of weeks for a B2B-ready login.
- What would change my mind
- Per-user pricing at consumer scale, or a hard requirement to keep auth in-house.
- Alternative
- Auth.js (NextAuth)
- Payments
Stripe (Razorpay if your customers are mostly in India)
Checkout, subscriptions, invoices and webhooks with the best docs in the business. Marketplaces use Stripe Connect for payouts.
- What would change my mind
- A market or payment method Stripe doesn't serve well, or merchant-of-record needs (tax handled for you), where Paddle or Lemon Squeezy fit.
- Alternative
- Paddle (merchant of record)
- Hosting
Vercel
Git push to deploy, preview URLs for every branch and no servers to manage, which is exactly what an MVP team needs.
- What would change my mind
- Long-running processes, heavy compute or strict data-residency requirements.
- Alternative
- Netlify, or Railway for a container
- Background jobs
Inngest or Trigger.dev
Durable background functions with retries, schedules and a dashboard, written in the same TypeScript codebase.
- What would change my mind
- Very high throughput or strict data residency, which points to a queue in your own cloud.
- Alternative
- BullMQ + Redis
- Analytics
PostHog
Product analytics, funnels, session replay and feature flags in one tool, with a generous free tier.
- What would change my mind
- A marketing-only site, where a simple privacy-friendly counter like Plausible is enough.
- Alternative
- Plausible (simple), or Mixpanel
- Email
Resend
Reliable transactional email with a clean API and good deliverability defaults.
- What would change my mind
- Marketing campaigns and newsletters, which belong in a separate tool.
- Alternative
- Postmark
This is the stack I'd pick.
Want me to build on it? I ship MVPs on exactly this kind of stack.
How I pick
- Team skills first. The fastest stack is the one your team already knows. A great tool in an unfamiliar language costs months.
- Boring by default. Proven, widely used tools have answers, hires and integrations. Spend your novelty budget on the product.
- Managed before self-hosted. Pay a provider to run databases, auth and queues until the bill, not the build, becomes the bottleneck.
- One database: Postgres. Relational, transactional, JSON when needed, vectors via pgvector. Add specialised stores only when profiling says so.
- Compliance changes everything. Health or financial data moves you to your own cloud account, signed agreements with vendors and audit logs from day one.
The default stack
A JavaScript team building a web product for thousands of users, with payments, gets this. It's my starting point before any answer changes it.
| Layer | Pick | Alternative |
|---|---|---|
| Frontend | Next.js (React + TypeScript) | Vite + React SPA, or Remix / React Router |
| Backend / API | Next.js route handlers + server actions | A standalone Node.js + Fastify service |
| Database | PostgreSQL (managed: Neon or AWS RDS) | MySQL, or MongoDB for document-shaped data |
| Auth | Clerk | Auth.js (NextAuth) |
| Payments | Stripe (Razorpay if your customers are mostly in India) | Paddle (merchant of record) |
| Hosting | Vercel | Netlify, or Railway for a container |
| Background jobs | Inngest or Trigger.dev | BullMQ + Redis |
| Analytics | PostHog | Plausible (simple), or Mixpanel |
| Resend | Postmark |
When to break the defaults
- Regulated data. Healthcare and financial products move to your own cloud account, vendors who sign the right agreements, and audit logs everywhere.
- A team with deep expertise elsewhere. A Rails, Go or Elixir team should use what it knows. The principles stay the same.
- Real scale on day one. If you're launching to an existing audience of millions, plan caching, queues and load tests before launch.
- Heavy compute or long jobs. Video processing, model training or big data pipelines need containers or dedicated workers, not serverless functions.
- Hard latency or offline needs. Games, trading and field apps can justify native code and specialised infrastructure.
Questions founders actually ask
Why does the picker recommend boring technology?
Is this stack good enough to scale?
Should the stack follow my team's skills or the 'best' tools?
When should I pick a backend-as-a-service like Supabase?
Is the picker sponsored by any of these tools?
Stack by product type
More from the workbench
Fine print
Tools: on the house.
Engineer: by the hour.
The opinion was free. The implementation is where I come in.
I'm Himanshu, an AI and full-stack engineer. I build MVPs, AI agents and the growth plumbing around them for early-stage startups.