If you searched for SaaS Pegasus HTMX support or a modern Django + HTMX SaaS framework, the short answer is: yes, SaaS Pegasus is the strongest paid Django SaaS boilerplate with first-class HTMX mode today. Its public site describes a choice of React or HTMX front end plus teams, subscription billing, APIs, async/WebSocket support, deployment guidance, and a Django codebase built for SaaS rather than a blank scaffold.
That does not make Pegasus the automatic pick for every Python team. Django Rocket is a leaner documented Django starter, djaodjin is still the free billing-first framework to inspect, Cookiecutter Django is the safer scaffold when you want to own every SaaS decision, and smaller HTMX-first starters can be useful for MVPs.
This guide stays narrowly focused on Django + HTMX SaaS boilerplates: which starter gives you usable auth, billing, teams, background jobs, deployment defaults, and HTMX-friendly server-rendered workflows. For a broader Rails/Laravel/Django framework decision, use the adjacent framework comparison instead of treating this page as a general web-framework ranking.
TL;DR
SaaS Pegasus is the best Django + HTMX boilerplate when you have budget and want the SaaS layer mostly assembled: public pricing starts at $249 one-time, and the product page advertises React-or-HTMX frontend choice, teams, billing, APIs, async/WebSocket support, deployment docs, and a commercial support surface. Django Rocket is the leaner Python-first pick when you want a smaller Django SaaS starter with documented Stripe setup, Google sign-in setup, Celery, Docker, Postgres, Redis, OpenSearch, and tests without buying into a larger framework. djaodjin is the best free option if multi-tenant billing is the core requirement. Cookiecutter Django is the right foundation if you're building custom. django-saas-starter handles MVPs on zero budget.
For this search intent, the decision is simple: pick Pegasus when "HTMX support" means a paid SaaS kit with teams, billing, and maintained docs; pick Cookiecutter/Falco/Hyperion when "modern Django + HTMX framework" means a clean server-rendered foundation you will extend yourself.
Key Takeaways
- SaaS Pegasus is the clearest paid answer for the
saas pegasus htmxquery: its public product page advertises a React-or-HTMX frontend choice, teams, billing, APIs, async/WebSocket support, and deployment guidance - Django Rocket is the lean Python SaaS starter to shortlist when you want Django, Stripe setup, Celery, Docker, Postgres, Redis, search, and tests without a heavy commercial framework
- Modern HTMX support should mean HTMX 2.x-compatible patterns, partial-template responses, progressive enhancement, and a plan for WebSocket/SSE features where the product needs them
- Python AI/ML is the killer advantage — Django + HTMX lets Python teams keep LLM, data, and background-job code close to the product instead of splitting the app into a separate JavaScript frontend and Python service layer
- djaodjin's URL-based multi-tenancy is the most battle-tested free multi-tenant approach in the Django ecosystem
- Cookiecutter Django is a scaffold, not a boilerplate — it creates a solid structure but adds no SaaS features (billing, multi-tenancy, etc.)
- The paid-vs-free decision reduces to whether teams, billing, emails, deployment docs, and update/support access save more engineering time than the license cost
What "SaaS Pegasus HTMX support" means in practice
Searchers often use "SaaS Pegasus HTMX" because they are trying to answer a buying question, not a syntax question. Pegasus is relevant because the product page advertises a choice of React or HTMX for interactive pages rather than requiring a React dashboard. That matters if your team wants Django templates, server-rendered forms, and small interactive islands while still buying a SaaS kit.
For due diligence, check four Pegasus details before purchase:
| Question | Why it matters |
|---|---|
| Does the download support HTMX for the screens you actually need? | Marketing-site support is not the same as billing/team/admin flows that match your product. |
| Which tier includes the features you need? | Public pricing starts at $249, while higher tiers add more capability and licensing scope; verify the current checkout page before buying. |
| Are teams, invitations, roles, and billing modeled the way your SaaS needs them? | Retrofitting tenant or billing assumptions later can erase the boilerplate time savings. |
| How current are the docs and dependencies? | Django and HTMX both move; choose a starter with an update path, not a frozen code dump. |
Pegasus remains the best top pick for this guide because it answers the intent behind "modern Django + HTMX SaaS framework": a paid Django codebase with SaaS primitives, HTMX-friendly rendering, and enough commercial maintenance to reduce launch risk.
Why Django + HTMX for SaaS in 2026?
Django + HTMX is compelling for Python SaaS teams because it keeps the product loop mostly inside Django: URL routing, ORM, auth, admin, sessions, forms, templates, and background jobs stay close together, while HTMX adds partial-page interactivity through HTML attributes instead of a separate SPA application.
That does not eliminate every frontend tool. Some starters still use Tailwind, Alpine.js, asset bundlers, or small JavaScript helpers. The advantage is that the core product screens can remain server-rendered Django workflows instead of React-first client applications.
The ecosystem is still fragmented. Some "boilerplates" are glorified scaffolds. Some are production-tested SaaS frameworks. Some have unclear update cadence. This guide ranks Django + HTMX SaaS starters by whether they help you ship a paid product: auth, billing, teams, admin, background jobs, deployment, and current docs.
What HTMX actually changes in a SaaS UI
Traditional Django SaaS screens usually choose between full-page server rendering and a separate React/Vue frontend. HTMX gives you a third path: keep business state in Django, return partial HTML for interactive regions, and avoid building duplicate JSON endpoints for routine product workflows.
That is most valuable for SaaS screens such as live search, table filters, team invites, billing-plan changes, settings panels, and modal form validation. These flows need fast feedback, but they rarely need a full client-side app. The due-diligence question for any Django HTMX SaaS boilerplate is whether it demonstrates those partial-response patterns in real product screens, not only in a toy demo.
<!-- Search results update without a React/Vue app or a custom JSON layer -->
<input
type="text"
name="q"
hx-get="/teams/acme/members/search/"
hx-trigger="keyup changed delay:300ms"
hx-target="#member-results"
placeholder="Search team members..."
/>
<div id="member-results"></div>
Django + HTMX SaaS stack:
Backend: Django 5.x — routing, ORM, auth, admin, sessions, forms
Database: PostgreSQL via psycopg3 (or SQLite for development)
Auth: django-allauth — email, Google, GitHub, MFA, passkeys
Frontend: HTMX 2.0 — partial HTML swaps, no JavaScript framework
Interactivity: Alpine.js 3 — lightweight client-side state where needed
Styling: Tailwind CSS 4 (or Bootstrap 5 for legacy projects)
Background: Celery + Redis — async tasks, scheduled jobs
Billing: Stripe via djstripe or django-stripe
Deployment: Gunicorn + Nginx, Railway, Render, or Fly.io
Compare this to package.json in a Next.js T3 stack — often 40+ dependencies — and the Python side looks refreshingly lean.
Modern HTMX support: what to verify
The HTMX docs describe a small dependency that exposes AJAX, CSS transitions, WebSockets, and Server-Sent Events directly through HTML attributes. For a 2026 Django SaaS starter, "HTMX support" should therefore mean more than adding one CDN script tag:
- templates are organized so full-page and partial responses are easy to maintain;
- forms, filters, invites, billing-plan changes, and settings panels progressively enhance instead of requiring JavaScript for the first render;
- the starter has a documented pattern for
HX-Requestor equivalent request detection; - WebSocket or SSE features have a clear extension path rather than a custom front-end island for every live update;
- the dependency target is HTMX 2.x-compatible, not an abandoned HTMX 1.x demo.
A representative partial-response pattern looks like this:
# Django view: full page for direct visits, partial HTML for HTMX swaps
from django.shortcuts import render
def member_list(request, team_slug):
members = load_team_members(team_slug)
template = "teams/partials/member_list.html" if request.headers.get("HX-Request") else "teams/member_list.html"
return render(request, template, {"members": members})
The Comparison
| Starter | Price | HTMX | Multi-Tenant | Auth | Billing | AI | Django |
|---|---|---|---|---|---|---|---|
| SaaS Pegasus | Starts at $249 | ✅ React or HTMX choice | ✅ Teams + RBAC | Full (allauth + MFA/passkeys advertised) | Stripe + Paddle advertised | ✅ Higher-tier AI features advertised | 5.x-oriented |
| Django Rocket | Paid / Apache 2.0 codebase docs | ⚠️ Django templates first | ⚠️ Build yourself | Google sign-in setup | Stripe setup | ⚠️ Add yourself | 5.x-oriented |
| djaodjin | Free (BSD*) | ⚠️ Add yourself | ✅ URL-based | ✅ Built-in | Stripe native | ❌ | 4.x/5.x |
| Cookiecutter Django | Free (BSD) | ⚠️ Add yourself | ❌ | allauth | ❌ | ❌ | 4.x/5.x |
| Falco | Free (MIT) | ✅ Configured | ❌ | allauth | ❌ | ❌ | 5.x |
| Hyperion | Free (MIT) | ✅ HTMX-first | ❌ | allauth | Stripe | ❌ | 5.0 |
| cangeorgecode | Free + Paid | ✅ HTMX-first | ❌ | allauth | Paid tier | ❌ | 5.x |
| Community starters | Free | ✅ | ❌ | allauth | Stripe | ❌ | 4.x/5.x |
The Starters, Ranked
1. SaaS Pegasus — Best Overall
Price: Starts at $249 one-time (verify current tier pricing at checkout) Creator: Cory Zue GitHub: Private repository (download on purchase) Positioning: Commercial Django SaaS boilerplate with user management, teams, subscription billing, APIs, deployment docs, and React-or-HTMX frontend choice
SaaS Pegasus is the only premium Django boilerplate that offers configurable frontend mode — you choose React or HTMX when you download. The HTMX mode is first-class, not an afterthought.
What you get in HTMX mode:
# Pegasus uses class-based views with HTMX partial returns
class TeamMembersView(LoginRequiredMixin, PermissionRequiredMixin, View):
"""Handles team member management with HTMX partial renders."""
def get(self, request, team_slug):
team = get_object_or_404(Team, slug=team_slug)
members = team.membership_set.select_related("user").all()
# Full page render for direct visits
return render(request, "teams/members.html", {"team": team, "members": members})
def post(self, request, team_slug):
form = InviteForm(request.POST)
if form.is_valid():
invitation = send_invitation(team, form.cleaned_data["email"])
# Partial HTML return for HTMX requests
return render(request, "teams/partials/member_row.html", {"invitation": invitation})
return render(request, "teams/partials/invite_error.html", {"form": form})
Full feature list to verify against your tier:
- Auth: django-allauth-based authentication with social login and modern account features advertised
- Teams/Orgs: Multi-tenant team/organization model with invitations and role-based access control advertised
- Billing: Stripe and Paddle subscription/payment support advertised
- Admin: Django admin and support tooling patterns
- Background: Celery/Redis-style async task guidance and async/WebSocket support advertised
- AI: AI features are advertised on higher-tier/product pages; verify whether they matter for your project
- APIs: Django REST Framework/API patterns advertised
- Deployment: deployment documentation and multiple hosting paths
- Frontend: Tailwind/DaisyUI-style UI with React or HTMX as the interactive frontend choice
Pricing check: Pegasus public pricing was rechecked on 2026-05-15 and starts at $249 one-time, with higher tiers for broader feature/license needs. Treat any exact tier table as volatile: confirm the current product page and checkout before budgeting.
Verdict: If teams, billing, invites, account flows, deployment docs, and update/support access save even a few days of senior Django time, Pegasus is usually the rational paid choice. If you only need a clean Django project and want to build the SaaS layer yourself, start with Cookiecutter Django, Falco, Hyperion, or Django Rocket instead.
2. Django Rocket — Best Lean Django SaaS Starter
Price: Paid Best for: Python teams that want a smaller Django SaaS foundation with batteries included but not a heavyweight product framework. Review: Django Rocket review 2026
Django Rocket is the most relevant newer addition to this shortlist because it sits between Cookiecutter Django and a larger commercial kit. Its docs show a conventional Django project with modules such as auth, billing, search, and utilities, plus setup paths for Stripe products, Google sign-in, Docker services, Postgres, Redis, OpenSearch, Celery, pytest, Tailwind dependencies, and environment files.
That makes Django Rocket a good fit when you want real SaaS plumbing but still prefer to understand and own the codebase. It is not trying to be a no-code product builder or a full enterprise platform. Treat it as a lean Django SaaS starter that gives you a cleaner launch path than wiring every app from scratch.
Best fit: Solo developers and small Python teams building a focused SaaS where Django templates, Django admin, Celery, Stripe, and a conventional backend matter more than a polished JavaScript dashboard.
Watch-outs: Validate the exact update cadence, license terms, and included frontend mode before buying. If you need deep teams/RBAC, multiple billing providers, or premium support, compare it directly with SaaS Pegasus before committing.
3. djaodjin — Best Free Billing-First Framework
Price: Free (BSD license) Creator: DjaoDjin Inc (runs their own SaaS on it) GitHub Stars: ~1.2k Django: 4.x/5.x compatible
djaodjin is the most complete free Django SaaS framework — and it's battle-tested because the creators run real SaaS businesses on top of it. The architecture is split into composable Django apps:
djaodjin-saas— subscriptions, billing, multi-tenancy, and reportingdjaodjin-signup— authentication with Stripe-aware flowsdjaodjin-pages— CMS-style page managementdjaodjin-rules— declarative access control
The standout feature: URL-based multi-tenancy
djaodjin uses URL prefixes for organization isolation. Each tenant gets their own URL namespace (/orgs/acme/billing/) and access rules are managed in the database, not in code:
# djaodjin-rules: define access in settings, not scattered across views
RULES = [
# managers can POST to /api/, subscribers can only GET
("/api/", {"POST": "manager", "GET": "subscriber"}),
# only managers can access billing
("/billing/", {"ANY": "manager"}),
# profile pages accessible to all authenticated users
("/profile/", {"ANY": "authenticated"}),
]
This is a fundamentally different approach from per-view @permission_required decorators — the rules are centralized and database-driven, so non-technical admins can adjust them.
HTMX integration: djaodjin's templates use older jQuery-style JavaScript in places, but the server-side rendering architecture maps cleanly to HTMX patterns. Adding HTMX is straightforward — the template structure already returns partials where needed:
# djaodjin view returns HTML partials on AJAX requests
class UserRelationListView(ListView):
def get_template_names(self):
if self.request.headers.get("HX-Request"):
return ["saas/htmx/subscriber_list.html"] # partial
return ["saas/subscriber_list.html"] # full page
Verdict: If you need multi-tenant billing without paying for Pegasus, djaodjin is the answer. The DX is less polished than modern stacks, but the billing and access control implementation is genuinely production-grade.
4. Cookiecutter Django — Best Project Scaffold
Price: Free (BSD) Creator: Daniel Feldroy (Two Scoops of Django) GitHub Stars: 22k+ Django: 4.2 / 5.x
Cookiecutter Django is the most-starred Django project generator — but it's important to understand what it is: a scaffold, not a SaaS boilerplate. It doesn't include billing, multi-tenancy, or production SaaS UI. It creates a well-structured Django project foundation:
- Docker Compose for local development
- PostgreSQL + psycopg3 configured
- Celery + Redis setup
- django-allauth for authentication
- Custom user model (the right default)
- WhiteNoise for static files
- Pre-commit hooks + GitHub Actions CI
Adding HTMX to a Cookiecutter project:
pip install django-htmx
# settings.py
INSTALLED_APPS = [
...
"django_htmx",
]
MIDDLEWARE = [
...
"django_htmx.middleware.HtmxMiddleware",
]
<!-- base.html: add HTMX 2.0 -->
<script src="https://unpkg.com/htmx.org@2.0.4" crossorigin="anonymous"></script>
<!-- Optional: Alpine.js for client-side interactivity -->
<script src="https://unpkg.com/alpinejs@3.x.x/dist/cdn.min.js" defer></script>
# views.py: check request.htmx to return partial vs full page
from django_htmx.http import retarget
def search_view(request):
q = request.GET.get("q", "")
results = Product.objects.filter(name__icontains=q)[:10]
if request.htmx:
# Return just the results partial
return render(request, "partials/search_results.html", {"results": results})
# Return the full page
return render(request, "search.html", {"results": results, "q": q})
Verdict: Use Cookiecutter if you have an experienced Django team that knows what you need and wants to build it your way. Use Pegasus or djaodjin if you need SaaS features shipped fast.
5. Falco — Best Minimal HTMX Starter (Free)
Price: Free (MIT) GitHub Stars: ~1k Django: 5.x HTMX: Pre-configured
Falco is a newer, opinionated Django starter that targets the modern stack: Django 5, HTMX 2.0, Alpine.js, Tailwind CSS 4, and htmx-ext extensions pre-configured. Unlike Cookiecutter, Falco includes a Makefile-driven development workflow and sensible defaults for Django deployment.
What Falco adds over Cookiecutter:
- HTMX + Alpine.js pre-integrated (not add-it-yourself)
- Tailwind CSS 4 with PostCSS configured
django-cottonfor component-based templatesdjango-browser-reloadfor hot reloading during development- Production-ready deployment scripts for VPS
What it lacks:
- No billing integration
- No multi-tenancy
- No pre-built SaaS UI
Verdict: Best free choice if you want the HTMX ecosystem pre-configured and plan to build custom SaaS features on top of it.
6. Hyperion (eriktaveras) — Best Free HTMX-First Starter
Price: Free (MIT) + paid premium version GitHub: github.com/eriktaveras/django-saas-boilerplate Stars: 83+ Django: 5.0
Hyperion is a purpose-built HTMX-first Django starter — not a Cookiecutter fork, not a paid product with a stripped-down free tier. Just clean Django 5 + HTMX + Tailwind + Stripe that the developer built for his own SaaS products and open-sourced.
Stack: Django 5.0, HTMX (no React option), Tailwind CSS, Alpine.js, PostgreSQL, django-allauth, Stripe subscriptions + one-time payments + trial periods, role-based access control, responsive dashboard.
Three-command setup to running server. The creator published a detailed write-up on DEV.to explaining the architecture — good due diligence read before forking.
Verdict: Best free choice if you want a modern HTMX-first stack with no React distraction and plan to build custom features on top.
7. cangeorgecode Django Boilerplate
Price: Free (open-source) + paid premium GitHub: github.com/cangeorgecode/Django_Boilerplate_Free Django: 5.x
Built by a developer who used it to ship 4 apps in 2 months. The free version covers Django 5, HTMX, Tailwind, and email auth. The paid version adds Wagtail CMS (same CMS option as SaaS Pegasus) and Stripe billing.
Notable: 63+ stars in the first 2 days after launch — strong signal for a niche boilerplate. HTMX-first with no React option. Wagtail bundled for content/blog features.
Verdict: Worth evaluating if you want HTMX + Wagtail CMS without the Pegasus price tag. Smaller community; paid tier pricing is not publicly listed.
8. Community Starters
Additional options for MVPs and learning:
- PaulleDemon/Django-SAAS-Boilerplate — Free, Firebase storage, Stripe, i18n built-in, deploys to Vercel/Railway/Render
- danjac/django-saas-starter — Opinionated cookiecutter variant for SaaS
- ernestofgonzalez/djangorocket — Cookiecutter-based, Stripe + Tailwind + allauth
Audit GitHub before committing — check last commit date, Django version (5.x?), and whether HTMX 2.x is used. Some haven't been updated since 2024.
Django + HTMX vs Django + React: The 2026 Decision
For most B2B SaaS, HTMX is sufficient — and often superior:
| Scenario | HTMX wins | React wins |
|---|---|---|
| Solo Python developer | ✅ One language, one mental model | — |
| Python AI/ML SaaS | ✅ Direct access to ML libraries | — |
| B2B dashboard (tables, forms, filters) | ✅ Less code | — |
| Internal tools | ✅ Build speed over UX polish | — |
| Content-heavy app | ✅ Server rendering is natural | — |
| Consumer mobile-first | — | ✅ Native-like interactions |
| Offline-capable app | — | ✅ Client-side state |
| Large JS team exists | — | ✅ Leverage existing skills |
| Real-time collaborative editing | — | ✅ Complex client state |
| React Native mobile app | — | ✅ Code sharing |
The Python AI/ML angle is decisive in 2026. If your SaaS integrates LLMs, vector search, data pipelines, or ML models, Django + HTMX lets you call langchain, openai, chromadb, and scikit-learn directly from your Django views — no microservice layer, no API bridge between Python and JavaScript, no serialization overhead. This alone makes Django + HTMX the correct default for AI-powered SaaS built by Python teams.
Production Stack Reference
A complete, production-ready Django + HTMX SaaS stack in 2026:
Layer Technology
─────────────────────── ──────────────────────────────────────────
Web framework Django 5.x
Database PostgreSQL 16+ via psycopg3
ORM Django ORM (built-in)
Authentication django-allauth 0.63+ (email, OAuth, MFA, passkeys)
Billing djstripe 2.9+ or Pegasus billing
Background tasks Celery 5.x + Redis 7
Task scheduling Celery Beat
Cache Redis 7 (cache backend)
Frontend interactivity HTMX 2.0 + Alpine.js 3.x
Styling Tailwind CSS 4 (or Bootstrap 5)
Static files WhiteNoise (dev) → S3/CloudFront (production)
File uploads django-storages → S3
Email django-anymail → SendGrid/Postmark/Resend
Search django-watson or PostgreSQL full-text search
WSGI server Gunicorn 21+
Reverse proxy Nginx (self-hosted) or Caddy
Hosting Railway, Render, Fly.io, or VPS
Container Docker + Docker Compose
Python dependencies for a full SaaS (requirements.txt):
django>=5.0
django-allauth[socialaccount]
django-htmx
celery[redis]
redis
psycopg[binary]
stripe
djstripe
gunicorn
whitenoise
django-environ
django-storages[s3]
django-anymail
pillow
Compare to a Next.js T3 stack: 40+ npm packages, TypeScript config, Prisma schema, NextAuth config, bundle optimization — the Python side is dramatically simpler.
Who Should Use Each
SaaS Pegasus — Python developers who want to ship fast and have budget for a paid starter. The value case is strongest when teams, billing, onboarding, emails, background tasks, and deployment docs would otherwise consume the first several build days. Ideal for: indie hackers, B2B SaaS founders, Python teams with a product to build.
Django Rocket — Python teams that want a leaner documented Django SaaS starter with Stripe, Google sign-in, Celery, Docker, Postgres, Redis, OpenSearch, Tailwind, and test setup paths, but are comfortable validating support and extending teams/RBAC themselves.
djaodjin — Developers who need multi-tenant billing without the cost. Takes more configuration than Pegasus but the billing and access control system is production-proven. Ideal for: bootstrapped projects, teams that want full source control without a license.
Cookiecutter Django — Teams with Django expertise building something custom. The scaffold gives you production defaults; you add the SaaS features you need. Ideal for: consulting shops, teams with specific architecture requirements.
Falco — Developers who want a modern Django + HTMX foundation (HTMX 2.0, Tailwind 4, Alpine.js configured) but don't need billing included. Ideal for: custom SaaS builds where you'll integrate your own billing.
Community starters — MVP validation and learning projects. Ideal for: proving concept before investing in Pegasus.
Browse all Django + HTMX boilerplates on StarterPick — filter by price, features, and frontend framework.
Related: SaaS Pegasus Review 2026 · Django vs Rails SaaS Starters · Best SaaS Boilerplates 2026
Source and claim notes (checked 2026-05-15)
- SaaS Pegasus public site and docs: checked for React-or-HTMX frontend choice, teams, subscription billing, APIs, async/WebSocket support, deployment documentation, and public pricing starting at $249. Pricing and tier packaging are volatile, so this guide uses "starts at" language and tells buyers to confirm checkout.
- Django 5.2 docs and release notes: checked as the current official Django docs surface for the Django 5.x references used here.
- HTMX official docs: checked for the current description of AJAX, CSS transitions, WebSockets, and Server-Sent Events through HTML attributes; this guide avoids over-specific release-date claims.
- Django Rocket docs: checked at
djangorocket.comfor the documented project structure, Stripe setup, Google sign-in setup, Docker/Postgres/Redis/OpenSearch/Celery/test/Tailwind paths, and Apache 2.0 license note. - GitHub project pages checked for Cookiecutter Django, djaodjin-saas, Falco, Hyperion, cangeorgecode Django Boilerplate, PaulleDemon/Django-SAAS-Boilerplate, danjac/django-saas-starter, and ernestofgonzalez/djangorocket. Star counts and exact update cadence are intentionally treated as volatile and should be rechecked before adoption.
- Duplicate/adjacent guide risk: this page intentionally stays on Django + HTMX SaaS boilerplates. For a general framework choice, use the Django/Rails/Laravel comparison rather than broadening this article.
Search Intent Refresh: SaaS Pegasus HTMX Support
Searchers comparing Django + HTMX SaaS starters usually want to know whether they can ship a paid SaaS without adopting a heavy JavaScript stack. SaaS Pegasus is the most direct fit when you want a commercially supported Django starter with HTMX patterns, billing, teams, and production guidance. Cookiecutter Django is better as a flexible foundation when you want to assemble more of the SaaS layer yourself.
Decision checklist:
- Pick a paid starter if auth, billing, teams, emails, deployment docs, and updates save more time than the license costs.
- Pick an open foundation if your team already has strong Django conventions and does not want starter lock-in.
- Prototype the hardest interactive screen with HTMX before committing to the architecture.
- Check whether the starter's Stripe, email, background job, and deployment choices match your production plan.
- Treat "Django + HTMX" as a product-speed choice, not just a frontend preference.