About five months ago, I started building VitalCare, a SaaS platform for long-term healthcare facility management. We're in the soft launch phase now with our first customers onboarded, and honestly, it's been pretty exciting to see something go from idea to actual paying users.
But here's the thing - as I built VitalCare, I realized I was creating a really solid foundation that could work for any SaaS app, not just healthcare management. All the user management, multi-tenancy, theming, async processing, and deployment infrastructure was completely generic and reusable.
So I decided to abstract all those core concepts and turn them into Woopdi - a clean SaaS starter template. This is essentially a stripped-down and polished version of the VitalCare foundation, minus all the healthcare-specific features.
The motivation was pretty simple: I wanted something I could clone for future ideas so all the foundational work wouldn't be permanently cemented into one codebase. As you build more domain-specific features into any platform, the core foundation gets less and less reusable. By extracting it now while it's still clean, I've got a solid starting point for whatever comes next.
Whether you're building project management software, e-commerce tools, or something completely different, the core challenges are always the same: user auth, organizations, permissions, data isolation, theming, and reliable deployment. Woopdi handles all of that so you can focus on building the parts that actually matter for your specific use case.
User Management That Actually Makes Sense
You're building a SaaS product and you need to figure out how customers are going to invite their team members, manage permissions, and keep their data separate from other customers. This is the kind of stuff that sounds simple until you actually try to build it, then suddenly you're drowning in user tables, permission systems, and data isolation nightmares.
Woopdi handles all of this out of the box with a proper multi-tenant organization system. Think GitHub organizations, but for whatever SaaS you're building.
Here's how it works: each of your customers gets their own organization. They can invite team members, assign different roles (admin, moderator, member), and everyone in that org only sees data that belongs to them. No data leakage, no accidentally seeing another customer's stuff, no permission headaches.
Your customers get a clean invite flow - just like inviting someone to a GitHub repo. They send an email invite, the person clicks a link, creates their account (or signs in if they already have one), and boom - they're part of that organization with whatever permissions make sense.
The really nice part is that users can be part of multiple organizations. Maybe someone is a consultant who works with several of your customers, or an employee who switches between different company divisions. They just use the organization switcher in the top nav and everything changes - different data, different team members.
All the tricky multi-tenant stuff is handled for you: data isolation, permission checking, context switching, invite management. You don't have to build any of this from scratch or worry about accidentally showing Customer A's data to Customer B.
If you've ever tried to retrofit multi-tenancy into an existing app, you know it's a complete nightmare. Starting with it built-in means you can focus on building your actual product instead of wrestling with user management plumbing.
A Nice and Simple Theming System
The frontend has full support for your brand and style, and honestly, it's pretty flexible. But here's the cool part: it's incredibly AI-friendly. You can literally copy and paste one of the existing themes into any LLM and ask it to make a new theme based on what you want. Try something like: "Give me a theme for a financial services app. The colors should feel cool and trusting, and it should have the vibe of a brand like Merrill Lynch or JPMorgan - authoritative, intelligent, and minimal. Here's an example of how a theme looks..." then just paste in an existing theme.
Here is an example of a theme made by an LLM in just seconds "Hacker Buzz"
LLMs are surprisingly good at this stuff. Since the client uses MUI React, all the elements are super customizable in a clean, consistent, and predictable format. No more wrestling with CSS chaos or trying to figure out why your button looks different on every page.
The project comes with several dark and light themes right out of the box. The themes are dead simple to make, so instead of burning weeks on design concepts and endless mockups, you can just experiment with generating themes until you find something that actually fits your brand.
Picture this: instead of hiring a designer, waiting for concepts, going through revision cycles, and hoping the final result matches your vision, you just describe what you want to an AI and get a working theme in minutes. That's the kind of workflow that actually lets you focus on building your product instead of getting stuck in design limbo.
Your logo is also configurable on the backend in the settings configuration https://github.com/SpencerCooley/woopdi-api/blob/master/config/system_settings.py
Below are some example of themes that come with Woopdi out of the box:
Clean Architecture That Grows With You
Woopdi is architected from day one to handle complexity without becoming complex. The system uses clean separation of concerns so you get the scale handling you need without the architectural mess.
Two Repos, One System
The project splits into two repositories: a FastAPI backend and a Next.js frontend. The backend handles data processing, business logic, and external API integrations while the frontend focuses purely on user experience. This separation means you can scale each piece independently - spin up more API servers when you're getting hammered with requests, or deploy frontend updates without touching the backend.
FastAPI Backend
FastAPI brings several key advantages that make the codebase maintainable and productive:
The code reads like documentation - any Python developer can jump in and understand what's happening immediately. Visit /docs on your running API and you get a fully interactive OpenAPI interface for testing endpoints directly in the browser.
Everything is type-safe with Pydantic models, so data gets validated at the edges before it becomes a problem. Async support is built-in from the ground up, handling concurrent requests efficiently without the typical Python threading headaches.
Users get real-time progress updates through WebSockets via a custom TaskStreamer. Each Celery worker runs in its own Docker container for easy horizontal scaling. Redis serves as the message broker, result backend, and cache layer.

Celery for Async Tasks
Long-running processes and AI workloads run through Celery with a clean, organized structure. Tasks live in a dedicated celery_app/tasks/ folder - adding new async functionality is just dropping a file in the tasks directory.
Docker for Deployment Flexibility
The entire stack runs in Docker containers, giving you deployment options that scale with your needs. Start with everything on a single VPS for your MVP - database, Redis, API, and workers all running together. Scale horizontally by adding more containers as demand grows.
The containerized setup works identically across development, staging, and production environments. Each major service (API, Celery workers, Redis) can be replicated independently based on where you're hitting bottlenecks.
Clean Patterns Throughout
The architecture uses consistent patterns that make the codebase predictable. API endpoints follow clear conventions. Database models use proper relationships and constraints. Tasks have standardized error handling and progress reporting.
This consistency means you can work efficiently without constantly figuring out how different parts of the system work. Whether you're processing a few requests or millions, the same clean patterns handle the load gracefully.
But here's the important part: this isn't a black box or some proprietary framework you're locked into. It's just a curated collection of completely open source tools - FastAPI, PostgreSQL, Redis, Celery, Next.js, React, MUI - glued together in a way that actually works well. There's nothing tricky or mysterious happening under the hood. No vendor lock-in, no proprietary APIs, no custom frameworks you have to learn.
You own all the code, you understand all the pieces, and you can modify or replace any part of the stack as your needs change. It runs on any infrastructure and not just some very specific cloud service. It's just solid, proven tools organized into a foundation that lets you build a SaaS app without reinventing the wheel.
My Future Plans for This Code
I open sourced this mostly because I find it useful for myself. I'm using it as the foundation for my own early-stage company, and since nobody really knows or cares who I am yet, I figured I'd just leave this as a solid boilerplate for when I want to experiment with ideas or quickly prototype something.
What's Available Now
The master branch is designed as a starting point for simple, non-paid platforms. I stripped out the payment features from my main SaaS (VitalCare) to make this version easy to get up and running without being blocked by paywall complexity. The payment endpoints are still there though, so adding a billing flow is straightforward when you need it. Payment flows tend to be specific to a company or a product so my VitalCare flow didn't make sense as a general product flow since it is very specific to my customer type and industry.
Where This Is Going
I've got a few things in the works:
First, I'm adding a branch with a complete payment flow example for anyone building a paid platform. The infrastructure is already there, just need to wire up the frontend pieces.
Second, I'm building MLmama.com using Woopdi as the foundation. It's going to be an SDXL LoRA training platform that makes it easy to train and test style models, with sharing and credit systems - kind of like Civitai meets Hugging Face. I mostly just want a way to train models quickly and cheaply without the usual devops setup headaches.
The goal is to make dataset creation and labeling extremely simple - I want an aesthetic-focused workflow that just works. Beyond the LoRA trainer, I'm planning to use MLmama as my ML research playground. I'll probably build a suite of tools around the Qwen models, but for now I'm focused on finishing the SDXL trainer and seeing where that takes me.
Think of it as my experimental ML notebook, but where every experiment is built from a product perspective instead of just being academic code that only works on my machine. It is a place for me to build ML apps and workflows that others can also use and experience.
As I build MLmama, I'll keep improving this repo as well. If I create useful middleware or refactor something to work better, those improvements will make their way back here. The plan is to keep building cool specialized branches as I discover new patterns and solve new problems.
This isn't a corporate open source project with roadmaps and governance. It's just a useful tool I'm sharing while I use it to build other things. If it helps you skip the boring setup work and get straight to building something interesting, then it's doing its job.
Visit the repos on github at the links below:
GitHub - SpencerCooley/woopdi-api
Contribute to SpencerCooley/woopdi-api development by creating an account on GitHub.
https://github.com/SpencerCooley/woopdi-apiGitHub - SpencerCooley/woopdi-client
Contribute to SpencerCooley/woopdi-client development by creating an account on GitHub.
https://github.com/SpencerCooley/woopdi-client