Best Tech Stack for Building an API as a Solo Developer

I've shipped five different APIs over the years. Some serve mobile apps, some power SaaS products, and one is a public API that third-party developers integrate with. The stack I keep coming back to depends on one question. How performance-critical is this thing?

For most solo developers, the answer is "not very." Your API needs to be reliable, well-documented, and quick to build. It doesn't need to handle 100,000 requests per second on day one. Here's what I'd pick.

The Recommended Stack

These are the current stable versions as of late May 2026, pinned from the official package registries so you can copy them straight into your dependency file.

One thing worth knowing up front. FastAPI 0.136 requires Python 3.10 or newer, so make sure your runtime is recent before you start.

Why This Stack Works for Solo Developers

When you're building an API alone, the framework does 80% of the heavy lifting. FastAPI gives you automatic request validation, automatic API documentation, async support, and type checking. That's four things you'd otherwise build or configure yourself.

I switched from Express.js to FastAPI about two years ago and my productivity roughly doubled. Not because Python is inherently better than JavaScript, but because FastAPI makes so many decisions for you. Request validation? Pydantic handles it. Documentation? Swagger UI is generated automatically from your type hints. Async endpoints? Just add async def.

The result is that you write less code, ship faster, and get production-quality documentation without any extra work.

Framework: FastAPI

FastAPI is the fastest-growing Python web framework for a reason. Write a function with type hints, and you automatically get request validation, serialization, and interactive API documentation. It's almost unfair how much it does for you. The project sits at roughly 98,600 GitHub stars, which tells you the ecosystem and the answers-on-Stack-Overflow situation are both in good shape.

Here's a real example. A typical CRUD endpoint in Express requires manually validating the request body, writing error handling, and separately maintaining API docs. In FastAPI, you define a Pydantic model and the framework handles all three.

Alternatives. Django REST Framework (3.17.1, 30,000 GitHub stars, pairs with Django 6.0.5) if you want the full batteries-included experience (admin panel, ORM, auth, everything). On the JavaScript side, Express 5.2.1 (69,000 GitHub stars, around 103 million npm downloads a week) is the old reliable, and Hono 4.12.23 (~30,700 GitHub stars, roughly 38 million npm downloads a week) is the modern lightweight option if you don't want to learn Python. Go with Gin (v1.12.0, ~88,500 GitHub stars) if raw performance matters more than development speed. But for solo developers who want to ship fast, FastAPI is the sweet spot.

Database: PostgreSQL

Every API needs a database, and PostgreSQL is the safe default. The current stable release is PostgreSQL 18.4, which shipped on 2026-05-14. It handles relational data, JSON columns, full-text search, and geospatial queries. Whatever your API needs to store, Postgres can handle it. One planning note. PostgreSQL 14 reaches end of life on 2026-11-12, so if you inherit an older deployment, budget time to move up to a supported major version.

I've used MongoDB for APIs before, and I regretted it every time. The flexibility of schemaless documents sounds great until you're debugging inconsistent data shapes at 2 AM. Postgres with a proper schema prevents those problems.

For the ORM, I use SQLAlchemy (2.0.50, ~11,900 GitHub stars) with Alembic (1.18.4) for migrations. It's Python-native and works perfectly with FastAPI. If you're in the JavaScript world, Prisma (7.8.0, ~46,000 GitHub stars, around 11.6 million npm downloads a week) is the equivalent and it's excellent.

Auth: Keep It Stateless

For APIs, authentication usually means one of two things. API keys for third-party developers, or JWT tokens for your own frontends.

API keys are dead simple. Generate a random string, store a hash in your database, and check it on every request. That covers 90% of API auth needs.

JWTs work when your API serves a frontend you control. The frontend logs in, gets a token, and sends it with every request. No session storage needed on the server.

Don't start with OAuth2 unless your API genuinely needs third-party integrations. I built a full OAuth2 provider once for an API that had exactly zero third-party developers for the first year. That was wasted time.

What I'd Skip

GraphQL. For a solo developer's API, REST is simpler to build, easier to cache, and better understood by most developers. GraphQL makes sense when multiple clients need wildly different data shapes. If you're building one API for one frontend, REST wins.

Microservices. Build one API. One service. One database. One deployment. Split it up later if you actually need to, which you probably won't.

API gateways. Kong, AWS API Gateway, or similar tools add complexity you don't need. Your framework handles rate limiting, authentication, and routing. Use what's built in.

Serverless for everything. Lambda functions are great for webhooks and cron jobs. They're terrible for APIs with database connections, cold start sensitivity, or complex business logic. A simple server is easier to reason about.

Getting Started

1. Scaffold the project. Create a FastAPI project with a proper folder structure. Separate your routes, models, and business logic from day one. It takes 10 extra minutes and saves you hours later.

2. Set up PostgreSQL. Use Railway or Render's managed Postgres. Railway gives you a one-time $5 trial credit with no card required, then its Hobby plan is $5 a month plus metered usage. Render has a genuine free tier (the free web service spins down after 15 minutes of inactivity and you get 750 free instance-hours a month, while the free Postgres database is capped at 1 GB and expires 30 days after creation), with Starter web services from $7 a month and Starter Postgres from $6 a month. Check current pricing before you commit, since both vendors adjust tiers. Connect the database with SQLAlchemy and create your first migration with Alembic.

Common Errors and Fixes

These are the snags that catch people on this exact stack. Each one maps to behavior documented in the official FastAPI, Pydantic, SQLAlchemy, or hosting docs.

Python version too old for FastAPI. FastAPI 0.136 declares requires-python >=3.10. If pip install fastapi resolves to an ancient release or errors on install, your interpreter is below 3.10. Upgrade Python, then reinstall. Pin the version in your dependency file so a fresh machine cannot drift backward.

Pydantic v1 patterns breaking on Pydantic v2. Current FastAPI runs on Pydantic 2.x (2.13.4 today). The v1 to v2 migration renamed things. BaseSettings moved to the separate pydantic-settings package, .dict() became .model_dump(), .parse_obj() became .model_validate(), and orm_mode = True in a model Config became model_config = {"from_attributes": True}. If you copy an older tutorial and hit AttributeError or validation that silently behaves differently, you are mixing v1 syntax into a v2 install.

async def endpoint that blocks the event loop. FastAPI runs async def path operations on the main event loop. Calling a synchronous, blocking library (a sync database driver, requests, time.sleep) inside one stalls every other request. Either use an async driver and await it, or define the path operation as a plain def so FastAPI runs it in a threadpool. The FastAPI concurrency docs spell out which to pick.

SQLAlchemy 2.0 "Textual SQL expression should be explicitly declared as text()." SQLAlchemy 2.0 no longer accepts raw strings passed straight to execute(). Wrap the SQL with text(), for example session.execute(text("SELECT 1")). This is one of the most common 2.0 upgrade surprises.

Alembic autogenerate produces an empty migration. Alembic only sees tables that are imported and attached to the MetaData object referenced by target_metadata in env.py. If a model module is never imported before autogenerate runs, Alembic does not know the table exists and emits a no-op migration. Import your models in env.py (or a package they all live under) and rerun alembic revision --autogenerate.

Render free service "sleeping" on the first request. A free Render web service spins down after 15 minutes without traffic, and the next request waits about a minute for cold start. That is expected free-tier behavior, not a bug. For anything user-facing, move to a paid instance so the service stays warm.

The best API stack for a solo developer is one that minimizes boilerplate and maximizes the time you spend on business logic. FastAPI does exactly that. Build the thing, ship it, and iterate based on what your users actually need.

Sources

All version numbers, star counts, download figures, and prices below were checked on 2026-05-30.

• FastAPI on PyPI (version 0.136.3, requires Python >=3.10)
• FastAPI on GitHub (~98,600 stars, via GitHub API)
• FastAPI concurrency and async docs (when to use async def vs def)
• Pydantic on PyPI (version 2.13.4)
• Pydantic v1 to v2 migration guide (renamed methods and settings)
• Uvicorn on PyPI (version 0.48.0)
• SQLAlchemy on PyPI (version 2.0.50)
• SQLAlchemy on GitHub (~11,900 stars, via GitHub API)
• Alembic on PyPI (version 1.18.4)
• PostgreSQL homepage (latest stable 18.4, released 2026-05-14; PostgreSQL 14 EOL 2026-11-12)
• Prisma on npm (version 7.8.0; ~11.6M weekly downloads via api.npmjs.org)
• Prisma on GitHub (~46,000 stars, via GitHub API)
• Django REST Framework on PyPI (version 3.17.1)
• Django REST Framework on GitHub (~30,000 stars, via GitHub API)
• Django on PyPI (version 6.0.5)
• Express on npm (version 5.2.1; ~103M weekly downloads via api.npmjs.org)
• Express on GitHub (~69,000 stars, via GitHub API)
• Hono on npm (version 4.12.23; ~38M weekly downloads via api.npmjs.org)
• Hono on GitHub (~30,700 stars, via GitHub API)
• Gin releases on GitHub (latest v1.12.0; ~88,500 stars, via GitHub API)
• Railway pricing ($5 one-time trial credit, Hobby $5/mo, Pro $20/mo per seat, plus metered usage)
• Render pricing (Starter web from $7/mo, Starter Postgres from $6/mo)
• Render free tier docs (free web service spins down after 15 min, 750 instance-hours/mo; free Postgres 1 GB, expires 30 days after creation)