I'm Muhammad Hassan. Over the past several years, I've built and shipped over 20 full-stack SaaS applications using Django on the backend and React on the frontend. Some of these have scaled to thousands of paying users. Others taught me hard lessons early. Here's what I know now that I wish I'd known at the beginning.
Architecture First, Always
The biggest mistake I see in early-stage SaaS is treating architecture as something you "figure out later." By the time you have 10,000 users, your data model is ossified and refactoring is expensive and risky.
Spend the first sprint on:
- Database schema design with multi-tenancy in mind from day one
- API contract design (REST or GraphQL — commit and be consistent)
- Authentication strategy (JWT vs session — understand the trade-offs)
- Permission model (RBAC from the start saves enormous pain later)
Django Patterns That Scale
Fat Models, Thin Views
Put business logic in models and managers, not views. Views should be thin orchestrators that validate input, call model methods, and return responses. This makes your logic testable and reusable.
Custom User Model — Always
Always create a custom user model at project start, even if you don't need custom fields today:
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(unique=True)
# ... your fields here
USERNAME_FIELD = 'email'
REQUIRED_FIELDS = []Migrating from Django's default User model after you have data is genuinely painful. Just do it from the start.
Celery for Async Tasks
Anything that takes more than 200ms should be a Celery task. Emails, PDF generation, third-party API calls, image processing — all async. Your API response times will thank you.
React Patterns That Age Well
Server State vs Client State
Separate your server state (API data) from client state (UI state) clearly. Use TanStack Query (React Query) for server state — it handles caching, revalidation, loading states, and error handling better than you will with useState/useEffect.
Compound Components for Complex UI
For complex UI elements like modals, dropdowns, and tabs, use the compound component pattern. It's far more flexible and composable than prop-drilling everything:
<Modal>
<Modal.Trigger>Open</Modal.Trigger>
<Modal.Content>
<Modal.Header>Title</Modal.Header>
<Modal.Body>Content here</Modal.Body>
<Modal.Footer>
<Modal.CloseButton />
</Modal.Footer>
</Modal.Content>
</Modal>The Mistakes I Made (So You Don't Have To)
1. Premature optimisation. I once spent 3 days optimising a query that served 12 requests per day. Profile first, then optimise.
2. Not writing tests. SaaS without tests is technical debt accumulating at compound interest. Even if it's just integration tests for critical user flows, write them.
3. Ignoring the billing system. Stripe integration sounds simple. It's not. Handle webhooks, failed payments, subscription changes, proration, and dunning properly from day one. Or use a service like Lemon Squeezy that handles more of this for you.
4. Over-engineering auth. Unless you have specific compliance requirements, django-allauth + JWT is sufficient for most SaaS products. Don't build OAuth from scratch.
The Stack I Reach For Today
- Backend: Django 5.x + Django REST Framework + Celery + Redis + PostgreSQL
- Frontend: Next.js 15 + TanStack Query + Zustand (for local state) + Shadcn/ui
- Auth: django-allauth + dj-rest-auth + SimpleJWT
- Payments: Stripe (Checkout + Webhooks + Customer Portal)
- Deployment: Railway (backend) + Vercel (frontend) + Cloudflare (CDN + DNS)
- Monitoring: Sentry + PostHog
This stack lets me (Muhammad Hassan) go from idea to deployed product in 2–4 weeks for an MVP, and it scales to 100K+ users without major architectural changes.
If you're building a SaaS product and want a technical co-founder or senior architect perspective, reach out to Muhammad Hassan.
