Как создать веб‑приложение для закупок и согласования

Цель приложения и границы проекта

Веб‑приложение для закупок нужно, чтобы переводить «хочу купить» из переписок и таблиц в управляемый процесс: заявка → согласование → заказ → приёмка → закрывающие документы. Главная цель — сделать согласование заявок на покупку предсказуемым и проверяемым: кто инициировал, кто и почему одобрил/отклонил, какой бюджет затронут и что реально было поставлено.

Какие задачи решает приложение

В MVP обычно достаточно четырёх базовых функций:

• Электронные заявки на закупку: единая форма, обязательные поля, вложения (КП, спецификации), комментарии.
• Маршруты согласования: последовательные/параллельные согласования, эскалации, замены отсутствующих.
• Оформление заказа и контроль исполнения: фиксация выбранного поставщика, суммы, сроков, поддержка частичной поставки.
• Приёмка и подтверждение факта: подтверждение количества/качества, фиксация расхождений, привязка к заявке.

Для кого подходит

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

Что автоматизировать в первую очередь

Начните с процессов, которые дают быстрый выигрыш:

1. стандартные заявки с понятными правилами согласования;
2. бюджетный «стоп‑кран» (лимиты и запрет обхода);
3. журнал действий и статусная модель, чтобы исчезли «потерянные» заявки.

Пример целевого результата и критерии успеха

Целевой результат — меньше ручных согласований и ошибок в данных: не нужно уточнять суммы, статьи, ответственных и сроки «по кругу».

Успех удобно измерять метриками: время цикла от заявки до заказа, прозрачность (доля заявок со всеми обязательными данными и историей решений), соблюдение лимитов (сколько заявок блокируется или корректируется из‑за превышений), снижение числа возвратов на доработку.

Роли пользователей и ключевые сценарии

Чтобы веб‑приложение для закупок не превратилось в «универсальную форму на все случаи», сначала зафиксируйте роли и решения, которые они принимают. Это упрощает настройку прав доступа и маршрутов согласования.

Ключевые роли и их ответственность

Инициатор — создаёт электронные заявки на закупку и отвечает за корректность данных (что купить, зачем, сроки, центр затрат).

Согласующие — руководитель, владелец бюджета, служба безопасности/ИТ/юристы (по необходимости). Их задача — подтверждать целесообразность, соответствие политике и лимитам.

Закупщик — подбирает поставщика, сравнивает предложения, фиксирует условия и ведёт коммуникации.

Бухгалтерия/финансы — проверяет статьи затрат, НДС/первичку, готовность к оплате, соответствие регламенту.

Администратор — управляет справочниками, правилами маршрутизации, ролями и правами доступа, аудитом и журналом действий.

User stories (типовые сценарии)

Инициатор: «Как инициатор, я хочу создать заявку из шаблона и приложить коммерческое предложение, чтобы ускорить запуск закупки». «…хочу отменить заявку до утверждения, если потребность исчезла».

Согласующий: «Как руководитель, я хочу видеть сумму и обоснование, чтобы быстро решить — согласовать или вернуть на доработку». «…хочу делегировать согласование на время отпуска».

Закупщик: «Как закупщик, я хочу заменить поставщика на этапе выбора, чтобы отразить лучшие условия без потери истории». «…хочу оформить частичную поставку, чтобы закрывать заявку поэтапно».

Бухгалтерия: «Как бухгалтер, я хочу проверить реквизиты и условия оплаты, чтобы снизить риск ошибок в документах».

События процесса и особые случаи

Минимальный набор событий: создание заявки → согласование → возврат на доработку → повторное согласование → отмена. Важно фиксировать причину возврата и кто инициировал изменение — это основа для аудита и анализа узких мест.

Отдельно продумайте: срочную закупку (ускоренный purchase approval workflow с обязательным пост‑контролем), замену поставщика (с сохранением версии и комментариев) и частичную поставку/закрытие (остаток в заявке, корректировка сроков и сумм).

Матрица ответственности (кто утверждает что)

Опишите правила в виде матрицы: по сумме, категории, центру затрат и риску. Например: до лимита — руководитель, выше лимита — владелец бюджета, для ИТ‑закупок — дополнительное согласование ИТ, для договоров — юрист. Чем точнее матрица, тем меньше ручных исключений и тем проще автоматизация закупок.

Сбор требований к заявке и данным

На этом этапе важно договориться не только о том, «как выглядит заявка», но и какие данные система обязана хранить так, чтобы их можно было проверять, согласовывать, передавать в учёт и анализировать.

Поля заявки: что должно быть в карточке

Минимальный набор полей стоит фиксировать вместе с финансами и закупками — иначе позже появятся «обязательные мелочи», из‑за которых заявки начнут возвращаться.

Обычно в заявке нужны:

• Номенклатура (товар/услуга), количество, единица измерения, цена и валюта
• Центр затрат и/или проект, чтобы расходы корректно попадали в аналитику
• Статья бюджета (и при необходимости — аналитики: подразделение, программа, объект затрат)
• Поставщик (если уже известен) или требования к поставщику
• Желаемая дата поставки/оказания, адрес/склад, комментарий инициатора

Отдельно решите, будет ли заявка построчной (несколько позиций) или «одним лотом». Это сильно влияет на структуру данных и проверку лимитов.

Обязательные вложения: какие документы требуются

Заранее перечислите типы вложений и правила обязательности:

• коммерческое предложение (КП)
• договор/проект договора
• спецификация
• обоснование закупки (почему нужно и почему сейчас)

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

Справочники и источники правды

Чтобы избежать ручного ввода и ошибок, определите справочники: товары/услуги, подразделения, статьи бюджета, поставщики. Важно согласовать владельца каждого справочника и частоту обновления.

Валидации, черновики и шаблоны

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

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

Проектирование маршрутов согласования

Маршрут согласования — это набор правил, по которым заявка на закупку проходит через нужных людей и фиксирует их решения. Хорошо спроектированный маршрут сокращает задержки и снижает риск «ручных исключений», которые потом сложно объяснять аудиторам.

Типы маршрутов: как выбрать логику

Обычно в приложении стоит поддержать несколько типов маршрутов, чтобы покрыть разные случаи без постоянных доработок:

• По сумме: чем выше сумма, тем больше уровней (например, руководитель отдела → финансы → директор).
• По подразделению: у каждого отдела свой набор согласующих и лимиты.
• По категории: ИТ‑оборудование, маркетинг, услуги — разные эксперты и правила.
• По проекту: заявки в рамках проекта согласуются руководителем проекта и владельцем бюджета.

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

Последовательно или параллельно

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

Важно заранее определить, что означает «параллельное согласование»: требуется все “за” или достаточно большинства/одного ответственного.

Эскалации и автоодобрение

Чтобы заявки не «зависали», задайте эскалацию: если нет решения за N часов/дней — напоминание, затем передача на замещающего или руководителя.

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

Возврат на доработку

Возврат должен быть полноценным состоянием процесса: согласующий оставляет комментарий, отмечает обязательные исправления (например, приложить КП, уточнить статью бюджета), а заявка возвращается на конкретный шаг или автору — с сохранением истории изменений и причин возврата.

Бюджетный контроль и лимиты

Бюджетный контроль — это не «бухгалтерия в интерфейсе», а набор простых проверок, которые не дают заявке уйти в работу без денег и прозрачного решения по превышениям.

Где и когда проверять бюджет

Практика показывает, что одной проверки недостаточно — лучше поставить «ворота» в нескольких точках:

• При создании заявки: быстрый предварительный контроль. Пользователь сразу видит, что по выбранному центру затрат/проекту денег мало, и может скорректировать сумму или статьи.
• Перед отправкой на согласование: фиксируется версия данных (сумма, валюта, центр затрат), чтобы в процессе согласования не «уплыла» база расчёта.
• Перед созданием заказа/договора: финальная проверка на случай, если лимит изменился, а также чтобы учесть уже зарезервированные средства другими заявками.

Типы бюджетов, которые стоит поддержать

Минимальный набор, который покрывает большинство компаний:

• Годовой/месячный бюджет (периодический лимит по подразделению).
• По проекту (например, стройка/внедрение — отдельная «копилка»).
• По центру затрат (основной управленческий разрез).

Важно заранее решить правило приоритета, если заявка попадает в несколько разрезов: например, сперва проверяем проект, затем центр затрат.

Резервирование средств (обязательства)

Чтобы избежать двойных трат, добавьте резерв:

• Резерв создаётся при переводе заявки в статус «Согласовано» или при «Отправлено в закупку» (зависит от процессов).
• Резерв уменьшает доступный лимит до момента заказа.
• При отмене/отклонении — резерв снимается.

Пример правила: «Доступный лимит = Лимит периода − Факт расходов − Резервы по согласованным заявкам».

Работа с превышениями

Не блокируйте бизнес «намертво». Лучше сделать управляемые варианты:

• Автодобавление дополнительного согласования (например, финансовый контролёр/директор) при превышении > 0.
• Запрос дополнительного лимита: отдельное действие в заявке с полем «Причина», а после одобрения — увеличение лимита или разовый допуск.

Простой пример: лимит 100 000 ₽, уже зарезервировано 80 000 ₽. Заявка на 30 000 ₽ даёт превышение 10 000 ₽ → система добавляет финальное согласование и помечает заявку как «Требует решения по превышению».

UX и интерфейсы для заявок и согласований

Хороший UX в системе закупок — это когда пользователь тратит время на решение, а не на поиск кнопок и справок. В интерфейсах заявок и согласований важно сделать процесс «прозрачным»: где сейчас заявка, кто следующий, что нужно от меня и какие последствия у действия.

Основные экраны, без которых сложно жить

Список заявок — стартовая точка для большинства ролей. Он должен отвечать на вопрос «что происходит» за 5–10 секунд: статус, сумма, автор, подразделение, поставщик (если уже выбран), дата создания и крайний срок.

Карточка заявки — место, где принимают решения. Удобно, когда она разделена на блоки: предмет закупки и обоснование, суммы и статьи, вложения, маршрут согласования, история действий.

Экран согласования можно встроить в карточку, но лучше выделить зону фокуса: что согласующий должен проверить (сумма, лимиты, документы, поставщик) и какие действия доступны.

Поиск и фильтры: меньше кликов, больше контроля

Фильтры должны закрывать типовые запросы: статус, автор, поставщик, сумма, период. Добавьте быстрые пресеты вроде «На мне», «Просроченные», «Требуют уточнения». Поиск — по номеру заявки, названию, комментарию и реквизитам.

Комментарии и история обсуждения

В карточке нужна понятная «лента» обсуждения: комментарии, упоминания, прикреплённые файлы, решения и причины отклонения. Критично, чтобы история была неизменяемой и привязана к шагам процесса: тогда легче разбирать спорные ситуации и ускорять повторные согласования.

Действия одной кнопкой и защита от ошибок

Для согласующих важны быстрые кнопки: одобрить, отклонить, вернуть на доработку, делегировать. После нажатия показывайте короткое подтверждение с последствиями (например, «уйдёт на финансовый контроль») и обязательные поля (причина отклонения).

Доступность и минимизация ручного ввода

Используйте понятные статусы, подсказки к полям и автозаполнение (подразделение автора, валюта, тип закупки, шаблоны позиций). Чем меньше вручную вводят суммы и реквизиты, тем ниже риск ошибок — и тем быстрее проходит согласование.

Модель данных и статусы процесса

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

Ключевые сущности и связи

В основе веб‑приложения для закупок обычно лежат:

• Заявка (Purchase Requisition): инициатор, подразделение/проект, валюта, итоговая сумма, комментарии, текущий статус.
• Позиция заявки: номенклатура/описание, количество, цена, НДС, центр затрат/статья бюджета, желаемая дата.
• Поставщик: справочник контрагентов (или ссылка на ERP), реквизиты, контактные данные.
• Согласование: «шапка» процесса и набор шагов (кто, когда, какое решение принял).
• Заказ (Purchase Order) и приёмка: создаются после одобрения, чтобы замкнуть цикл «заявка → заказ → фактическое получение».

Связи обычно такие: одна заявка → много позиций и одна заявка → много шагов согласования. При этом шаги могут быть последовательными или параллельными (например, финансы и безопасность).

Статусы и переходы

Минимальная цепочка: черновик → на согласовании → одобрено / отклонено. На практике полезно добавить статусы «на доработке» (когда согласующий вернул с комментариями) и «отменено» (когда инициатор снял заявку).

Важно заранее описать правила переходов: кто может переводить в «на согласовании», когда разрешено редактирование позиций, что делать с заявкой после отклонения (создавать новую или переоткрывать старую).

Вложения и доступ

Вложения (КП, спецификации, обоснования) лучше хранить как отдельную сущность, связанную с заявкой/позициями, с политиками:

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

Версионирование после согласования

Если после одобрения меняется сумма или состав позиций, не стоит «тихо» править утверждённую заявку. Практика — вводить версии:

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

Безопасность, права доступа и аудит

Безопасность в закупках — это не только «защита от взлома», но и предсказуемость процессов: кто имеет право создавать заявки, кто может их согласовывать и как доказать корректность действий при проверках.

Разграничение доступа: роли, подразделения, проекты

Начните с простой, понятной модели прав. Обычно достаточно RBAC (доступ по ролям) с дополнительными ограничителями по организационной структуре.

Например:

• Инициатор видит и редактирует только свои заявки до отправки на согласование.
• Руководитель подразделения согласует заявки своего подразделения.
• Проектный менеджер видит заявки в рамках выбранного проекта и его бюджета.
• Закупщик получает доступ к заявкам только после определённого статуса (например, «Одобрено»).

Важно предусмотреть делегирование (отпуск/замена) и запрет конфликтов интересов (инициатор не может сам себе финально согласовать).

Единый вход (SSO) и пароли, если без SSO

Если в компании есть SSO (SAML/OIDC), подключайте его: меньше паролей — меньше рисков и обращений в поддержку.

Если SSO нет, задайте минимальные требования:

• сложные пароли (длина, запрет популярных комбинаций);
• ограничение числа попыток входа и временная блокировка;
• 2FA для ролей с финансовыми полномочиями;
• обязательный выход из активных сессий при смене пароля.

Журнал действий и неизменяемые записи

Для внутреннего контроля нужен аудит: кто, когда и что сделал. Логируйте создание/изменение заявки, смену статусов, комментарии, решения согласующих, изменения маршрутов и лимитов.

Критично обеспечить неизменяемость ключевых событий: записи журнала не должны правиться задним числом даже администратором. Практика — отдельное хранилище для аудита, запрет UPDATE/DELETE (только добавление) и контроль целостности (например, хэш‑цепочки).

Защита данных: шифрование, резервное копирование, сроки хранения

Шифруйте данные при передаче (TLS) и «на диске» (шифрование баз/бэкапов). Регулярные резервные копии с проверкой восстановления важнее, чем факт их наличия.

Заранее задайте сроки хранения: заявки и аудит могут храниться дольше операционных данных. Опишите политику удаления/архивации и доступ к архиву — это снижает риски и упрощает проверки.

Уведомления и управление задачами согласующих

Хорошие уведомления — это не «спам по каждому чиху», а аккуратное управление вниманием. Согласующий должен быстро понять, что от него нужно, к какому сроку и чем это грозит (например, остановкой закупки).

Каналы: email, корпоративный мессенджер и внутри приложения

Сделайте три канала и дайте пользователю (или администратору) настройки: где получать срочное, а где — только сводки. Практика:

• Внутри приложения — «источник истины»: карточка заявки, комментарии, история.
• Email — официальный канал с возможностью найти письмо позже.
• Корпоративный мессенджер — короткие пинги, когда нужен быстрый ответ.

Важно: любые уведомления должны вести по прямой ссылке в нужное место, например: /requests/123?tab=approval.

Напоминания и дедлайны согласования

У каждой задачи согласования задайте SLA: срок реакции и срок решения. Напоминания лучше делать ступенчато: за 24 часа до дедлайна, в момент дедлайна и эскалация руководителю через N часов просрочки. При этом учитывайте календарь (выходные/праздники) и часовой пояс.

Сводка задач согласующего

В интерфейсе согласующего нужна простая «панель принятия решений»: что требует действия сейчас, что просрочено, что вернулось на повторное согласование. Добавьте фильтры по подразделению, сумме, типу закупки и «быстрые действия» (согласовать/вернуть/задать вопрос) без лишних переходов.

Шаблоны сообщений и быстрые ссылки

Сообщение должно помещаться в один экран и содержать контекст (сумма, поставщик, статья бюджета, дедлайн) и 1–2 ссылки.

Тема: Требуется согласование заявки №{id} до {deadline}

Коротко: {title}
Сумма: {amount} {currency}
Инициатор: {requester}

Открыть заявку: /requests/{id}
Принять решение: /approvals/{approval_id}

Трекер изменений после доработки

Если заявку вернули на доработку, повторное уведомление должно подсвечивать, что именно изменилось: сумма, спецификация, сроки, вложения. Минимум — список изменённых полей и ссылка на сравнение версии: /requests/{id}/changes. Это снижает раздражение и ускоряет повторное решение.

Интеграции и обмен данными

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

Базовые интеграции: ERP/учёт, номенклатура, контрагенты

Обычно нужны три потока данных:

• ERP/учётная система: бюджеты, статьи затрат, центры финансовой ответственности, факты и обязательства.
• Каталог номенклатуры: товары/услуги, единицы измерения, атрибуты, типовые спецификации.
• Справочник контрагентов: поставщики, реквизиты, статусы (активен/на проверке/заблокирован).

Сразу определите «источник истины» (source of truth): где хранятся актуальные цены, карточки поставщиков и итоговые статусы документов. Например, цены могут быть в каталоге, поставщики — в ERP, а статусы согласования — в вашем приложении.

Обмен документами: заказ на основании одобренной заявки

Ключевой сценарий — автоматическое создание заказа (PO/заказ поставщику) после финального одобрения заявки. На практике важно заранее описать:

• какие поля обязательны для создания заказа (НДС, адрес поставки, договор/рамочное соглашение);
• как передаются позиции (с единицами, валютой, скидками);
• что делать при частичном заказе или дроблении на несколько заказов.

Импорт/экспорт, API и вебхуки

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

Для системной интеграции используйте API и вебхуки: события по смене статуса заявки (создана → на согласовании → одобрена → отклонена → заказ создан) позволяют подключать уведомления, задачи в сервис‑деске и обновление данных в ERP. Подробные требования к событиям и идемпотентности запросов стоит зафиксировать заранее в техническом описании (см. /blog/requirements-for-approval-workflows).

Отчётность и аналитика закупок

Аналитика в веб‑приложении для закупок нужна не «для красоты», а чтобы управлять расходами и дисциплиной процесса. Хороший набор отчётов помогает увидеть, где теряются деньги, время и качество данных — и быстро улучшать правила согласования заявок на покупку.

Базовые отчёты, которые закрывают 80% вопросов

Начните с понятных срезов:

• Расходы по категориям (в разрезе подразделений, проектов, центров затрат) — чтобы сравнивать план и факт и подкреплять контроль бюджета цифрами.
• Скорость согласования: среднее/медиана по этапам и по согласующим — покажет узкие места в purchase approval workflow.
• Причины отклонений: топ‑5 причин, доля отклонённых заявок, повторные подачи — полезно для обучения инициаторов и корректировки маршрутов согласования.

Дашборды для руководителей

Руководителям редко нужны детали по каждой заявке. Дайте им панель «сигналов»:

• текущие лимиты и прогноз до конца месяца;
• топ‑поставщики по сумме и частоте;
• экономия: разница между запрошенной суммой и итоговой (после КП/торга), доля заявок с альтернативными предложениями.

Важно: один клик должен открывать расшифровку до конкретной электронной заявки на закупку.

Контроль соответствия и качество данных

Добавьте автоматические проверки и отчёты по нарушениям:

• заявки без КП или с неполным пакетом документов;
• превышения бюджета/лимита и попытки «дробления» сумм;
• подозрение на обход маршрутов (нестандартная цепочка согласования, ручные правки критичных полей).

Отдельно ведите метрики качества данных: доля заполненных обязательных полей, частота правок после отправки, процент заявок без категории/проекта. Это напрямую влияет на точность аналитики и успешность интеграции с ERP.

Экспорт и права доступа

Экспорт (XLSX/CSV) нужен, но только с ролевыми ограничениями. Разделяйте доступ к аналитике: финансовые показатели — для уполномоченных, операционные метрики — для руководителей команд. Журналируйте выгрузки так же, как действия в процессе согласования заявок на покупку.

Запуск, тестирование и развитие продукта

Запуск системы закупок лучше планировать как управляемый процесс: сначала — понятный MVP, затем — пилот, и только после этого масштабирование. Так вы быстрее получите пользу и снизите риск «застрять» на бесконечных доработках.

MVP: что нужно, чтобы начать

Для первого релиза достаточно цепочки «заявка → согласование → заказ» и нескольких обязательных вещей вокруг неё:

• создание заявки с минимальным набором полей (что покупаем, количество, цена/оценка, статья бюджета/проект, обоснование, вложения)
• базовый маршрут согласования (инициатор → руководитель → финансы/закупки)
• фиксация результата: согласовано/отклонено/на доработку и комментарии
• выгрузка или создание заказа (даже если это пока файл/интеграция «в одну сторону»)

Важно заранее зафиксировать, что не входит в MVP (например, сложные тендерные процедуры или продвинутые каталоги), чтобы команда не распылялась.

Тестирование перед запуском

Проверяйте не только «счастливый путь», но и то, что чаще ломается в реальности:

• сценарии смены статусов (отмена, возврат на доработку, повторное согласование)
• права доступа (кто видит суммы, вложения, чужие заявки; кто может менять маршрут)
• уведомления (не дублируются, не теряются, приходят адресатам вовремя)
• нагрузка (массовая подача заявок, пакетные согласования, отчёты)

Пилот и обучение пользователей

Запускайте пилот на одном подразделении с понятными KPI: доля заявок «в системе», среднее время согласования, количество возвратов.

Обучение делайте коротким: одна страница «как создать заявку», шаблоны заявок под типовые покупки и FAQ «почему вернули на доработку»/«что писать в обосновании».

Поддержка и развитие

Собирайте улучшения в backlog и вводите контроль изменений: кто может править маршруты согласования, как согласуются изменения лимитов и правил. Полезно завести регулярный цикл (например, раз в 2–4 недели) с приоритизацией по влиянию на скорость согласований и соблюдение бюджета.

Отдельный практический момент: если вы хотите быстро собрать рабочий прототип внутренних процессов (формы, статусы, роли, уведомления, журнал действий) и показать его бизнесу до начала «тяжёлой» разработки, можно использовать TakProsto.AI. Это vibe‑coding платформа для российского рынка: вы описываете процесс и экраны в чате, а система помогает собрать веб‑приложение на React с бэкендом на Go и PostgreSQL, с возможностью выгрузки исходников, деплоя, снапшотов и отката. Такой подход удобен именно на этапе MVP и пилота, когда важно быстро проверить маршруты согласования и модель данных на реальных пользователях.