>Django vs FastAPI: how I actually choose for a client project

Every client conversation eventually reaches the same question: "Django or FastAPI?" The honest answer is that it depends on three things that have nothing to do with which framework is trendier — the shape of the domain, the team that will maintain it, and how the service actually gets used in production.

Start from the domain, not the framework

Django earns its weight when the product is data- and admin-heavy: a back office with dozens of related models, non-technical staff who need to edit records, and a long list of CRUD screens that would otherwise be hand-built. The Django admin alone can save weeks of frontend work on an internal tool. Its ORM, migrations, and batteries-included auth mean a small team can move fast without reinventing plumbing.

FastAPI earns its weight on narrow, high-throughput services: a public JSON API, a webhook receiver, a service that fans out to Celery workers, or anything where async I/O actually matters — waiting on external APIs, streaming responses, or holding many concurrent connections open. Its Pydantic-based validation and generated OpenAPI schema also make it a strong choice whenever a frontend team needs a contract they can trust without reading the backend source.

What I actually look at before deciding

• Concurrency model. If the service spends most of its time waiting on a database, a payment gateway, or another microservice, async FastAPI (or Django with ASGI + async views) removes a whole class of thread-pool tuning problems.
• Team shape. A team that already knows Django's conventions will ship faster in Django even if FastAPI is theoretically a better technical fit — familiarity compounds.
• Surface area. A handful of endpoints with strict input/output contracts favors FastAPI's typed request/response models. A sprawling set of related resources with server-rendered admin screens favors Django.
• Long-term ownership. Who maintains this in two years? Django's stability and "the Django way" reduce bus-factor risk on projects that will outlive the original team.

The frameworks are not competitors solving the same problem — they're tools for different shapes of problem. The mistake is picking one as an identity instead of picking one per project.

How matnazar.dev is actually built

This site's API is FastAPI: async SQLAlchemy, a small, well-typed set of endpoints, and no admin screens to speak of beyond a purpose-built dashboard. That's a FastAPI-shaped problem. A previous freelance project — an inventory system for a small distributor with a dozen staff editing stock daily — was Django, because the admin and ORM did most of the work for free.

Takeaway

Match the framework to the domain, the team, and the deployment constraints — not to what's trending on social media that week. Both frameworks are mature enough that the "wrong" choice rarely kills a project; the wrong reason for the choice does.