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

Цели приложения: RFQ и сравнение котировок

RFQ (Request for Quotation, «запрос котировок») — это формализованный запрос цены и условий поставки на конкретный товар или услугу с заранее заданными параметрами: количество, сроки, Incoterms/доставка, гарантия, сервис, валюта и т. п. Главная задача RFQ — получить сопоставимые предложения и выбрать лучший вариант по понятным критериям.

Важно не путать RFQ с другими форматами:

• RFI (Request for Information) — сбор общей информации о рынке и поставщиках, без обязательного сравнения цен «в лоб».
• RFP (Request for Proposal) — запрос развернутого решения: подход, команда, план, архитектура, SLA; цена важна, но обычно не единственная ось выбора.

Какие боли решает приложение

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

Отдельная боль — ручное сведение котировок: кто-то прислал цену с НДС, кто-то без; сроки указаны в рабочих днях, а не календарных; доставка включена только у части участников. Приложение должно снимать именно эти «трения», а не просто дублировать табличку в вебе.

Целевые результаты

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

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

Границы применения

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

Эти границы помогают не раздувать MVP и не смешивать разные процессы в одном интерфейсе.

Пользователи и роли: кто что делает

Чёткие роли — основа понятного workflow закупок: кто инициирует RFQ, кто оценивает, кто отвечает, а кто только наблюдает и согласует. Если не договориться об этом заранее, система быстро превращается в «чат с файлами» и несколькими версиями правды.

Покупатель (инициатор)

Инициатор создаёт RFQ, заполняет позиции, сроки и условия, выбирает круг поставщиков и публикует запрос. На нём же — коммуникации: ответы на вопросы, уточнения, напоминания и фиксация договорённостей прямо в карточке RFQ (а не в почте).

Категорийный менеджер

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

Поставщик

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

Администратор

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

Наблюдатель / финансы / юрист

Эти роли обычно не «ведут» RFQ, но влияют на исход: просматривают предложения, оставляют комментарии, участвуют в согласовании условий и проверке рисков. Для них важно разграничение прав: видеть, но не менять; комментировать, но не редактировать цифры.

Практический ориентир: у каждой роли должно быть 1–2 ключевых действия и понятный уровень доступа (просмотр, комментарии, редактирование, утверждение). Это ускоряет сравнение и снижает число спорных правок.

Сценарий от запроса до выбора поставщика

Эффективный workflow RFQ держится на простом принципе: покупатель задаёт правила один раз, а система дальше «ведёт» процесс и фиксирует всё важное — сроки, версии, ответы и решения.

1) Черновик RFQ → публикация → приглашения поставщикам

Покупатель создаёт RFQ в статусе «Черновик»: описание потребности, позиции, условия поставки/оплаты, требования к документам и дедлайн. В черновике удобно согласовать текст внутри компании.

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

2) Вопросы и ответы (Q&A) с фиксацией времени и видимости

Поставщики задают вопросы в отдельном потоке Q&A. Для каждого вопроса фиксируются автор, время и статус ответа.

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

3) Приём предложений до дедлайна и контроль полноты

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

4) Сравнение, запрос уточнений, короткий список

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

5) Выбор победителя, протокол, экспорт

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

Требования и MVP: что сделать в первую очередь

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

MVP‑функции (минимум, который должен работать)

1. Создание RFQ: покупатель задаёт сроки, условия, список позиций и критерии оценки.

2. Приглашения поставщиков: выбор из списка/ввод e‑mail, отправка ссылок, контроль статуса «приглашён/открыл/ответил».

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

4. Сравнение предложений: таблица по позициям и итогам, базовый расчёт итоговой стоимости и подсветка несоответствий.

Обязательные поля и минимальные справочники

Чтобы предложения были сопоставимы, договоритесь о «жёстком минимуме»:

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

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

Ограничения первой версии (что сознательно не делаем)

Без сложных согласований, многоуровневых ролей, EDI/ERP‑интеграций и продвинутых правил доступа по подразделениям. Эти вещи часто «съедают» сроки — лучше планировать их после пилота.

Метрики успеха

Заложите измеримость с первого дня:

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

Локализация, валюты и единицы измерения

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

Модель данных: сущности и связи

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

Практичный подход: сразу отделить «запрос» (RFQ) от «позиций» (line items) и от «котировок» (quotes), чтобы поставщики могли отвечать частично, а покупатель — сравнивать по строкам.

RFQ как «контейнер» процесса

Сущность RFQ обычно хранит метаданные и управление жизненным циклом:

• Идентификатор (человекочитаемый номер + внутренний UUID)
• Статус (черновик → опубликован → сбор предложений → закрыт/отменён)
• Дедлайны: крайний срок вопросов, крайний срок подачи котировок, дата решения
• Владелец (ответственный закупщик) и, при необходимости, команда/подразделение
• Категория (для фильтрации, прав доступа, аналитики)

Связи: RFQ 1→N к позициям и 1→N к приглашённым поставщикам.

Позиции RFQ (line items)

Позиции — это то, что реально сравнивается:

• Номенклатура/описание (SKU, артикул, свободный текст)
• Количество и единицы измерения
• Требования: спецификация, допустимые аналоги, условия поставки, требования к качеству

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

Поставщик и контакты

Сущность Поставщик и связанные Контакты поддерживают управление поставщиками:

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

Связи: поставщик 1→N контактов; поставщик N↔N RFQ через таблицу «приглашения» (с датой приглашения и статусом участия).

Котировка: ответ поставщика

Котировка привязывается к конкретному RFQ и поставщику и содержит:

• Цены по позициям (часто отдельной сущностью QuoteLine)
• Сроки (поставка, производство, срок действия предложения)
• Условия: Incoterms/доставка, оплата, гарантия
• Валюта, НДС/налоги (явно, чтобы правильно сравнивать)
• Вложения (коммерческое, спецификации, сертификаты)

Рекомендуется хранить версионность котировки (черновик/отправлено/отозвано) и историю изменений.

Коммуникации и аудит

Чтобы снизить хаос в переписке, полезно завести сущности:

• Q&A (вопросы и ответы) с привязкой к RFQ и, при необходимости, к позиции
• Комментарии (внутренние и для поставщика — раздельно)
• События аудита: кто что сделал (публикация RFQ, изменение дедлайна, отправка котировки)

Это упрощает контроль, соответствие требованиям и разбор спорных ситуаций без поиска «по письмам».

Интерфейс покупателя: создание и публикация RFQ

Покупательский интерфейс — место, где RFQ формируется быстро и без ошибок. Хорошая цель: менеджер закупок создаёт запрос за 10–15 минут, а коллеги понимают, что именно ушло поставщикам.

Форма RFQ: автосохранение и проверки

Сделайте форму «живой»: автосохранение черновика каждые 10–20 секунд и явный индикатор статуса (Черновик → На согласовании → Опубликован). Если пользователь закрыл вкладку, он должен вернуться туда, где остановился.

Проверки заполнения лучше разделить на два уровня:

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

Загрузка позиций из шаблона (CSV/XLSX)

Для большинства RFQ позиции удобнее импортировать. Дайте шаблон с колонками (SKU/описание, количество, единица, требуемый срок, комментарий) и встроенную валидацию:

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

Показывайте результат импорта как предпросмотр с подсветкой проблем, чтобы пользователь исправил всё до публикации.

Управление версиями RFQ

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

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

Критерии оценки и права доступа

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

Права доступа: кто может редактировать, кто — публиковать, кто — только просматривать. Типовой минимум — роли «Автор», «Согласующий», «Публикатор» плюс журнал действий для внутреннего контроля.

Портал поставщика: подача котировок без лишних шагов

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

Приглашение и вход

Оптимальный старт — приглашение по email с одноразовой ссылкой. По ней поставщик сразу попадает в нужный RFQ, без поиска и ручного ввода идентификаторов.

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

Панель поставщика: минимум, но по делу

На главном экране достаточно списка RFQ с простыми статусами: «Приглашён», «Черновик», «Отправлено», «Отозвано», «Просрочено». Рядом — дедлайн, контакт закупщика и быстрый переход к форме.

Полезная деталь: предупреждение за 24/3 часа до дедлайна прямо в интерфейсе, чтобы поставщик не пропустил срок.

Форма котировки: позиции + общие условия

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

Загрузка документов без хаоса

Добавьте загрузку документов (сертификаты, спецификации) с ограничениями типов и размеров: PDF/DOCX/XLSX/JPG, лимит на файл и общий лимит на заявку. Покажите список вложений, кто их увидит, и фиксируйте версии при обновлениях.

Отправка, отзыв и обновления до дедлайна

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

Сбор и нормализация предложений: чтобы сравнивать корректно

Даже идеальный RFQ превращается в «яблоки против апельсинов», если поставщики присылают цены в разных валютах, с разными единицами измерения и по-разному трактуют налоги и скидки. Поэтому сбор предложений — это управляемый процесс приведения данных к единому стандарту.

Валидация на входе

Сделайте так, чтобы система не принимала предложение, пока не заполнены обязательные поля и не пройдены базовые проверки:

• обязательные позиции и количество, срок поставки, валюта, условия оплаты/доставки;
• допустимые диапазоны (например, срок поставки не может быть отрицательным, скидка — больше 100%);
• единицы измерения только из справочника (шт, кг, час и т. п.), чтобы не появлялись «pcs/pc/шт.»;
• формат налогов: явно указать, включён ли налог в цену и какая ставка применяется.

Проверки лучше делать и на фронтенде (для удобства), и на сервере (для надёжности).

Нормализация: единые правила сравнения

После сохранения предложения система должна рассчитывать «нормализованные» значения, не затирая оригинал:

• пересчёт валют по курсу на фиксированную дату (например, на момент дедлайна RFQ) или по политике компании;
• приведение скидок к одному виду (процент/фикс) и расчёт итоговой цены строки;
• единый формат налогов и итогов: цена без налога, налог, цена с налогом.

Храните вместе с расчётом и курс, и дату курса — иначе позже будет сложно объяснить происхождение цифр.

Альтернативы и частичные поставки

Разрешите поставщику честно указать отклонения: аналог вместо запрошенной модели, минимальная партия, частичная поставка по графику. Для этого удобно разделять:

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

Структурированные данные vs файлы

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

Дедлайны и опоздавшие предложения

Заранее определите политику: автоматически помечать опоздавшие предложения как «late», запрещать редактирование после дедлайна, но разрешать просмотр и отдельное одобрение покупателем. Это снимает споры и сохраняет прозрачность процесса.

Сравнение котировок: таблицы, TCO и критерии

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

Таблица сравнения по позициям

Основа интерфейса — таблица «позиции × поставщики». Для каждой позиции показывайте ключевые поля: цена, срок поставки, MOQ (минимальная партия), условия оплаты/поставки, срок действия предложения.

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

TCO: сводная стоимость, а не только цена

Рядом с ценой по позиции и итогом по поставщику выводите составляющие полной стоимости:

• доставка и страхование;
• налоги/пошлины;
• скидки (объёмные, промо, ранняя оплата);
• доп. услуги: упаковка, калибровка, монтаж, расширенная гарантия.

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

Фильтры, группировки и «риск»

Чтобы не утонуть в данных, добавьте фильтры и группировки: по поставщику, по позиции/категории, по отклонениям от требований, по рискам (например, просрочки, отсутствие сертификатов, нестабильные сроки).

Балльная оценка и прозрачное решение

Сделайте балльную модель с настраиваемыми весами (цена, срок, качество, условия). Разрешите ручную корректировку балла, но обязательно требуйте короткое объяснение — это дисциплинирует и помогает в аудите.

Экспорт и протокол выбора

Экспорт отчёта в PDF/XLSX должен включать таблицу сравнения, расчёт TCO, применённые фильтры/веса и «протокол выбора» (кто и когда утвердил, почему выбран поставщик). Это экономит время на согласованиях и снижает спорные ситуации.

Коммуникации, уведомления и интеграции

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

Обсуждения внутри команды

Покупателю обычно важны короткие обсуждения прямо в контексте позиции или всего RFQ: комментарии, упоминания коллег и мини‑задачи.

Практичный минимум:

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

Так меньше переписок, а новым участникам проще понять, что уже решено.

Q&A с поставщиками: публично и приватно

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

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

Критически важна история: вопрос, ответ, кто автор, версия спецификации на момент ответа. Тогда изменения требований не превращаются в спор.

Уведомления, которые не раздражают

Уведомления должны быть событийными и управляемыми: публикация RFQ, изменения в спецификации, новые вопросы/ответы, напоминания о дедлайне, «котировка отправлена/обновлена». Дайте настройки частоты (сразу/дайджест) и канала (почта, внутри приложения).

Интеграции по необходимости

Начните с простого: почтовые уведомления и SSO (например, SAML/OIDC) для корпоративных аккаунтов. Дальше — интеграции через API: выгрузка выбранного предложения в ERP/CRM, синхронизация справочников контрагентов, статусы согласований. Полезно предусмотреть вебхуки «RFQ опубликован», «дедлайн изменён», «поставщик подал котировку».

Логи событий для контроля

Аудит‑лог помогает разбирать спорные ситуации и готовить внутренние отчёты: кто пригласил поставщика, кто менял условия, когда открывали и сравнивали предложения. Делайте логи неизменяемыми, с фильтрами и экспортом — это снижает риски и ускоряет внутренние проверки.

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

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

Аутентификация и роли: принцип минимальных прав

Задайте роли и права так, чтобы пользователь видел только то, что нужно для его задачи: покупатель — свои RFQ и ответы, поставщик — только приглашённые запросы, руководитель — отчёты и утверждения.

Практика: отдельные разрешения на создание RFQ, приглашение поставщиков, просмотр цен, утверждение выбора, выгрузку файлов.

Разграничение видимости котировок (до/после дедлайна)

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

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

Аудит и контроль изменений

Встроенный журнал действий должен отвечать на вопросы «кто, что, когда и откуда изменил»:

• изменения статусов RFQ и котировок;
• правки позиций, единиц измерения, файлов;
• действия по утверждению/отклонению.

Сделайте экспорт журнала (CSV/PDF) и неизменяемые события для критичных действий.

Защита данных: шифрование, бэкапы, хранение файлов

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

Анти‑подмена: версии и неизменяемые статусы

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

Архитектура и технологии: практичный выбор стека

Для RFQ‑системы чаще всего не нужен «космический» стек. Важнее предсказуемость, безопасность и удобная поддержка. Стартуйте с простого решения, которое можно масштабировать без переписывания.

Монолит на старте — микросервисы при росте

Для MVP обычно выигрывает модульный монолит: единое приложение, общая база, понятный деплой.

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

API: REST или GraphQL, версионирование и лимиты

REST хорошо подходит для типовых операций (RFQ, позиции, котировки, статусы), особенно если планируются интеграции с ERP/почтой/SSO.

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

Обязательно продумайте:

• версионирование (/api/v1) или через заголовки, чтобы менять контракт без поломок;
• ограничения запросов (rate limiting) и квоты для публичных частей портала поставщика;
• идемпотентность для повторных отправок котировок.

Данные, файлы, поиск и наблюдаемость

Для RFQ и котировок чаще всего оптимальна реляционная БД (PostgreSQL): связи, транзакции, аудит.

Файлы (ТЗ, спецификации, прайсы) лучше хранить в объектном хранилище (S3‑совместимом), а в БД — только метаданные и ссылки.

Для поиска и фильтрации начните с индексов и продуманной схемы; полнотекст подключайте по необходимости.

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

Как ускорить разработку MVP с TakProsto.AI

Если цель — быстро проверить гипотезу и провести пилот, разумно собрать первую версию на платформе TakProsto.AI. Это vibe‑coding подход: вы описываете workflow (статусы RFQ, роли, Q&A, сравнение, экспорт), а дальше через чат итеративно собираете веб‑приложение без долгой рутины программирования.

Практично, что TakProsto.AI из коробки ориентирован на российский рынок: развёртывание и хостинг на серверах в России, работа с локализованными и open‑source LLM‑моделями, а также экспорт исходников. Для типового RFQ‑MVP стек понятный: фронтенд на React, бэкенд на Go, база PostgreSQL. Полезны и «операционные» функции для пилота: planning mode (чтобы заранее согласовать сценарии и модель данных), snapshots и rollback (чтобы безопасно откатывать изменения), подключение кастомного домена.

По тарифам можно стартовать с Free/Pro, а при росте перейти на Business или Enterprise — когда появятся требования к расширенным доступам, SLA и процессам.

Запуск и развитие: тестирование, пилот, улучшения

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

Тестирование, которое реально снижает риски

Соберите пирамиду тестов под ключевой путь RFQ → получение котировок → выбор поставщика:

• Юнит‑тесты для расчётов (валюта, налоги, доставка, округления), статусов и правил дедлайнов.
• Интеграционные тесты для связок: публикация RFQ, приём котировки, пересчёт итогов, выгрузка отчёта.
• E2E‑тесты для «живого» сценария с ролями: покупатель создаёт RFQ, поставщик отправляет предложение, закупщик сравнивает и фиксирует решение.

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

Подготовка данных к старту

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

Сделайте шаблоны импорта (CSV/XLSX) и «песочницу» проверки: система должна подсвечивать ошибки строк и давать понятный отчёт, иначе запуск затянется.

Пилот и план развития

Начните с пилота: одна категория закупок и ограниченный пул поставщиков (например, 5–15), фиксированные правила сравнения и короткий цикл обратной связи.

После пилота развивайте систему по ценности:

• согласования и маршруты утверждений;
• каталоги и повторные закупки;
• рамочные договоры и лимиты;
• аналитика (экономия, SLA поставщиков, причины отклонений).

Так вы получите продукт, который стабильно работает «в поле» и постепенно обрастает функциями, а не усложняет процесс.