<img src="https://habrastorage.org/getpro/habr/upload_files/554/197/b87/554197b878cdf5751363fcf9f03fa7f4.jpg" /><p>Каждый раз, когда начинаешь новый SaaS-проект на Django, первые две недели уходят на одно и то же. Сначала — кастомная модель пользователя с UUID вместо integer PK, потому что потом не переедешь. Потом JWT-аутентификация, настройка SimpleJWT, написание <code>RegisterView</code>, <code>LoginView</code>, <code>LogoutView</code> — всё это уже было в прошлом проекте, но лежит в другом репозитории и просто так не скопируешь. Дальше Docker Compose: сервисы <code>web</code>, <code>db</code>, <code>redis</code>, <code>celery</code>, <code>celery-beat</code>, <code>flower</code> — шесть штук, которые надо поднять и связать между собой. Потом разбираться с Celery, который в новой версии изменил синтаксис конфига. Stripe webhooks с идемпотентностью — отдельная история. Мультиарендность, роли, permissions — ещё неделя.</p><p>В итоге к первой рабочей фиче добираешься к концу третьей недели.</p><p>Добавь сюда ещё один нюанс: каждый раз это проект с немного другим стеком. Где-то Kafka вместо Redis, где-то allauth с самого начала, где-то биллинг на пользователя, а не на команду. Но ядро остаётся одним: каждый раз перед стартом ты тратишь одинаково одни и те же две недели. Вот это и хотелось исправить.</p><p>Я прошёл через это несколько раз и в какой-то момент решил, что хватит. Собрал Django SaaS boilerplate под названием <strong>Shipyard</strong> — не как набор сниппетов в Notion, а как полноценный, готовый к production репозиторий, который можно клонировать и сразу писать продуктовую логику.</p><p>В этой статье разберу, что там внутри, почему выбраны именно эти компоненты и какие конкретные технические решения показались мне наиболее интересными.</p> <a href="https://habr.com/ru/articles/1025002/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1025002#habracut">Читать далее</a>