Backend MVP: ship it.
- Users
- A handful of clients, usually your own app
- Team
- You, plus an agent
You are here if
- You can change the API shape without telling anyone
- The database fits in a file or a free tier
- There is no queue, no cache and no second service
- Local development is one command
An MVP backend should be small enough for an agent to read whole. One router, one schema library that validates requests and generates types, one database with migrations in the repo. Skip the queue, the cache and the service split; each one is a place the agent has to hold state it cannot see.
What changes when you leave this tier: consumers. The moment a client you do not control depends on a response shape, you need a versioned contract, migrations that only roll forward, and integration tests the agent runs against a real database.
Product API · serves web & mobile
Bun + Hono + SQLite
One file to start, a Zod-validated router, and a database that is a file in the repo until it needs to be more.
The stack
- Framework
- Hono
- Runtime
- Bun
- Data
- SQLite (libSQL / Turso) via Drizzle ORM
- Auth
- Session cookies or a hosted provider's JWT
- Hosting
- Fly, Railway, or a single VPS; Turso if the database must be remote
- Also
-
- Zod OpenAPI for validation and a generated spec
- Hono RPC client for the frontend
- bun test
Why agents do well here
5/5- Hono's API is small and its docs are dense; the agent rarely invents a middleware that does not exist.
- Drizzle over SQLite keeps the schema in one readable TypeScript file and migrations in the repo, so the agent sees the whole data model at once.
- Zod on every route means a wrong shape fails at the boundary with a message the agent can act on.
Avoid at this tier
- Postgres before you need concurrent writers; SQLite is faster to develop against and to test.
- A queue; do the work inline until something takes longer than a request should.
- Splitting into packages; one
src/is enough.
Data & AI · pipelines & jobs
FastAPI + Pydantic + Postgres
Python for the libraries, Pydantic for the types, and a single service that runs the jobs and serves their results.
The stack
- Framework
- FastAPI
- Runtime
- Python 3.14 with uv
- Data
- Postgres (Neon or Supabase) via SQLAlchemy 2 or SQLModel, pgvector if you embed
- Hosting
- Fly, Railway, or Modal for the heavy jobs
- Also
-
- Pydantic v2 models shared between API and jobs
- APScheduler or a cron for schedules
- pytest with a real database
Why agents do well here
5/5- Pydantic models give Python the explicit shapes an agent needs; the data flowing through a pipeline has a type at every step.
- FastAPI generates OpenAPI from those same models, so the API contract is never out of date with the job output.
- Python's data and AI libraries are the most heavily represented in training data, so the agent's first attempt is usually the idiomatic one.
Avoid at this tier
- A workflow orchestrator before there is more than one pipeline.
- Notebooks as the source of truth; jobs live in modules with tests.
- Untyped dicts between steps; every boundary is a Pydantic model.
Internal · tools & automation
Hono + SQLite + server-rendered HTML
An internal tool is a few tables and a few forms; render them on the server and skip the frontend build entirely.
The stack
- Framework
- Hono with JSX (server-rendered) or Supabase Edge Functions
- Runtime
- Bun
- Data
- SQLite via Drizzle, or the product's Postgres in read-only
- Auth
- Google Workspace or GitHub OAuth allow-list
- Hosting
- Fly or a VPS behind a company VPN
- Also
-
- htmx or plain forms for interactivity
- Tailwind via CDN for styling
- A cron for the automation parts
Why agents do well here
5/5- Server-rendered HTML is the simplest thing an agent can write and verify; there is no client state to reason about.
- One codebase for both the screens and the automation keeps the whole tool in the agent's context.
- An OAuth allow-list is a ten-line middleware the agent will get right, unlike a home-grown login.
Avoid at this tier
- A React frontend for a CRUD screen.
- Writing to the product database from an internal tool; read from a replica, write through the product API.
- A separate automation service; put the cron in the same process.