Regarding apps, I was just thinking you could create a directory structure like this, essentially eschewing the whole concept of Django "apps":
<project>
src/
<package>/
models/
__init__.py # Import all model classes (necessary for Django to find them)
some_model.py # Define SomeModel class
views/
__init__.py
some_view.py # Views for SomeModel
settings.py # Add "<package>" to INSTALLED_APPS
urls.py
You still need to register the top level package as an app for Django to find things, but then you don't have to deal with Django's concept of apps beyond that. All your tables will be named <package>_<model> by default, which seems nice.
If it turns out later you need resusable "apps" for some reason, you could always add an apps/ subpackage for them.
I haven't tried this in a real project, so I don't know if there are any downsides, but it seems like a decent approach.
Yeah I've played around with this approach in the past while prototyping service boilerplates, I think it's viable. I never got it polished enough to publish as a startproject --template and ultimately went with Flask for microservices, so I didn't finish the prototype.
There are a few different places where little things break and then you need to use an obscure settings.py variable to fix them, which makes me a little nervous since it will cause a little cognitive friction for Django-fluent developers joining your project. But I do think it's worth experimenting with.
If it turns out later you need resusable "apps" for some reason, you could always add an apps/ subpackage for them.
I haven't tried this in a real project, so I don't know if there are any downsides, but it seems like a decent approach.