Hire a Django Developer: Evaluation Checklist for Founders

Hiring a Django developer is not the same as hiring “someone who knows Python.” Django products usually fail in quieter places: admin screens operators cannot use, APIs that return another account’s data, reports that block web requests, or migrations nobody reviewed. This checklist is for founders who need to judge a developer, an agency, or a fixed-scope project before committing.

You do not need to be a Django expert to use it. Each section gives you questions to ask and what a good answer tends to sound like. A strong candidate will not get every point perfect, but they will be able to explain their choices in plain language.

1. Product shape fit

Start by asking whether Django is the right tool for what you are building. Admin-heavy SaaS products, internal operations tools, content-heavy sites, and DRF-backed APIs for web or mobile clients are strong Django fits. A small async API in front of AI models, or a streaming chat backend, may be a better fit for FastAPI or a separate service.

A good candidate says this out loud instead of forcing Django everywhere. They should be able to explain the trade-off in a sentence or two, and suggest using both only when there is a clear boundary. For the longer version of that decision, see FastAPI vs Django: Which Python Framework for Your Product? and Django for SaaS: When the Batteries-Included Framework Wins.

Ask: “Would you build this in Django? What would make you choose something else?”

2. Django REST Framework competence

Most Django products today have an API for a frontend, a mobile app, or integrations. Django REST Framework (DRF) is the usual choice, and it is easy to use badly. Look for comfort with:

• Serializers as the validation boundary, with clear read and write shapes
• Authentication and permissions for SPA and mobile clients, not only session login
• Pagination, filtering, and a versioning habit before the first breaking change
• Thin views, with business rules in a service layer or model methods that can be tested on their own
• Avoiding N+1 queries with select_related and prefetch_related

Ask: “Walk me through a DRF endpoint you built. Where do permissions live, and where is the queryset filtered?” A clear answer names specific places in the code. A vague answer usually means the logic is scattered. Django REST Framework Patterns for Product APIs covers what a tidy structure looks like, and Designing Clean Python Service Layers explains the service-layer idea.

3. Admin quality, not default screenshots

Django Admin is one of the main reasons to choose Django, but the default admin is a starting point, not a product. Your support and operations staff will live in it. Look for:

• Useful list columns, search fields, and list filters for the questions staff actually ask
• Inlines for related records that need to be edited together
• Bulk actions that are safe, confirmed, and logged
• Read-only fields and permissions so staff cannot change what they should not
• Admin pages that stay fast when a table has many rows

Ask: “Show me an admin you customised. What did operators use it for?” See Django Admin as an Internal Operations Tool for the patterns worth expecting.

4. Celery and background work

Imports, exports, month-end reports, emails, webhooks, OCR, and LLM calls should not run inside a web request. If they do, users wait, requests time out, and a slow third party can take the site down with it. Ask how the candidate structures background work:

• Which queue they use (Celery with Redis or RabbitMQ, or a simpler option) and why
• Retries with backoff for calls that can fail temporarily
• Idempotent tasks, so a retried job does not send two emails or charge twice
• How failed jobs are surfaced: logs, alerts, or a status field staff can see
• Scheduled jobs and what happens if one is missed

Ask: “A task fails halfway through. What happens next?” The answer should mention retries, idempotency, and how someone finds out. Background Jobs in Python: Celery vs Simpler Queues goes deeper.

5. Postgres and the data model

Django’s ORM makes it easy to start, and just as easy to build a schema that is hard to change later. A good Django developer treats the data model as part of the product design. Look for:

• Constraints and indexes in the database, not only validation in forms
• Comfort with Postgres features when they help, such as JSON fields, full-text search, or partial indexes
• Migrations reviewed like product changes, with a plan for large tables and data backfills
• Transactions around operations that must succeed or fail together
• Reading the SQL the ORM generates when a page or report is slow

Ask: “How would you add a required column to a table that already has a lot of rows?” A careful answer splits it into steps: add the column as nullable, backfill, then add the constraint.

6. Tenancy safety

If your product has accounts, workspaces, or organisations, the most serious bug is one customer seeing another customer’s data. “We filter in the template” is a red flag. Filtering belongs in querysets, permissions, and tests, so that forgetting it in one view is hard to do.

class InvoiceViewSet(viewsets.ModelViewSet):
    serializer_class = InvoiceSerializer
    permission_classes = [IsAuthenticated, IsAccountMember]

    def get_queryset(self):
        # Every query starts from the caller's account.
        return Invoice.objects.filter(account=self.request.user.account)

This is only one approach. Others include a custom manager, row-level security in Postgres, or schema-per-tenant libraries. What matters is that the candidate can explain where the boundary is enforced and how a test proves it.

Ask: “How do you make sure an API never returns another account’s records?”

7. Tests and deploy habits

You are not looking for a coverage number. You are looking for tests on the things that would hurt if they broke, and a repeatable way to ship.

• pytest (or Django’s test runner) for critical models, permissions, APIs, and background jobs
• At least one test that tries to read another tenant’s data and expects a refusal
• A reproducible local setup, often Docker, so a second developer can start quickly
• Settings and secrets from the environment, not committed to the repository
• A staging check before production, and a rollback plan for migrations

Related reading: pytest for API Developers: What to Test First and Dockerizing Python APIs for Local and Production.

8. Communication and ownership

Django work often reaches beyond code: admin workflows need explaining to staff, API contracts need agreeing with frontend or mobile developers, and data changes need sign-off. You want someone who can:

• Break work into milestones you can review, not one large delivery at the end
• Raise risks early, such as a migration that needs downtime or a vague requirement
• Write short notes on admin workflows and API endpoints
• Say “I don’t know yet, I’ll check” instead of guessing

A simple way to run the evaluation

1. Short call: ask the product-fit question and listen for trade-offs, not enthusiasm.
2. Code walkthrough: have them explain a past DRF endpoint, admin, or Celery task they wrote. Real production code, even partly redacted, tells you more than a portfolio page.
3. Small paid task: a few hours on something real, such as one endpoint with permissions and tests, shows how they work and communicate.
4. Milestone plan: ask for a first-milestone outline. A good plan names risks and decisions, not only features.

Red flags

• No opinion on Django vs FastAPI trade-offs
• Business logic dumped into views or admin save methods without structure
• No plan for background jobs, or heavy work inside requests
• Cannot explain how tenancy filtering is enforced
• Migrations treated as an afterthought
• Portfolio shows only tutorials, never production constraints

Summary

Hire for Django products that are safe to operate: product-fit judgement, DRF discipline, a usable admin, reliable background jobs, a careful data model, tenancy safety, and tests on the parts that matter. Framework trivia is secondary. A developer who can explain these choices clearly is usually one who can also maintain them.

If you are evaluating a Django project or want a second opinion on a plan, get in touch.