Saas Pegasus is the blog of the Django SaaS boilerplate's creator, covering Django, HTMX, deployment, uv and JavaScript.
HN mentions it as the Django option among SaaS boilerplates, where its creator joins threads to answer questions about the product.
Ok I feel like I can give some good advice here. I wrote 4 Django apps over the last few years some for work and some during vacation/downtime (and sold a couple). One was a car reservation system with reminder emails. The others were covid screening, warehouse management and a car key replacement service.
They all were multi-tenant and had the concept of an admin login and a user login. Basically I had organizations and each org can have admins and users. Each user had a profile with a role/organization_id which determined what UI they were served.
I used Django apps this way:
* core-app - models and common services
* admin-app - admin ui and admin services
* user-app - user ui and user services
Of course you could code up the admin and user projects separately for maximum decoupling but you'd want your common core app to be a dependency for each.
Messages (Email and SMS) to be sent were dropped on a queue and processed by workers.
Each message was self contained and basically was the type of email to send, a map of data and a pointer to the template. I think in the later version I skipped the worker and called a lambda on the message appearing (this was AWS)
Reminders in the future were just put in the db and then a cron job grabbed them when it was time to send. For instance, the time to remind someone that their car reservation was about to expire was configurable by the admin - so you could say 24 hrs before or less depending on the dealer's policy. Anyway…
i generally like-ish Laravel, in part because it's PHP so you know it's easy to hack, but...
one potential issue with Laravel is there are 8 trillion pieces of tech you will have to read about or try to ignore to get to a simple deployment.
and even simple deployment is not so simple -- you need tools, lots and lots of tools.
you know, to compile your css. :-D
but i would generally agree-ish with one of the commenters below who recommended Laravel.
it's mostly well done, generally organized, etc.
if you do the current latest install, you'll end up with a Laravel app with a 'Breeze' front end (i think). Breeze being the simpler little cousin of the two 'Jetstream' front ends/routing techs that will also be bundled, but you don't have to use.
The default css is Tailwind, the default templating engine is blade, the default js/component/library implementation is Vue.
laravel also sells - or someone sells - laravel-in-a-box so in theory it's easy to run vagrant-style.
there are now a bunch of 'saas scaffolding' apps out there you can buy for a few hundred bucks - so they give you what every framework should already give you out of the box - authentication, primarily.
and laravel has a trillion plugins/apps/services, some of which are paid. like a deployment service. a fancy admin panel. etc. their own scaffolding, 'Spark', was downgraded to be just a souped-up version of their Cashier plugin/app (I think) - but not sure.
https://www.saaspegasus.com/ is an example for…
I'm the creator of https://www.saaspegasus.com/ and would love to have you as a customer, and very happy to answer any questions you have about the Pegasus product, community, etc.
That said, all of the popular boilerplates have been created by individuals or teams who are passionate about their frameworks (in my case Django) and have significant experience building products on top of them (in my case 10+ years). All of them will drastically reduce your time to MVP and likely be a better foundation than you'd author on your own.
I actually would choose a language/framework first and then choose a boilerplate based on that. The boilerplate will get you far, but ultimately you're still going to be doing lots more dev in the framework, so you should pick one you like. Django and Rails and to some extent Laravel are comparable - mature frameworks with lots of batteries included, mostly server-render HTML by default. JavaScript is its own separate beast with a more fractured ecosystem, but tighter integration with the front end. I'm obviously biased towards Python because it's a wonderful language to work with and has a great community and third-party package ecosystem. But honestly, any of these are great choices and will help you launch your first product way faster.
There's a huge list of SaaS boilerplates broken down by language available here: https://github.com/smirnov-am/awesome-saas-boilerplates
Good luck!
Okay, well, I'm biased because I literally make a SaaS starter kit/boilerplate based on Node.js and Vue called Nodewood: https://nodewood.com/
I built it from Node.js and Vue because I knew them very well and found that they made it very easy to do the kind of work I wanted to. Even still, there was still a lot of extra stuff I had to set up each time, like the basic scaffolding, user authentication, subscription payments, teams/permissions, etc. Once I started building myself a re-usable version, I realized I could add a bit more rigour and sell it, as well.
So that would be my choice.
But if you strongly prefer other languages, there are other great boilerplates out there as well:
- SaaS Pegasus, if you like Python (https://www.saaspegasus.com/)
- Laravel Spark, if you like PHP (https://spark.laravel.com/)
- Bullet Train, if you like Ruby (https://bullettrain.co/)
I think low-code, like a good boilerplate, outperforms no-code if you're building anything that needs to scale beyond simple built-in functionality. Once you need to do something the no-code app doesn't let you do, you're faced with a pretty uncomfortable choice between rebuilding the whole thing from scratch or figuring out some ugly hack to bolt on the functionality you need.
Building from scratch wastes a ton of time and I'm a big fan of starting with some working parts and customizing from there. I think with what's going on with AI it makes sense to use python more because all the researchers love python and make examples available through python notebooks. Then your tech stack is less split amongst many languages and there is less complexity and you can hire developers for cheaper. Ruby devs are fairly pricey because they all working in silicon valley-esque well-funded startups. There is a Django boilerplate provider that's really good https://www.saaspegasus.com/. The guy behind it, Corey, is very responsive. All in all, it's probably not the worst thing to use Ruby, as long as you use less weakly-typed javascript :P
Thanks for reading and for the feedback.
Yeah, I see what you're saying. I had this article[0] in mind, which is a well-written article and ranks #1 for "organize front end code django" on Google. None of the other results are close in relevance or quality.
But I guess that example could be confusing for readers who aren't familiar enough with Django to know why structuring the frontend is a hard problem that not many people write about.
[0] https://www.saaspegasus.com/guides/modern-javascript-for-django-developers/client-server-architectures/