На Хабре любят истории про эффективность. Но есть одна тема, которую обычно обходят стороной — ритуалы джанго-разработчиков.
Эти ритуалы жрут месяцы жизни компаний, и об этом мало кто говорит.
Я расскажу историю. Она звучит как анекдот, но на самом деле это кейс.
История Васи и Пети
В компании «Рога и Продакшн» решили запустить новый сервис.
Назначили двух разработчиков:
Вася — senior Django-разработчик.
Петя — middle, но с django-cfg.
Вася: путь традиции
Первые три дня он копировал старый
settings.py.Потом неделю правил
INSTALLED_APPS.Потом два дня воевал с
ALLOWED_HOSTS.Потом переписывал
DATABASESпод дев, тест и прод.Потом поймал баг, потому что написал
DEBUG="yes".Потом завёл
.envи сказал, что «всё по best practices».
К концу месяца Вася гордо показал: «проект готов к написанию бизнес-логики».
Петя: путь революции
Написал конфиг в 10 строк через django-cfg.
Запустил сервис на следующий день.
На третий день уже писал бизнес-логику.
Через неделю показал работающий релиз.
Счёт компании
Ставка разработчика — $4000/мес.
Вася потратил 1,5 месяца на конфиги → $6000.
Петя сделал то же за 1 день → $200.
Разница: $5800 в мусорное ведро только из-за того, что Вася верил в магию settings.py.
В чём суть django-cfg?
Типизированные конфиги на Pydantic (никаких «строка вместо bool»).
Готовые пресеты для DRF, Spectacular и прочего.
Зоны API: public, admin, internal — настраиваются декларативно.
Автогенерация Python + TypeScript клиентов с авторизацией и токенами.
Ноль копипаста: один файл → всё готово.
А теперь вопрос для работодателей
Когда вы видите строку в бюджете «1,5 месяца на подготовку окружения»,
вы думаете, что это реальная работа?
Нет. Это Вася-джанго-разработчик обосновывает своё существование.
А Петя уже сделал продукт.
Потому что django-cfg убирает то, на чём они десятилетиями строили иллюзию «сложной инженерной работы».
Ритуалы исчезают. Остаётся продукт.
А продукт видно директору.
Заключение
Каждая компания выбирает:
Либо оплачивать шаманство с
settings.py.Либо делать проекты быстро и прозрачно.