Я поделюсь своим опытом при разработке RESTful API. Не важно на каком языке вы пишите. Главное экономия времени и нервов. Дополнительный функционал для управления API при разработке - это козырный туз. Что я имею в виду?

1. документация: роуты (эндпоинты)
2. документация: таблицы и поля базы данных
3. документация: работа приложения
4. графическая схема: структура приложения
5. графическая схема: база данных
6. автоматические тесты
7. команды CLI
8. ведите учёт коммитов в документе front:back
9. бекап: код приложения
10. бекап: картинки и другие медиaфайлы
11. бекап: базы данных

Я работал в конторах в которых мы даже не знали какие разделы на сайте есть. Мы как разработчики не знали какой функционал предоставляет приложение. Схем таблиц базы данных было. Таблицы были связаны между собой первичными ключами, но отношения не прописывались. Часто первичные ключи ссылались в "пустоту". Тестов не было и программист мог написать новый функционал и тем самым поломать другие части кода. Одним словом, подобная работа - это ад. Старайтесь по возможности не работать в таких конторах. Если вы работаете в такое среде, то находите время и занимайтесь документацией.

Самое последнее, что я придумал - это удобные команды которые создают фикстуры для pytest тестирования приложения. У вас должны быть команды для наполнения базы данных тестовыми данными. Если вы поломали данные, то при помощи команды можно восстановить данные в таблицах буквально за несколько секунд.

Вы можете написать команду для подсчёта количества строк которые вы как программист написали. Часто находятся люди, которые вам будут говорить, что вы ничего не пишите и благодаря этой команде вы сможете сказать что приложение растёт.

Бекапы - это святое. Вы должны уметь делать разные бекапы. Если есть база, то нужно делать бекап базы данных. Я мог потерять все свои сайты и только чудеса меня спасали. Мои сайты ломали и пытаются ломать. Бекапы - это важно.

Разумеется в большой компании ведётся документация и есть аналитика. Даже могу быть схемы того, как приложение будет развиваться по годам. Хорошо если сайт не просто работает в сети ради благотворительности, но и приносить копеечку ). Я работал в конторе, где делали сайт и вложили в него несколько миллионов, как в разработку, так и в SEO. Но проект не выстрелил. Было обидно за потраченный труд моих коллег.

"Ведите учёт коммитов в документе" - многим не понятно о чём это я пищу. Я скажу что если вы делаете api и front в разных папках, то пишите коммиты друг напротив друга front:backend в документе. Если вы будете откатываться на несколько коммитов назад в API, то вы не сможете сразу без анализа понять на какой коммит откатиться в FRONT. Возможно вам и не придётся откатываться в FRONT приложении, но нужно будет внести небольшие изменения которые вы поймёте по нескольким коммитам.

Постарайтесь выкроить время на тесты. Мне очень нравится pytest. Сотни автоматических тестов защитят ваше приложение от критических ошибок.

Если у вас вообще не будет документации по роутам, то вы можете сделать дублирование функционала, что нехорошо. Это просто трата времени на задачу которая уже сделана. Вывод простой: хорошие привычки экономят время.

Для безопасности не делайте простой пароль 1234 для подключения к БД. Если у вас постгрес и порты для базы видны в сети интернет, то блокируйте пользователя в файле pg_hba.conf или отзываете права при помощи REVOKE CONNECT и GRANT CONNECT. Читайте статью: Как готовить базу данных postgres API приложения для prod режима.

Для разработки веб-приложений используйте готовые популярные фреймворки. Присмотритесь к асинхронным фреймворкам. Не пишите без особой надобности свои доморощенные фреймворки. Просто потеряете массу времени. Если вы питонист то посмотрите на питоновские фреймворки.