Огромное спасибо Павлу за то, что согласился взять этот проект! Наконец-то нашёл исполнителя, который устроил меня на 100%.

Если кратко, то Павел за короткий срок собрал просто шикарную архитектуру на современном стеке, с учётом последних трендов разработки.

Что особенно понравилось:

1. Выбор стека. Павел предложил грамотный набор: монорепо + Nextjs + Nestjs. Обернул всё в Docker.

2. Павел очень гибко принимал мои предложения. Например, макет фигмы у меня был свёрстан под Ant.design, но я нашёл классную библиотеку NextUI. И Павел согласился взять её в работу. Получилось отлично!

3. Павел очень хорошо понял логику работы приложения! Делал именно то, что я хотел. Было примерно так: обсудили задачу, Павел 2-3 дня работал, потом говорит: можно проверять. Я проверяю — всё точно, как я описывал.

4. Подробно объяснял, как запускать проект. Я параллельно тестировал развёртывание на своём сервере.

5. Отдельное спасибо, что исполнитель не был против, что я подключился к основному репозиторию и в отдельных ветках доделывал «фишечки» на фронте. Для меня это было важно, так как у некоторых исполнителей была фраза: «степень участия заказчика в проекте обсуждается и оценивается отдельно» O__O. Павел мёрджил мои ветки в master-ветку, разрешал конфликты, если были.

6. У Павла топовая экспертиза в настройке CI/CD: сделал так, что проект автодеплоится на сервер с помощью Jenkins.

7. Отличная командная работа: Павел консультировал других разработчиков (мы взяли фронтендера, чтобы чуть ускориться) и вводил в курс проекта.

8. Отдельное спасибо за грамотную речь и русский язык без ошибок, опечаток и т.п.

Что в итоге сделали:

1. Подготовка монорепо и бэк+фронт проектов.
2. Регистрация, авторизация пользователя и восстановление пароля.
3. Создание и тонкая настройка объекта. Очень обширный раздел, один из ключевых, со сложной логикой.
4. Раздел Команда. Так же обширный раздел, с различными привязками и зависимостями.
5. Инвайт-система: полноценное приглашение в команду проекта с системой ролей.
6. Генерация шахматки. Ещё один ключевой раздел.
7. Настройка полноценного CI/CD.

Сделали так, что бэк и фронт крутятся в одном монорепо и общаются через server actions. Благодаря этому получили очень хорошую скорость работы приложения.

Главное было сделать изначально такую архитектуру приложения, чтобы потом её можно было легко дорабатывать и дополнять новыми функциями. И это получилось.

Мы немного вышли из первоначального бюджета, но это потому, что я по ходу разработки дополнял ТЗ. Пока я генерировал мокапы фронта через Cursor AI, у меня появлялись новые прикольные идеи и фишки, которые решено было сразу внедрять.

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

Резюмируя, скажу, что очень доволен работой с Павлом. Надеюсь, следующие этапы так же буду завершать с ним, так как проект получился с большим бэклогом.

Остался доволен работой с Дмитрием, т.к. он годами занимался продумыванием удобного сервиса для строителей, и дал мне полную техническую свободу по его реализации, чтобы у меня появилась возможность соединить весь мой опыт проектирования и самые передовые тренды веб-разработки воедино. Так как для базовой вёрстки он применял AI IDE Cursor, то на проекте я смог научиться работать со сгенерированной нейросетями вёрсткой, а также сам был смотивирован рутинные задачи решать с помощью AI. Начал проект я в одиночку, но когда мы довели проект до стадии минимального MVP, то пригласили продолжать дальнейшее развитие фронтенд-части нового разработчика в команду, а мне было предложено возглавить техническую реализацию как архитектор и dev-ops, плюс по прежнему оставить за собой программирование бэкенд-части.

Разработка этого проекта позволила мне значительно улучшить навыки dev-ops, т.к. для ci/cd мне ранее уже приходилось использовать self-hosted инструмент Jenkins, но именно на этом проекте я и сам Jenkins, и облачный агент сборки обернул в docker для использования эфимерных сред при деплое - чтобы ресурсы сервера именно на ci/cd использовались бы по большей части только во время непосредственно интеграции и доставки. Само же веб-приложение благодаря полному его оборачиванию в монорепо и docker (бэкенд и фронтенд со staging + standalone mode для максимальной экономии дискового пространства сервера на хранение docker-образов и кэша сборок) деплоится каждый раз как с чистого листа, избавляя от всевозможных коллизий от артефактов предыдущих сборок.

Благодаря всесторонней помощи Дмитрия по обсуждению бизнес-логики и соответствующих сущностей, удалось спроектировать очень гибкую, функциональную и подготовленную с помощью балансировщика к кластеризации базу данных на основе Postgres, схему которой мы проектировали с использованием позволяющего хранить её в репозитории, а также просматривать онлайн несколькими участниками сервиса dbdiagram.io - далее экспортируя в Prisma. На проекте Planomer я наконец-то научился хранить схему БД Prisma отдельно от бэкенда и фронтенда, но импортируя её внутрь них в качестве интерфейсов бизнес-моделей - вместе с общими для бэка и фронта валидаторами форм + всеми необходимыми общими типами, т.к. код всего приложения хранится в одном монорепо, но любые отдельные его составляющие - инфраструктурные конфиги, либо бэкенд, либо фронтенды, да хоть вышеупомянутые общие для них модели и валидаторы данных - всё это при желании хранится в отдельных репозиториях и собирается воедино с помощью gitmodules.

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