Alexander Lebedev

для добавления нужно только право "add..."
право "change..." - дает возможность просмотра списка и редактирования данных (но не удаления)
таким образом, если вы хотите, чтобы пользователь только создавай новых пользователей - выдайте ему только право "add...", списка пользователей он видеть не будет, изменить и удалить ничего не сможет
хотите, чтобы пользователь еще и менять что-то мог - давайте "change..."
в любом случае, без права "delete..." никто ничего удалить не сможет

в Django работа с несколькими базами данных осуществляется так.
При этом весь набор функционала Django (модели, менеджеры и пр.) доступен для всех баз вашего проекта.

столкнулся с этой проблемой не так давно. Теперь файлы моделей у меня выглядят так:
app2/models.py:

from django.db import models

class B(models.Model):
    data = models.ForeignKey('app1.A')

избавляет от лишних импортов и, ИМХО, делает код модели более читаемым - всегда видишь к какому приложению относится модель.
Если нужно в том же файле использовать класс A, например - в методе того же класса, то делаю так:

from django.db import models
from django.apps import apps

class B(models.Model):
    data = models.ForeignKey('app1.A')

    def some_method(self):
        a_class = apps.get_model('app1', 'A')
        a_object = a_class.objects.get(id=1)
        ...

Валидация на сервере принципиальна?
Зачем гонять данные на сервер и обратно, если вот так можно все быстро и дешево сделать на фронтенде.

что мешает использовать, например, такое?

сервер/не сервер: может предрассудок, но серверному ПО - сервер; другое качество железа, большая производительность, возможности к расширению
по поводу конфигурации сервера - согласен с handbrake, расписано дельно
по поводу базы данных: 6-8 человек - пограничное количество, когда уже рекомендуется использование MSSQL, но еще можно работать на файловой базе. Если нет спецов по MSSQL, начните с файловой, почувствуете проблемы с производительностью базы - переходите на MSSQL. Кстати, если работать с MSSQL, рекомендую разносить файлы баз данных и логи транзакций на разные дисковые массивы - производительность возрастает ощутимо. Еще, для MSSQL, настоятельно рекомендую ознакомиться и реализовать.
бэкапы: для файловой используйте встроенные средства 1С - там есть весь нужный функционал (но потребуется, чтобы все пользователи вышли из системы); для MSSQL базы - встроенные средства СУБД, они быстрее 1С-ных и не требуют выгонять пользователей. Бэкапы всегда лучше хранить на отдельном устройстве с RAID массивом (подойдет сетевое хранилище от WD на пару дисков с поддержкой RAID1). Не надо отдавать хранение бэкапов на откуп пользователю

у нас используется teampass, но мы все чаще думаем о самописке

Почему бы не попробовать Celery? Асинхронный запуск задач, управление расписанием через админку проекта; полноценная работа с ORM проекта в коде task'а.

Обычно разделяю предметные области проекта на отдельные приложения. Если какая-то область слишком обширна, то в папке приложения создаю отдельные приложения для подобластей. Для каждого приложения - своя папка templates: это позволяет при большом количестве приложений не путаться в разросшейся иерархии директорий. Кроме того, отправляю всю обособленную статику в директории static каждого приложения: иногда для работы интерфейса пишу JavaScript приложения на Marionette - всегда знаю, где искать нужную кучу скриптов.
Для примера: пишем проект для дилерской сети по распространению и продаже автомобилей. Получается так:

./project_name/
./project_name/settings.py
./project_name/urls.py
./project_name/static/
./project_name/static/css/...
./project_name/static/js/...
./project_name/static/imgs/...
./dealer/
./dealer/admin.py
./dealer/models.py
./dealer/views.py
./dealer/urls.py
./dealer/templates/
./dealer/templates/dealer/
./dealer/templates/dealer/list.html
./vehicles/
./vehicles/admin.py
./vehicles/models.py
./vehicles/logistics/
./vehicles/logistics/models.py
./vehicles/logistics/admin.py
./vehicles/logistics/views.py
./vehicles/logistics/urls.py
./vehicles/logistics/templates/
./vehicles/logistics/templates/logistics/tracking.html
./vehicles/logistics/static/
./vehicles/logistics/static/js/app/tracking/
./vehicles/logistics/static/js/app/tracking/main.js
./vehicles/logistics/static/js/app/tracking/app.js
./vehicles/logistics/static/js/app/tracking/...
./vehicles/sales/
./vehicles/sales/models.py
./vehicles/sales/admin.py
./vehicles/sales/views.py
./vehicles/sales/urls.py
./vehicles/sales/templates/
./vehicles/sales/templates/sales/invoices.html
./vehicles/sales/static/
./vehicles/sales/static/js/app/invoices/
./vehicles/sales/static/js/app/invoices/main.js
./vehicles/sales/static/js/app/invoices/app.js
./vehicles/sales/static/js/app/invoices/...
./static/
./media/
./templates/
./templates/base.html
./templates/...

Далее по аналогии. Если нужна какая-то мелочь - отправляем ее в соответствующее "корневое" приложение; если мелочь становится более серьезным куском функционала в рамках той же предметной области - создаем ей отдельное приложение внутри уже существующего. Все, что выходит за рамки предметной области - новое "корневое" приложение.