Build a Startup Cheatsheet
Backend Options (Supabase, Convex, Custom)
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.
What the Backend Does
The backend handles everything the browser should not see: database reads and writes, authentication logic, payment processing, external API calls, and business rules. In a Next.js app, backend logic can live in API routes (app/api/*/route.ts). For more complex needs, a separate server handles it.
The line between "backend-as-a-service" and "custom backend" has blurred significantly. The right choice depends on how much control you need versus how fast you want to move.
The Three Main Approaches
1. Backend-as-a-Service (BaaS)
A managed platform that provides database, auth, storage, and API in one package. You write minimal backend code.
Best for: Solo founders, teams without dedicated backend engineers, MVPs, products where data access patterns are simple.
2. Framework API Routes (Next.js or similar)
Your frontend framework handles API endpoints alongside the UI. No separate server to deploy or maintain.
Best for: Most startups. The backend logic lives in the same repo, same deploy, same TypeScript types. Scales well until you need WebSockets or long-running processes.
3. Custom Server (Express, FastAPI, Go)
A separate backend service you write, deploy, and maintain yourself. Full control.
Best for: AI-heavy products (Python inference), real-time features (WebSockets), high-throughput APIs, or when your team has strong backend experience and needs it.
Supabase
Supabase is an open-source Firebase alternative built on Postgres. It provides: a Postgres database, auth (email, OAuth, passwordless), file storage, edge functions, and a real-time subscription layer — all from one service.
Free tier: 500 MB database, 1 GB storage, 50,000 monthly active users, 500K edge function invocations. Projects pause after 1 week of inactivity on free tier.
Pricing: Pro starts at $25/month; scales with usage.
Pros:
- Postgres is the right default database for almost every product
- Row-Level Security (RLS) policies enforce data access rules at the database level — powerful for multi-tenant apps
- Built-in auth handles email codes, OAuth, and JWT sessions
- The JS client (@supabase/supabase-js) handles auth, data, and storage in one SDK
- Self-hostable if you ever need to move off
Cons: - RLS policies are powerful but have a learning curve - Edge functions (Deno) are limited compared to full Node.js - Real-time is basic — Postgres CDC subscriptions, not a full pub/sub system - Free tier pausing is annoying during development
When to use: Default choice for most web startups. Especially good when you want Postgres without managing a server.
import { createClient } from "@supabase/supabase-js"; const supabase = createClient(process.env.SUPABASE_URL!, process.env.SUPABASE_ANON_KEY!); const { data, error } = await supabase.from("posts").select("*").order("created_at", { ascending: false });
Convex
Convex is a reactive backend platform where your backend functions run in a TypeScript-native environment and the frontend subscribes to real-time data automatically.
Free tier: 1 GB database, 1 million function calls/month.
Pricing: Starter is free; Pro at $25/month.
Pros: - End-to-end TypeScript — shared types between backend and frontend with no manual API layer - Real-time by default — queries re-run automatically when the underlying data changes - Transactions are built in; no manual rollback code - No ORM or schema migration headaches; schema is TypeScript - Excellent developer experience for collaborative/reactive apps
Cons: - Vendor lock-in is higher than Supabase (proprietary query model, not Postgres) - Smaller community and ecosystem than Postgres - Less flexibility for complex SQL queries or joins - Not a fit if you need raw SQL or complex reporting
When to use: Apps where real-time reactivity is the core feature — collaborative tools, live dashboards, chat apps, multiplayer experiences. Not ideal for data-heavy reporting or if you need to self-host.
// convex/posts.ts — backend function export const list = query({ handler: async (ctx) => { return await ctx.db.query("posts").order("desc").collect(); }, }); // React component — auto-updates when data changes const posts = useQuery(api.posts.list);
Firebase
Google's BaaS. Provides a NoSQL real-time database (Firestore), auth, hosting, and cloud functions.
Pros: Very fast to prototype; excellent mobile SDK; real-time built in.
Cons: Firestore's document/collection model fights against relational data; querying is limited (no joins, limited filtering); vendor lock-in to Google; pricing at scale is unpredictable.
When to use: Mobile apps where offline sync and push notifications matter. For new web-first startups, Supabase or Convex are better choices.
Custom Express / Node.js Server
A backend you write yourself using Node.js and a framework like Express or Fastify.
Pros: Full control over every behavior; no vendor limitations; WebSockets, long-running jobs, background workers all work naturally; hire any Node.js developer.
Cons: You own the infrastructure; more code to write and maintain; must handle auth, rate limiting, and error handling yourself; separate deployment from the frontend.
When to use: When you need WebSockets for real-time features, when background jobs are essential (video processing, cron tasks), or when the team already has Express experience and time to invest.
const express = require("express"); const app = express(); app.use(express.json()); app.get("/api/users", authenticate, async (req, res) => { const users = await db.select().from(usersTable); res.json(users); }); app.listen(4000);
FastAPI (Python Backend)
FastAPI is a Python web framework — the right choice when your backend is AI/ML-heavy.
Pros: Best-in-class Python ecosystem for AI (OpenAI, LangChain, HuggingFace, PyTorch); automatic API docs; async support; type-safe with Pydantic.
Cons: Adds a second language/deploy to your stack; more overhead than Next.js API routes for simple CRUD.
When to use: When AI/ML inference, data science pipelines, or Python-specific libraries are central to your product.
Comparison Table
| Option | Best for | Real-time | Postgres | Vendor lock-in | Time to first API |
|---|---|---|---|---|---|
| Supabase | Most startups | Basic | Yes | Medium | 30 min |
| Convex | Reactive/collaborative apps | Native | No | High | 30 min |
| Firebase | Mobile apps | Native | No | High | 1 hour |
| Next.js API routes | Simple CRUD, no separate server | No | Via any DB | Low | 1 hour |
| Express + Postgres | Custom control, WebSockets | Yes | Yes | Low | 2–4 hours |
| FastAPI | AI/ML-heavy products | Yes | Via SQLAlchemy | Low | 2–4 hours |
The Decision Rule
- MVP with standard features (auth, CRUD, file upload): Supabase + Next.js API routes
- Real-time collaborative app: Convex or Supabase Realtime
- AI product with Python models: FastAPI sidecar + Supabase for storage/auth
- Complex custom logic or WebSockets at scale: Custom Express or Fastify server on Railway
- Mobile-first with offline sync: Firebase or Supabase with the mobile SDK
Do not run a custom server you do not need. Every server is infrastructure you maintain, a billing line you pay, and a failure point you debug at 2 a.m.