dmix, a 2-3 person team is actually exactly what this project was built for. The use case came from a start-up of the past that I was an engineer at that really really needed something like this.
I had not seen Nextdoor's scheduler, which looks awesome except for the required external requirement of SQS. Kala was built to not require anything except for the Kala binary.
Yelp's Tron is awesome, but I wanted an JSON over HTTP API and ISO 8601 Duration Notation. Plus there are a few over problems with it that I currently don't remember.
The initial use case was for a single node setup, Chronos for an early stage startup. I/we will be adding support for it to be distributed here soon, but not until the single-node, single binary with no external requirements setup is production ready.
If you have any feature requests, please create an issue in github. The more people request something the sooner it will get implemented.
Did you look at the actual main aspect of this simple tool, or just the one folder with the server-script? As previously mentioned. The main aspect of this is the automatic _Django Project Builder_, not "a collection of fragile scripts to get basic stuff done".
Even though it doesn't seem to be the case when viewing the README, this is more for automatically creating a Django app rather than the deployment process. There are things like Chef, or even Fabric, which are far more swag for auto-deployment.
The core aspect of this is the Django defaults and the front-end stuff. The server scripts are in a separate folder for a reason.
We have included settings_local.py for development purposes, which gets imported by settings.py if it can be found. The main purpose for this is for the settings_local.py to be using sqlite3 rather than postgres, which is the default in settings.py.
Another thing which is kind of hidden is the ptm1.4 branch. This is a branch that includes a lot more, and will be growing quickly. We wanted the master branch to be generic as possible, and have it so people can easily switch out our defaults for their own, i.e. changing any of the files in django-files/ for their specific needs.
In regards to supporting other 'preferred practices', we welcome people to fork this repo and contribute stuff back. The master branch will be staying more generic, but we are all for best practices no matter if they are the "Django way".