The Cheap Python Stack: A Broke Founder's Guide (2026)

The Framework Was the Easy Part

I told you about the weekend I cheated on JavaScript. Late 2024, I wanted to bolt an AI feature onto Clickly, my URL shortener, and every good library for the job lived in Python. So I opened a repo, agonized over which framework, and eventually landed on FastAPI. I wrote about that whole decision in the Python web framework guide — Django vs FastAPI vs Flask, when Python beats the Next.js default, all of it.

Here’s what nobody told me: picking the framework was the easy 10%. I shipped that first endpoint in an afternoon and felt like a genius. Then reality arrived. Where does the database live? How do the tables get created and migrated? How do users log in? What happens to the request that takes forty seconds because an LLM is thinking? How do I even install the right packages without my machine turning into a graveyard of broken virtualenvs? And where does the whole thing run without a surprise bill?

That’s the stack. The framework is one brick. This post is the rest of the wall — the complete, cheap Python toolchain I’d assemble today, in the order the questions actually hit you. No re-litigating Django vs FastAPI here; go read the other post for that. This is everything around it.

---

Rule Zero: Don’t Build This Stack If You Don’t Have To

I have to say it again because it’s the single most expensive mistake I see. If you’re already fluent in TypeScript and building a normal SaaS — dashboard, CRUD, auth, payments — you probably don’t need a Python backend at all. Next.js will do everything and you keep one language across the whole thing.

Python earns its place when the work itself is Pythonic: AI and LLM backends, data crunching, scraping, scientific stuff. That’s the whole test. If that’s you, or you already know Python cold and ship fastest in it, great — let’s build the cheapest version of this that works. If it’s not you, close this tab and keep your life simple. I’m not joking. A language switch you didn’t need will cost you more than any tool on this page will save you.

---

The Database and the ORM

Your database doesn’t change just because your backend is Python. It’s still Postgres, and it still lives on Neon — the same answer I give for every stack. Neon’s free tier gives you 0.5 GB per project, 100 compute-hours a month, and up to a hundred separate projects, which is how I quietly run seven databases for zero dollars (the per-project trick is the whole game). Neon got acquired by Databricks in 2025 and, refreshingly, the prices went down afterward. One catch to know on the free plan: scale-to-zero is mandatory, so a quiet database cold-starts after it idles. Fine for a side project, worth knowing before a user waits on that first query.

The Python-specific decision is the ORM — the layer that turns Python objects into SQL. And it splits cleanly by framework:

• On Django, you don’t decide anything. Django ships its own ORM and its own migration system, and they’re excellent. makemigrations, migrate, done. This is one of the real reasons Django exists — a huge chunk of the stack is just included.
• On FastAPI or Flask, you bring your own, because neither ships an ORM. The standard is SQLAlchemy, now on the 2.x line (2.0.51 as I write this, with 2.1 in beta) and with genuinely mature async support — which matters, because the whole point of FastAPI is not blocking while you wait. Pair it with Alembic, SQLAlchemy’s sister project, for migrations. That combo is the Django ORM’s job, assembled by hand.

If you went FastAPI because of async and AI work, use SQLAlchemy’s async engine and don’t fight it. My rule: Django hands you the ORM, FastAPI makes you buy the parts. Neither is wrong; just know which world you’re in before you start writing models.

---

Auth: The Part Everyone Underestimates

Auth is where solo founders lose a week. Again, it forks on framework.

Django gives you a full auth system for free — users, sessions, password hashing done properly, permissions, the works. For a full app, that alone can justify picking Django. You genuinely might not add a single dependency.

FastAPI gives you the primitives (OAuth2 flows, dependency injection for protected routes) but not a batteries-included user system. You either wire it up yourself with something like Authlib and hand-roll token handling, or you offload the whole problem to a hosted provider and never store a password. As a broke founder, my honest take: auth is the one place where “cheap” and “do it yourself” can quietly become “I leaked user data.” If you’re on FastAPI and you don’t enjoy security work, paying a little for managed auth — or leaning on your database provider’s auth — is money well spent. Rolling your own JWT logic at 1 AM is exactly the kind of over-engineering that sank half my projects.

---

Background Jobs: Celery, and When to Skip It

Here’s the trap I fell into. The moment I had a slow task — running that AI analysis on a batch of Clickly link data — my brain screamed “I need a task queue!” and I reached for Celery before asking whether I needed one at all.

First, the honest question: do you even need background jobs yet? If a task finishes in a couple of seconds, just await it. If it’s slow but rare, a lot of frameworks can hand it off without any extra infrastructure. Adding a queue means adding a broker, a worker process, and a whole new thing that can break at 3 AM. Don’t do it for the vibes.

When you do need it — real long-running work, LLM calls that take a minute, scheduled jobs — here’s the 2026 landscape, cheapest-brain-cost first:

• RQ (Redis Queue) — dead simple, uses Redis as the broker, roughly five minutes to set up. If your need is “run this function outside the request,” start here.
• Dramatiq — the sweet spot for a growing app. More reliable and featureful than RQ, far less ceremony than Celery, runs on Redis or RabbitMQ.
• Celery — the mature, heavy, do-everything option. Version 5.6 even validates task arguments with Pydantic now. It supports complex workflows, scheduling, and integrates tightly with Django admin. But it takes real time to operate and learn, and it pins you to specific Redis versions. Reach for it when you’ve outgrown the simpler two — not before.

All three need a broker running alongside your app, and that’s usually Redis. Upstash gives you a cheap serverless Redis if you don’t want to host one. My advice, learned the hard way: start with no queue, graduate to RQ or Dramatiq when a request is genuinely too slow, and only touch Celery when the app actually demands it.

---

Packaging: Throw Away pip, Use uv

This is the one part of the Python stack that got dramatically better recently, and if you learned Python years ago you’re probably still doing it the slow way. For a decade, Python packaging was a mess of pip, virtualenv, pip-tools, pyenv, and — if you were fancy — Poetry. Every project a different ritual, every machine slightly broken.

Then Astral — the people behind the Ruff linter — shipped uv, written in Rust, and it ate the entire toolchain. One binary replaces pip, virtualenv, pip-tools, pyenv, and most of Poetry. It’s roughly 10x faster than Poetry on the benchmarks that matter, installs in under a second, and it’s now the de facto standard — around 75 million monthly downloads, past Poetry’s ~66 million. For any new project in 2026, use uv. uv init, uv add fastapi, uv run. That’s the whole learning curve.

One thing to know so you’re not surprised later: OpenAI announced in March 2026 that it’s acquiring Astral. As I write this the deal hasn’t closed and they’re still separate companies, and OpenAI has said it’ll keep the tools open source. I’m using uv anyway — it’s open source and too good to pass up — but if that ownership makes you twitchy, Poetry 2.x is stable, community-maintained, and completely fine, especially if you’re publishing a library to PyPI. My take: uv for apps, Poetry if you’re a library author or you specifically don’t want to bet on the acquisition.

---

Where This Whole Thing Lives

Now the part the tutorials skip and a broke founder cares about most: where does it run? And the answer is the same one from my deployment tier list, because a Python backend is a long-running process and Vercel is built for JavaScript serverless functions. The second your Python app needs a persistent worker, a WebSocket, or a request that outlives a serverless timeout because a model is still thinking, Vercel fights you.

You want a container-based platform:

• Railway — my go-to. Push the repo, it detects Python, and the Hobby plan is a flat $5/month that already includes $5 of usage — so a small backend and its Redis worker cost you basically the subscription. Predictable, no per-request roulette.
• Fly.io — brilliant if you want containers close to your users with Postgres and workers alongside the web process. CLI-heavy, so not for beginners, but I love it.
• Koyeb — natively deploys Django, FastAPI, and Flask on a real always-on server for a flat fee, zero per-request billing anxiety.

The clean split for a JS person adding Python: frontend stays on Vercel, the Python backend lives on Railway or Fly, and they talk over HTTP. Same pattern I use for splitting a Node API off Vercel — the language changes, the wiring doesn’t.

---

The Whole Stack, One Table

Here’s everything above, compressed, so you can assemble it in an afternoon instead of a fortnight.

Layer	Django world	FastAPI / Flask world
Framework	Django	FastAPI (or Flask)
ORM	Built in	SQLAlchemy
Migrations	Built in	Alembic
Auth	Built in	Authlib or managed
Background jobs	RQ → Dramatiq → Celery, only when needed	Same
Database	Postgres on Neon	Postgres on Neon
Packaging	uv	uv
Hosting	Railway / Fly / Koyeb	Railway / Fly / Koyeb

Notice the pattern: Django includes the middle rows, FastAPI makes you assemble them. That’s the real trade, and it’s the same trade I argue at length in the framework post.

---

The Bottom Line

The framework debate gets all the blog posts, but it’s the shortest decision on this page. The stack around it — the ORM, the migrations, the auth, the jobs you probably don’t need yet, the packaging tool that finally doesn’t suck, the box it runs in — that’s where your weekend actually goes, and where a broke founder either stays lean or drowns.

So here’s the whole thing, no ceremony. Postgres on Neon, always. SQLAlchemy plus Alembic if you’re on FastAPI, nothing if you’re on Django. Auth you probably shouldn’t hand-roll. Background jobs only when a request is genuinely too slow, and RQ before Celery when that day comes. uv for everything you install. Railway, Fly, or Koyeb for the box. And a giant, load-bearing pile of things you deliberately don’t add yet, because the cheapest stack is the one with the fewest moving parts you have to keep alive at 3 AM.

The stack never made anyone a dollar either. Assemble the boring version and go build the thing that does. (And if you’re piecing together the whole shoestring operation, the broke solopreneur’s survival guide is the bigger picture; the database rabbit hole is where I go when Postgres genuinely isn’t enough.)

This is the Broken Engineer Guide — I over-engineer everything, fail at business, and hand you the shortcuts so you don’t have to bleed for them. Now uv run the thing and ship it.