Every SaaS boilerplate on the market does one of two things: it's all JavaScript, or it's all Django. The JS-only starters give you Next.js talking to itself. The Python starters give you Django with a React frontend bolted on as an afterthought. Both approaches leave something on the table.
I built a full-stack SaaS boilerplate using FastAPI and Next.js 15... and after comparing it against 11 competitors, I'm convinced this combination fills a gap nobody else is serving.
Why Not Just Use Next.js for Everything?
The "full-stack Next.js" approach is popular because it's simple. One language, one framework, one deployment. ShipFast, Makerkit, Supastarter... they all do this. And for a landing page with auth and Stripe, it works fine.
But the moment you need real backend logic... things get awkward.
Next.js API routes weren't designed to be a production API layer. They don't have dependency injection. They don't have request validation beyond what you manually write. They don't auto-generate OpenAPI documentation. And if you ever need to share your API with a mobile app, a CLI tool, or a third-party integration... you're retrofitting something that was built to serve HTML.
FastAPI was purpose-built for APIs. Every route gets automatic request validation via Pydantic. Every endpoint shows up in auto-generated OpenAPI docs. The dependency injection system handles auth, database sessions, and service layer patterns cleanly. Here's what an actual endpoint looks like:
@router.get("/me", response_model=UserResponse)
async def get_current_user_profile(
clerk_user: Annotated[ClerkUser, Depends(get_current_user)],
session: Annotated[AsyncSession, Depends(get_session)],
) -> User:
result = await session.execute(
select(User).where(User.clerk_id == clerk_user.clerk_id)
)
user = result.scalar_one_or_none()
# ...
Auth, database session, input validation, response serialization... all handled by the framework. No middleware chains, no manual parsing. The type hints ARE the documentation.
And the Pydantic schema is the API contract:
class UserResponse(BaseModel):
id: UUID
clerk_id: str
email: EmailStr
tier: str
created_at: datetime
model_config = {"from_attributes": True}
That schema validates the response, generates the OpenAPI spec, and maps directly from the SQLAlchemy model. One definition does three jobs.
Why Not Django?
Django's great. SaaS Pegasus has proven there's a real market for Django-based SaaS starters. But Django was designed in 2005 for synchronous, request-response web applications. It's gotten async support over the years, but it's bolted on... not native.
FastAPI is async-first. Every route handler is an async def. The database layer uses SQLAlchemy 2.0's async engine. The auth layer uses asyncio.Lock for JWKS caching. Nothing blocks the event loop because nothing was written to block in the first place.
For SaaS APIs that handle webhook processing, third-party API calls, and concurrent database operations... async isn't a nice-to-have. It's the difference between one request blocking while Stripe's API takes 200ms to respond and that request yielding to handle 50 others in the meantime.
Why Next.js 15 on the Frontend?
Because server-side rendering matters for SaaS, and React 19 is genuinely better than what came before.
Next.js 15 with the App Router gives you:
- Server components for the dashboard shell (no JS shipped to the browser for layout chrome)
- Client components where you need interactivity (forms, real-time updates)
- Middleware for auth redirects before the page even renders
- TypeScript everywhere... with strict mode
The frontend talks to FastAPI over REST. Clean separation. The backend doesn't know or care that the frontend is Next.js. The frontend doesn't know or care that the backend is Python. You could swap either side independently.
The AI Angle Nobody's Talking About
Here's the thing that made me most confident about this stack in 2026.
Python is the language of AI/ML. If you're building a SaaS that touches anything AI-adjacent... inference, embeddings, document processing, data pipelines... your backend is probably going to need Python libraries at some point. torch, transformers, langchain, numpy, pandas... they're all Python.
With a FastAPI backend, importing those libraries is just... an import statement. With a Next.js-only stack, you're now maintaining a separate Python microservice, a message queue between them, and deploying two things instead of one.
The entire point of "boring tech" is reducing moving parts. A FastAPI backend that serves your API AND runs your ML inference is one deployment. An Express backend that calls a Python sidecar is two.
What This Looks Like in Practice
Two apps, one server. FastAPI serves the API on port 8000, Next.js serves the frontend on port 3000. In production, nginx sits in front and routes /api to FastAPI and everything else to Next.js.
The SQLAlchemy models use 2.0-style Mapped types:
class User(Base, UUIDMixin, TimestampMixin):
__tablename__ = "users"
clerk_id: Mapped[str] = mapped_column(
String(255), unique=True, index=True, nullable=False,
)
email: Mapped[str] = mapped_column(
String(255), unique=True, index=True, nullable=False,
)
tier: Mapped[str] = mapped_column(
String(50), default=UserTier.FREE.value,
)
Alembic handles migrations. PostgreSQL handles the data. Clerk handles auth tokens that FastAPI validates via JWKS. Stripe webhooks hit a FastAPI endpoint that verifies signatures and processes events idempotently.
Nothing here is novel. That's the point.
The Market Gap
I looked at every commercial SaaS boilerplate I could find. 11 products. Not one combines FastAPI and Next.js 15 as a cohesive full-stack offering.
The closest is FastSaaS... which does FastAPI + PostgreSQL but doesn't include a modern frontend. And SaaS Pegasus... which does Python + React but uses synchronous Django and treats the frontend as secondary.
If you're a Python developer who wants a production-grade SaaS foundation with a modern React frontend... your options have been: build it yourself, or compromise.
I built The Unsexy Stack to fill that gap. 71 backend tests, 40 frontend tests, 17 PDF guides, 6 architecture diagrams, a 44-item security checklist. The whole thing is designed to be read, understood, and extended... not just cloned and deployed.
If you're curious about the philosophy behind it, I wrote about why boring tech wins and why 74% of startups fail from premature scaling. But that's a whole separate post.
I'm Alex Mayhew, a solo developer on Cape Cod building and shipping products. The Unsexy Stack is available at theunsexystack.com.
