Not Just Another AI-Built App - Why I’m Taking the Long Road?

Saasboilerplate Fullstackdevelopment Django

Part 1 - Not Just Another AI-Built App: Why I’m Taking the Long Road? This series is for beginner developers, indie hackers, and experienced engineers who want to build production-ready SaaS applications from the ground up - not just MVPs that work, but systems that last. If you're curious about combining traditional software engineering with modern AI-assisted workflows (without surrendering control to a black box), you're in the right place.

Sun Aug 03 2025
8 min read
Not Just Another AI-Built App - Why I’m Taking the Long Road?
“Take the long road - with a map.”
In a world where AI can spit out a full-stack app in minutes, you might be wondering: Why would anyone choose to build a SaaS boilerplate from scratch - and in public?
Welcome to VAS-DJ - short for Validated App Stack for Dreamers & Jackers(Jackers = tinkerers, not hackers).
I think I can come up with a much better name - but the whole point of this build it not the name or branding - as that will change as per the boiler plate implementation
This isn’t just another starter kit to get you from zero to MVP in a weekend. It’s a deliberate attempt to create a foundation that lasts beyond the honeymoon phase, built with an opinionated philosophy, transparent decision-making, and just enough AI assistance to accelerate without losing control.

Why Not Just Use an Existing Boilerplate?

Over the years, I’ve explored and learned from many SaaS boilerplates - open-source and commercial. Each has its strengths, and some are excellent if your needs align closely with what they offer.
But I noticed recurring patterns in how they’re built and where they tend to shine or struggle:

🏃‍♂️ Optimized for the First Mile

Many are fantastic for getting something live quickly, but the architecture often favors speed over long-term maintainability. You can get a “Hello World” up quickly, but evolving the app for complex use cases may require serious rewrites.

🔒 Limited Transparency

Some commercial kits are proprietary black boxes. They can be polished and feature-rich, but when you want to customize deeply, you’re left reverse-engineering choices you didn’t make.

🎯 Narrow Focus

A lot of boilerplates are designed for the simplest SaaS patterns: single-platform, basic CRUD flows, minimal integrations. If you need advanced multi-tenancy, offline-capable mobile apps, or AI-powered features, you’ll have to add them yourself - often reworking the core architecture.

💰 The Paywalled Gems

There are also paywalled boilerplates that are genuinely excellent - polished, well-documented, and thoughtfully engineered. If your project fits their architecture and constraints, they can save you weeks or even months of work.
But I wanted something built to my specific preferences and philosophy, where I understand and own every architectural decision. Hopefully to keep learning and improve this system as long as possible.

AI as a Tool - Not the Driver

I’ve spent over a decade building and scaling enterprise systems, and one lesson is clear: shortcuts without guardrails rarely scale well.
AI can be an incredible productivity multiplier, but only if used with intention:
As a copilot to suggest, scaffold, and accelerate - not as an unsupervised coder.
To automate repetitive tasks, surface design options, and help debug - while I retain architectural oversight.
I work within guardrails that ensure the codebase stays maintainable, secure, and consistent.
I’m not asking AI to build the project for me, or even using it for one-shoting the a given feature. I’m using it like a sous-chef: speeding prep, suggesting techniques, but never plating the dish. I’m using it the way an experienced chef might use a sous-chef: prep the ingredients, keep the tools sharp, suggest a new technique - but the final dish is still my creation.
The VAS-DJ Philosophy Instead of chasing the fastest route to an MVP, I’m optimizing for learning and extensibility.
The Dreamers & Jackers
  • 🌟 Dreamers - Visionaries who want to focus on product, not plumbing.
  • 🔧 Jackers - Tinkerers who enjoy going under the hood and shaping the system.
Most boilerplates serve one camp or the other. VAS-DJ serves both.
Core Principles
  • 💡 Build Intentionally - Choose boring, proven tech over hype. Favor explicit code and clear documentation.
  • 🧱 Modular by Default - Shared UI, utilities, and configs in a monorepo, used across web and mobile.
  • 🛠️ Tinker-Friendly - Swap auth systems, databases, or frontends without rewriting everything.
  • 🤖 AI-Ready - Designed for future AI integrations like RAG, streaming APIs, and agent workflows.

The Stack (and Why)

I’ve been working with the Python stack for over six years. While other frameworks, like FastAPI, might be better suited for certain use cases, I chose to build on a stack I’m comfortable with and layer modern tooling and best practices on top. Django, in particular, offers many built‑in layers and has proven itself with companies such as Instagram, Spotify, and Mozilla.
In retrospect while reviewing this post I think I might build one more backend only boilerplate repo for FastAPI stack with async workflows.

Backend: Django + DRF

🧸 For a 10-year-old:

Django is like LEGO. It gives you ready-made blocks to build cool stuff. You don’t have to make your own plastic—just focus on building.
Summary: Django saves time by giving solid, tested building blocks out of the box — like auth, admin, ORM, etc.

👨‍🎓 For a high-schooler:

Building with Django is like setting up a well-organized science project. It gives you a lab manual (batteries-included), safety goggles (security features), and lab partners (huge community).
Summary: Django is battle-tested, well-documented, and lets you focus on solving your business problem, not re-solving HTTP or database plumbing.

🎓 For a college student:

Django and Django REST Framework (DRF) form a structured MVC/MVT architecture with clear separation of concerns. This makes it easy to scale, onboard new devs, and build maintainable APIs with serializers, viewsets, and middleware.
Summary: It’s a robust foundation to build RESTful APIs fast, securely, and at scale — great for SaaS backends.

Frontend: Next.js + Expo

Why Next.js for Web and Expo for Mobile?

I want to be able to ship fast to both web and mobile without duplicating effort.
  • Next.js gives me server-side rendering (great for SEO), API routes, and a rich React ecosystem.
  • Expo lets me write React Native apps with a smoother DX and faster setup for mobile (both iOS + Android).
You could say:
🧃 These two frameworks are like a blender and a coffee machine. One’s perfect for cold, refreshing smoothies (web apps), the other for piping hot espresso (mobile). I want both — same beans, different brews.
And since I’m also planning to create a cross‑platform UI library—a huge project in itself, but I’ll see what I learn from it—Both frameworks can reuse components where possible, keeping things DRY and snappy.
I want to be honest about the frontend: I have some experience with Next.js, and the BlockSimplified Blog website is built using it. I have no experience building mobile applications. I researched native Android and Swift (as I did during my master’s), but I realized I need something more efficient for rapid prototyping. Depending on the product use case and performance requirements, we can explore these options. That is why we have a decoupled backend to support rapid pivots.

High Level Architecture of the Project

vas-dj-arch.png
Monorepo Structure
md
├── apps/                    # Applications
│   ├── web/                # Next.js SaaS interface
│   ├── mobile/             # React Native mobile app  
│   └── marketing/          # SEO-optimized marketing site
├── packages/               # Shared packages
│   ├── ui/                 # Cross-platform components
│   ├── auth/               # Authentication logic
│   ├── api-client/         # Type-safe backend client
│   ├── types/              # Shared TypeScript definitions
│   └── utils/              # Common utilities
└── backend/                # Django REST API
Apps stay thin, packages stay focused, backend stays API-first.

Planned Feature Set

SaaS Essentials
  • User accounts & teams
  • Admin dashboard
  • Subscriptions & payments
  • Multi-theme UI
Growth & Engagement
  • Landing page (config-driven)
  • Blog/CMS integration
  • Public API ecosystem
Ops & Reliability
  • Feature flags
  • i18n & localization
  • Email & 2FA
  • Background tasks
  • Security-first defaults
Developer Experience
  • Tests + CI
  • Docker-based dev
  • Clear documentation
I think I will add more as the time and work progresses

Why “The Long Road — With a Map”?

The “long road” is about not cutting corners but implementing solid architecture, tests, docs, and a great developer experience. The “map” means every choice is explained, alternatives considered, and trade-offs documented.
Example: Multi-Tenancy Instead of the simplest possible approach — a single tenant_id foreign key sprinkled through models without structure — I’m implementing logical separation of tenant data. That means:
  • A well-defined Organization (or similar) model as the tenant boundary
  • All tenant-aware models inherit from a base that enforces isolation rules
  • Clear query patterns that always respect tenancy
  • Support for tenant-specific branding, configurations, and features
  • Routing support for subdomains and custom domains

why not django-tenants?

I’m not doing database partitioning or schema-per-tenant approaches like django-tenants — those add operational complexity I don’t currently need. Logical separation still allows for compliance-grade isolation and keeps the door open for other strategies later if requirements change.
It’s more work up front than just adding a tenant_id everywhere, but it won’t crumble when real customers — with different needs and scales — start using the system.

Who VAS-DJ Is (and Isn’t) For?

✅ You’ll like it if you:
  • Want to scale beyond a weekend MVP
  • Care about architecture and maintainability
  • Plan to target web and mobile
  • Enjoy learning the “why,” not just copy-pasting code
❌ Maybe not for you if you:
  • Need a no-code/low-code solution
  • Just want the fastest CRUD demo possible
  • Prefer all decisions made for you

What’s Next in the Series

  • Setting up the dev environment for rapid iteration
  • Multi-tenancy deep dive: Why I replaced django-tenants with a custom approach
  • Building a shared UI library for web and mobile (scary but exciting)
  • AI-ready backend patterns

📍Code checkpoint for this post:

Key Takeaways
  1. Philosophy > speed for long-term products
  2. Django + DRF = stable backend choice
  3. Next.js + Expo = cross-platform speed without duplication
  4. Modular, tinker-friendly monorepo = future-proof foundation
  5. AI is a co-pilot, not a driver
Built with ❤️ by Vaibhav Doddihal | BlockSimplified
Open-sourced at GitHub
But please remember that this is a work in progress.