Build a Startup Cheatsheet
Choosing Your Stack
Use this Build a Startup reference while you build software engineering projects, review code for technical interview prep, or polish examples for a software engineer resume.
Why Stack Choice Matters (and When It Does Not)
For an MVP, almost any reasonable stack will work. The main risk is choosing something so niche that you cannot hire for it, or something so complex that a solo developer cannot maintain it. The secondary risk is over-engineering — picking a distributed system when a single server would have been fine for years. If you are teaching yourself computer science, choose boring tools that reinforce fundamentals: HTTP, SQL, data modeling, testing, deployment, and debugging.
Choose your stack based on: what you know, what the team knows, and what the community supports. Performance and scale considerations come later.
The Default Stack for Most Startups
For the majority of web-based startups, this combination works:
| Layer | Choice | Why |
|---|---|---|
| Frontend | Next.js + Tailwind CSS | SSR, routing, API routes all in one; huge ecosystem |
| Auth | Clerk or Supabase Auth | Zero auth code to write; handles sessions, OAuth |
| Database | Supabase (Postgres) | Managed Postgres + storage + edge functions in one service |
| Hosting | Vercel (frontend) + Supabase (backend) | Both have free tiers; one-command deploy |
| Payments | Stripe | Industry standard; best docs; free until you earn |
| Resend | Modern API, generous free tier, React Email templates | |
| AI | OpenAI API | Largest model selection; best ecosystem |
This is not the only stack. It is the one that gets a solo founder from idea to paid users fastest.
Choosing a Language
The language choice has less impact than most developers think, but here is a practical breakdown:
| Language | Best for | Community size |
|---|---|---|
| JavaScript / TypeScript | Full-stack web, APIs, serverless | Largest; most libraries |
| Python | AI/ML-heavy backends, data pipelines, scripting | Dominant for AI; large web ecosystem (FastAPI, Django) |
| Go | High-throughput APIs, CLIs, infrastructure tools | Growing; great performance |
| Rust | Systems, CLI tools, WASM, performance-critical code | Growing; steep learning curve |
| Java / Kotlin | Enterprise, Android | Large but slower iteration cycle |
Recommendation: TypeScript for the frontend and most backends. Python if AI/ML is the core product. Do not mix languages in an MVP — it multiplies complexity.
The Build-vs-Buy Decision Framework
Before building any feature yourself, ask:
- Is this core to your competitive advantage?
- Will customers pay specifically because of this feature?
- Can an off-the-shelf tool do 80% of what you need?
If the answer to 3 is yes, buy. Build only what differentiates your product.
| Feature | Buy (use a service) | Build (only if essential) |
|---|---|---|
| Auth | Clerk, Supabase Auth, Auth0 | Custom OAuth only if very specialized |
| Payments | Stripe | Never |
| Email delivery | Resend, SendGrid | Never |
| Search | Algolia, Typesense, pgvector | If search is your core product |
| File storage | S3, Cloudflare R2, Supabase Storage | Never for MVP |
| Analytics | PostHog, Mixpanel | Only if you are building an analytics product |
Monolith vs. Microservices
Start with a monolith. Always.
A monolith is a single codebase that handles all features. Microservices split features into independent services that communicate over the network.
- Microservices solve problems of scale and team coordination — problems you do not have at zero to 10,000 users
- A Next.js app with API routes is already a monolith; a separate Express server is still a monolith
- Companies like Shopify and Stack Overflow ran monoliths for years at massive scale
- Splitting too early creates deployment complexity, network latency, and distributed tracing headaches
Split a service out when: a specific part of the system has dramatically different scaling needs (e.g., a video transcoder), or when different teams need independent deployment.
Serverless vs. Always-On Servers
| Serverless (Vercel Functions, Cloudflare Workers) | Always-on (Railway, Render, EC2) | |
|---|---|---|
| Cold starts | Yes (50ms–1s on first request) | No |
| Cost at low traffic | Effectively free | ~$5–$20/month |
| Cost at high traffic | Can be expensive | Predictable |
| Long-running jobs | Not suitable (15s limit on Vercel) | Works fine |
| WebSockets | Not supported on most platforms | Works fine |
| Setup overhead | Near zero | Minimal |
Recommendation: Use serverless (Vercel) for your frontend and API routes unless you need WebSockets, long-running processes, or background workers. Add a Railway or Render server when those needs arise.
TypeScript vs. Plain JavaScript
Use TypeScript from day one. The cost is minimal (a tsconfig.json and type annotations); the payoff is catching bugs at compile time rather than in production. Every major framework supports it, and type-safe database clients (like Drizzle ORM or Prisma) make your data layer far less error-prone.
When to Deviate from the Default Stack
- Mobile-first product — add React Native (Expo) or swap to Flutter
- Heavy real-time (multiplayer, collaborative editing, live dashboards) — add a dedicated WebSocket server or use Liveblocks/PartyKit
- AI/ML core — add a Python FastAPI sidecar for model inference; do not put ML code in a Node.js route
- High-performance API — Go or Rust instead of Node for specific endpoints, only when you have measured the bottleneck
- Enterprise customers — they may require self-hosted deployments; factor that into your infrastructure design early
Practical Stack Combinations
Lean SaaS (solo founder, weeks to launch) - Next.js + Supabase + Vercel + Stripe + Resend
AI-first product - Next.js (frontend) + FastAPI (Python backend for AI) + Supabase + Vercel + Railway + OpenAI
Marketplace - Next.js + Supabase + Stripe Connect + Vercel + Resend
Developer tool / API product - Go or Node.js API + Postgres (Railway or Neon) + Stripe + Resend + Cloudflare for CDN/DNS
Consumer mobile app - Expo (React Native) + Supabase + Stripe (via RevenueCat) + OneSignal for push