Next.js owns the product UI
React and TypeScript make it practical to build interactive screens, compose a design system, and keep frontend work focused.
SaaS Hammer reference architecture
Django + Next.jsSaaS Architecture
A fast React product UI paired with Django's business core, without infrastructure you do not need on day one.
System at a glance
Reference pattern
Browser
Interactive SaaS UI
HTTPS requests
Next.js + React
Product interface and TypeScript UI
Explicit API contract
Django + DRF
Business rules, permissions, and data operations
PostgreSQL
Application data
Redis + Celery
Async work and schedules
Boundaries
Next.js for the interface. Django for the core.
Each side owns its own concerns and meets the other at one contract.
Django owns the business core
Domain rules, data access, permissions, admin workflows, and API operations stay close to Django conventions.
Token boundary
Auth crosses an explicit token boundary.
The UI presents a short-lived identity token. Django verifies it before every protected API operation.
Reference implementation
A bearer token, not a browser session.
Next.js attaches a short-lived identity token to each request. Django validates it, resolves the user, and enforces permissions at the API boundary.
Design rule
CORS uses an exact origin allowlist, never a wildcard. Every token and permission is still verified at the API boundary.
API and background work
The API and the worker are first-class.
DRF is the contract between the UI and the domain. Celery keeps slow work out of the request path.
Reference pattern
A deliberate DRF API boundary
Django validates input, applies permissions, and coordinates the domain. Next.js calls a stable contract instead of reaching into backend internals.
Recommended production pattern
Celery handles work that should not block users
A request dispatches work, workers execute it, and Beat schedules the recurring jobs. Imports, emails, syncs, reports, and retryable AI jobs all live here.
Topology
Same boundaries, local and production.
How you host it is a deployment choice. That each concern runs, scales, and fails on its own is not.
Local development
Run the web app, Django API, database, Redis, and worker processes with clear responsibilities. Request, task, and data failures stay easy to isolate.
Production topology
HTTPS in front of Next.js and Django, PostgreSQL private, and Redis, workers, and scheduled jobs as separate services.
Comparison
Match the architecture to the product.
Django + Next.js is the default SaaS Hammer builds toward. It is not a universal winner.
Alternative
Pure Django templates
Best when
The interface is server-rendered, interactions are modest, and one Python codebase keeps the team moving.
Trade-off
Rich product UI and independently evolving frontend workflows can become harder to organize.
SaaS Hammer default
Django + Next.js
Best when
You need a React product UI while keeping Django for domain logic, data, permissions, and operations.
Trade-off
You own an API contract, two development environments, and an intentional auth strategy.
Alternative
Pure Next.js backend
Best when
Your team is all-in on TypeScript and the backend scope is small enough for its chosen server runtime.
Trade-off
You give up Django conventions and may need to assemble admin, ORM, background work, and operations separately.
Pre-flight
Validate the seams first.
Four checks worth passing before committing screens, contracts, and infrastructure to the stack.
Choose an auth model first
Decide how the UI and the API trust each other before building screens around it.
Treat the API as a versioned contract
It is a product surface with consumers, not an internal shortcut.
Move slow work off the request path
Anything heavy or retryable belongs in a worker, not the web request.
Decide what runs together
Know which services share a machine locally and run independently in production.
Next steps
Start with a foundation you can reason about.
Explore the SaaS Hammer boilerplate, then use the docs to decide which reference patterns belong in your product.