Forge – A Django SaaS Framework
djangoforge.devI think this makes sense. Ideas:
- Showcase your reciprocal contributions you make back to django community packages (e.g. Jazzband packages).
- Release a permissively licensed django package (with no catches) under your GH's org and brand name and have it take off. (e.g. django-forge-admin)
- The holy grail would be contributions to django itself. Example: Adding more CSS variables in django admin to font-size and font-family. Add rem, %, calc, flex, etc.
- Early startups funding: $5,000 for MVPs up into 6 figures. Your price point could be a bit higher. Email early founders and see what their reaction is. Use that feedback to tailor a business-friendly license to address the concerns of people with decision making powers. Commenters opinions matter, but they're not necessarily your clientele.
- Strike custom deals to make the sale.
- Add on custom development hours and add a clause to incorporate the work back into your product for reuse.
- Expect to be reaching out to founders often, using cold email introductions, both for advice, but also to show you're flexible. Be willing to hop on a zoom, demo it, etc.
- Find early startups to use your framework for testimonials and social proofing.
- I've personally set these up before many times in django at previous places. It takes weeks of effort to bootstrap, especially if you factor in billing. No it's not 8 hours. It's weeks of effort.
My only doubt is, I think you may ultimately make more money striking big deals to do development work. What's more efficient, a $100-$150k deal with one customer or being on the hook for 100 customers?
All good ideas — thanks for taking the time. I've been thinking about some of these but not all.
On the 1 customer vs 100, I totally lean towards the 100. I have a blend of these with https://www.pullapprove.com/ and the higher the price, the more it feels like you just work for them. Pros and cons, but personally I don't want something that looks like freelance/consulting/employment.
I wonder if this creates more problems than it solves.
For example, imagine there are a bunch of startups trying their hardest to shoe-horn contributions in Django main branch. It puts a lot of load on core developers at Django to reject frivolous features and unnecessary bloat.
The end effect would be that we get features no one asks for and Django becomes even more bloated.
Django is already a very popular framework and has many contributors.
I wouldn't limit django patches to just being new features. Ample room for incremental improvements.
There are some parts of django core that are stable, but fundamentally broke for non-trivial apps. Let's just take /admin:
- Can inline admin models be paginated? Searched? Both? Asynchronously?
- Use autocomplete_fields by default via ID/PK lookup / when `search_fields` exist. Right now related fields will load the whole table into a <select> box. This is an absurd default.
Other opportunities that'd be universal:
- Integrate channels into admin
- AJAX form validation
- Revision history that includes actual values / diffs / undo
Good response, I agree that these changes would benefit Django.
Yeah I could see that argument too. Lots of hard decisions and interesting questions in terms of how to navigate what people want/need. Honestly I don't envy their situation. It has even made me think crazy things like what a Django fork would look like... the thing has some bloat that could stand to be removed too. And some legacy decisions that are super hard to change, but also need to be changed.
The descriptions seem a little bit scarce for me. Like others I also wonder who's the intended audience. For 1k/year/repository I need to be quite serious with a project, but that project needs to be basically non existent (otherwise I would probably have the basis already) while also being somewhat serious.
Formulating it a bit provocative: In what way is it more than an expensive cookiecutter repository? (Especially with a one-time-use policy per subscription)
> Like others I also wonder who's the intended audience.
Me too — trying to figure that out!
> but that project needs to be basically non existent while also being somewhat serious
Super interesting point. I've helped integrate it into some existing projects and it is not fun.
> In what way is it more than an expensive cookiecutter repository?
I don't disagree with this. A couple differences in my mind are support (that you're paying for, and has an incentive to be as helpful as possible) and on-going updates (a cookiecutter won't help you integrate improvements over time, as far as I know).
Pricing is totally an experiment right now, and I shot high on purpose. Suggestions?
The project seems really well put together but until you figure out your ideal target customer (and their needs) I would hold off on pricing it too high. Maybe offer it for free, get some learnings and as you add more value and get more clarity on your target group, you can then ramp up the price?
Yeah I've been considering that. Probably more likely that I'll lower the price, learn some things, then ramp it up. Free feels hard to reverse and the difference between "I wouldn't pay at all" vs "I'd pay less than that, but something" is pretty big (and important to me unless I figure out another way for the project to get paid for).
> Free feels hard to reverse
Absolutely true. I remember the amount of hate HN spewed at Docker for making their desktop app /paid/ for Corp users.
Thanks for the reply!
> support (that you're paying for, and has an incentive to be as helpful as possible) and on-going updates (a cookiecutter won't help you integrate improvements over time, as far as I know).
That's true, good point.
> Suggestions?
I think it highly depends on your target audience.
Also this
> Things like django-coookiecutter are great, but they only really cover the project structure.
tailwind ui had a Goldilocks pricing imho .. you could always offer discounts case by case if prospect can fill out a form.
Good point. Still trying to figure out who is interested, but I'll probably add a student/educational discount too. (If anybody sees this and wants that, let me know.)
Interesting idea. I've been using Django for 10+ years and like all the choices you've made here. Not 100% what I personally prefer but close. And the decisions I differ on I'm curious about: "Hmm, should I be doing it that way?"
In the past few months I've been working on side projects and have gone through the process of setting up a similar template (just for my own use), which I've used with two different side projects.
I think my interest in buying this is not so much to replace my own template but to borrow parts of it.
From the borrow perspective, I wonder if this could be worth it to some established, non-agency companies that use Django.
Really nice code you can copypasta over? Doesn't take too much of that to get to $1000 of value.
I could absolutely see the "borrow some code" angle. Especially if you have an existing/established project where it would be pretty hard to integrate everything anyway. $1000 is not much for a company looking for another "professional Django resource" (if that's what it is).
Would have no issue with some people paying for access, borrowing some stuff, and being a part of a "community" of people sharing variations of the ideas and occasionally factoring that in to the Forge code itself, copying it out, etc.
This project looks very useful. It's easy to burn through $1000 in software engineering time setting up the initial stages of a project and this looks like it does a great job of streamlining that for you.
Another thing I like about this project: I've always felt that the rails community does a better job than the django community in the out-of-the-box experience of setting up a new app. This project seems to bring some of that niceness to the django world (and would be similar to https://jumpstartrails.com/).
Thanks. Completely agree on the contrast to rails... This has been a super interesting process for myself in thinking through "what are the parts of Django that are either way too clunky, or just completely outdated?" I think there's more than a couple... There are a lot of things I realized I have just gotten used to, but people new to Django would find super odd (why aren't emails required to be unique on users by default?).
Would also recommend people listen to the first episode of https://www.frameworkfriends.com/ if they are thinking about these kinds of things.
projects like this are impossible to sell to businesses
Great idea to bootstrap a product like this using an opinionated approach that I mostly agree with. The biggest challenge here will be that the audience you're most likely to target with this will likely be more interested in doing this themselves off a repo they've already got written up and charging $10k for it to a private client instead.
Thanks. Yeah, I agree with that. I'm honestly still trying to figure out exactly who it's for and the whole free/paid/price equation. Individuals? Agencies? Beginners? People with a couple years Django experience?
I'm finding it super helpful for my own purposes if nothing else. There are some topics that Django (understandably) doesn't get into, but also some rough edges that could use smoothing over (in my opinion).
And I think that is the rub.
You need to be an expert user to make use of this.
An expert user can likely already do this. And likely has differing opinions about some of your choices (maybe not a Heroku fan, like I would personally only ever run Django on GCP).
100%. Still working through it, but I think the question (or one of them) to me is whether you can lower the bar to where non-experts can get off the ground with some "expert" opinions (or at least experienced ones). Django itself just doesn't tell you, "hey Heroku + Stripe + Sentry + Tailwind + Poetry will get you off the ground if you don't even know where to start, and here's how to do it. And here's how you patch over some of our own idiosyncrasies... Revisit these things when you hit $X MRR or X users and know more about what you're doing."
Totally unproven yet, but I also think there could be an interesting community aspect. If everybody "in" Forge is essentially paying to be there, I think could have a really great place to ask questions and get help from people who are building stuff with a similar mindset to yourself.
This is like SaaS Pegasus https://www.saaspegasus.com/ which is a fraction of the cost and has a lot of the same functions. I wish I could demo it, but I do understand why I can't. Regardless, I hope this project takes off.
This is an interesting project. I'm not sure I'd pay $1000/year in the current configuration as I don't have any projects that could justify it, but I would certainly pay to get insight into how other devs are setting up their projects as well as their development environment and deployment pipeline (maybe in a community format?). For example I have a shortlist of things "I need to read-up on" when it comes to my Python/Django projects. Things like Poetry, Pre-commit, Black, TOML files etc. as well as deployment choices (Render, Fly, DO Apps). These are things that I know will be useful but I just haven't had time to configured and look into. Things like django-coookiecutter are great, but they only really cover the project structure.
> Things like django-coookiecutter are great, but they only really cover the project structure.
This is an important point, for me anyway.
Yeah $1000 can be a lot for an individual (myself included), especially for a hobby/side project. For individuals, at this price, it's probably more of "I've built a small revenue generating project before, and I'm going to skip some steps this time + connect with some other people doing it in a similar way"?
There is absolutely a market for this kind of product. If it saves someone a few days of work, the ROI is clear.
However, in my experience (have a similar product geared towards API backends: https://apibakery.com), many developers will stop at "boilerplate", think "cookiecutter", and balk away.
The most vocal complaints for me were:
- it's just boilerplate, therefore how dare you charge
- I can do that in an hour (all devs are optimists :)
- why should I pay a recurring fee for a one-off use (valid, and made me rethink my pricing strategy)
Ultimately, I suspect your users will mainly be founders who just want to get the ball rolling as quickly as possible. If you haven't already, engage with communities such as IndieHackers and r/SaaS.
Good luck!
I think I might be your target audience (oggling with the idea to create as SaaS, and good background in python). And let me be blunt: your promo material sucks
The docs show me what words to type to get your product, but not what your product gives me. From what I figured out it gives me a lot of django stuff. So should I go away now to learn all that djange stuff (probably yes), but then why do I need django forge?
The best explanation is the heading of the video. But still, what is the benefit. How difficult is it to build a SaaS with vanilla django, and how much easier is it with django-forge. I couldnt figure that out.
Can you make a video, where you show how to make a full fledged SaaS with django-forge and deploy it? How long would that video be?
> your promo material sucks
Well put.
Yeah I'm not 100% sure yet what level of Django experience is required to use (or at least appreciate) Forge? Should you have used Django at least once before on a project? Gone through the official Django tutorial maybe (https://docs.djangoproject.com/en/4.0/intro/tutorial01/)? At the moment, if you have not actually used Django before then I probably would recommend you go through their tutorial and THEN try Forge (or watch the video / read https://www.djangoforge.dev/docs/start/).
Some differences will immediately jump out — they'll tell you very (very) little about how to manage your dependencies, local environment, hosting/deploying, configuring settings with "secrets" for local vs production, the fact you'll probably want a custom AUTH_USER model later and it will be super hard to change, etc. But yeah, to sell those as differences, you do need to have a baseline familiarity or else I need to do a really thorough job of explaining and pointing them out ahead of time.
I think the gist, if you compared vanilla Django to Forge, would be that vanilla Django is almost completely open-ended. There are a lot of decisions you're going to have to make, and research you're probably going to have to do. Forge removes a lot of those decisions and makes them for you. Some are easy to spot up front, but others not until you're further down the road or have more experience...
> Can you make a video, where you show how to make a full fledged SaaS with django-forge and deploy it? How long would that video be?
Videos are absolutely the way to go. I'll try to do more and run through more of the parts and maybe a complete process. That first video I made stops short of deploying to Heroku, but it's maybe 5 minutes away from being deployed. Beyond that, basically every "topic" in the sidebar could use at least one video.
By 'THEN try Forge' you mean pay 1000$?
Lol, that's why I added the "or watch the video / read the Forge start page". 50% off right now though! Still thinking through some of these things. Not sure how to let people "try" it without basically giving away all of the value (code, which you can't take back).
I watched (partially) the video. Do you think it shows what you can do with django-forge? Does anybody here think so? In this case I will watch it again in 3 month.
$1000/yr is steep for starting a project from scratch with it. You need to really be sure about needing it and about it paying for itself.
The Rails equivalent (https://jumpstartrails.com/) is $249/year and the Laravel equivalent (https://spark.laravel.com/) is $99/project.
Those seem geared in features and price at hobbyist wanting to monetize a side project. This looks like it would be just as helpful for hobbyists using Django, but it’s not priced right for them.
Maybe it’s more for people who are about to start a second revenue project.
https://bullettrain.co/pricing is another example ($1450 one-time + $550/year).
> Maybe it’s more for people who are about to start a second revenue project.
I do think this is an interesting point that's come up a couple times now.
For what it's worth, I just added a 50% discount to the top of the page for the time being.
For Django there is also SaaS Pegasus(https://www.saaspegasus.com/) which has a pricing structure more in-line with Jumpstart Rails.
I am building a project with SaaS Pegasus, which I like. I have the unlimited projects account, allowing me a few experimental versions of my project(s) where I can quickly spin up and try variations of their offerings.
* Forge the Laravel server management SaaS
* Forge the Django SaaS framework
I'm sure other things use the name "Forge" but just seems odd you'd purposefully use the same one. Could also make your SEO rather difficult.
I have some regrets on this. I sort of landed on the name and then learned about Laravel Forge. But went with it anyway.
I assume the typical dev sentiment is that I would rather spend/waste/invest 2 hours of my time rather than spend/waste/invest 1 hour trying to read other peoples code and documentation. Devs are fidgity bunch. And as the great filmmaker Satyajit Ray said, "The only solutions that are ever worth anything are the solutions that people find themselves."
Based on the quote above boilerplates are for people who are more founder-y than dev-y. Some see codebase as solution, some see code as solution.
I'm interested and have purchased SaaSPegasus.com before. I like to compare the base setups between Django SaaS deployments for learnings. But SaaSPegasus is $299, imo $1,000 is far too much, and I wouldn't purchase it.
Thanks for the support and let me know if you have any suggestions on how to make Pegasus better! :)
Kudos to czue and Pegasus! I haven't used it before, but if that's a better fit for what you want, go buy it!
Honestly I feel a little weird "competing" directly with something like this, but such is life. Thanks to everyone who has made something similar (in any ecosystem), which is part of what got me over the hump of thinking it was even possible. I'm glad Django is getting some options and new ideas!
Hey, competition is what it is. If there was no competition you'd be in a bad market!
In this case there's probably room for a handful of small players at least, and certainly many people will have different opinions about what the "right" way to build a Django SaaS should be, so it makes sense there would be multiple products in the space.
At first glance Forge looks like it's trying to be more upmarket and more opinionated than Pegasus, while Pegasus is more price-accessible and flexible. Certainly there are pros and cons to both positions.
Good luck! I'm sure we'll see each other on the battlefield. :)
Add a Wagtail CMS layer and you'll have a number of agencies / companies potentially ready to use this as a service.
Do you plan on providing a hosted version as well, or just the core shipped package?
Don't have any plans for Wagtail or hosting, but those are interesting questions. I'll have to give it some thought.
How is this different from Pegasus https://www.saaspegasus.com/ which is a fully basked SaaS?
I haven't actually tried Pegasus, so I can't say exactly. In a lot of ways I'm sure they're similar. Some differences with Forge might be the removal of options: - Pegasus looks like it supports multiple CSS frameworks, Forge only comes with Tailwind - Pegasus talks about multiple deployment options, Forge focuses completely on Heroku - Pegasus talks about creating venvs or using virtualenvwrapper (+ pip-compile?), Forge uses Poetry
From what I understand, the update process for Pegasus is also a little bit more manual? Forge is intentionally set up to be a git remote, with directories and stuff named so that an update is essentially `git merge django-forge/main`.
Probably lots of little differences when you get into it — just different decisions from different people. Hoping to document more of Forge soon!
Disclaimer / shameless plug: I have an OSS project in this space, https://www.reactivated.io, and plan to do a Show HN on it tomorrow.
With that out of the way, I think having more opinionated Django frameworks is a great thing. Particularly around styling and forms.
I also think it's interesting to try to "productize" (I think there's a better word) what is often done as consulting. That is, bottling up and selling experience. So while the price may seem high, there's a ton of wisdom behind it. An experienced Django consultant is easily thousands of dollars per week.
I wish you the best!
Thanks! I found Reactive somehow yesterday — haven't looked closely at it yet but I will. Always cool to see more stuff in the ecosystem. But yeah, personally I feel like there are few things the Django community could learn (or at least try) from the Laravel (and Rails) communities. I love free software, but it has downsides too! (Like the fact that I can't justify spending all my time on it.)
This looks awesome! Thanks for sharing - I've been looking for a nice django/react starter kit to play with (especially as a less front-end inclined dev). Looking forward to the thread on your Show HN!
From the pricing page [0]:
Is there a free trial?
Unfortunately, because of the logistics of how this works, there is no free trial period. We do our best to give you an idea of what you're buying via public documentation, videos, and an overview of the repo. If you buy it and truly decide you aren't going to use it, contact us about a refund.
Wish I could figure out how to do a free trial. I've obviously considered whether the whole thing should be free and open-source in the first place, but getting paid to work on this stuff is the best way I know to make something high quality, where good support, improvements, fixes, etc. are all expectations.
Happy to give out some discounts if people are interested in that.
you want $1000/year for a boilerplate?
why would any business want this?
$1000 is potentially 6-8 hours of developer time. A well thought out boilerplate repo could easily save that time if it ticks the right boxes (I've no idea about this project in particular btw).
The Laravel community has a similar offering called Laravel Spark[0], and while it's priced differently ($99/proj or $199/unlimited), the gist is the same. The problem that folks I've talked to run into is that you could easily spend 3x-5x the time trying to figure out why the boilerplate did one thing vs. another, or end up spending time undoing something that doesn't necessarily fit.
Might be too high — not sure yet. It is partially based off of https://bullettrain.co/pricing#now (and I know they're making that work... but there are some differences).
> why would any business want this?
An existing business building a new product? A new business getting off the ground? Don't know exactly yet.
Unfortunate naming conflict with Laravel Forge
Isnt the real problem to use the 'django' name?
https://www.djangoproject.com/trademarks/
"You may not incorporate the Django name or logo into the name of any product to be sold by a commercial entity, regardless of whether that product or service is Django-related."
Yep. Don't know if this will become an issue or not, but it is unfortunate in retrospect.