Минимальная версия платформы коллективных закупок с модульной архитектурой: сначала поставщик и товар (нет товара — нет покупки), затем покупатель, затем деньги и логистика. Ядро + 13 модулей, каждый из которых может разрабатывать отдельный программист параллельно.
Как я понимаю проект «Родной» — в целом, глазами продавца и глазами покупателя. Это пространство для общего разговора о смысле и направлении. Замечания по конкретным задачам, компонентам ядра и модулям — в их обсуждение (кнопка 💬 у каждой).
«Родной» — это инфраструктура доверия для совместных закупок. Не маркетплейс и не очередной Telegram-бот, а слой, который превращает коллективную покупку из хаотичного чата в защищённую сделку. Сегодня в Telegram-СЗ всё держится на личном доверии к организатору: деньги переводят на карту, набор может провалиться, скам обрушивает группу. Мы строим платформу, где деньги замораживаются эквайрингом до подтверждения получения, поставщик верифицируется по ИНН через Контур.Фокус, а споры разбирает арбитраж платформы. Архитектурно — ядро (8 компонент) и 13 модулей поверх него, каждый модуль закрывает одну задачу и может разрабатываться отдельным разработчиком параллельно. Пилот — Москва, 3–5 поставщиков, 30–50 пулов, 13 недель. Подтверждаем гипотезу двумя числами: ≥40% пулов собираются и ≥25% участников возвращаются.
Поставщик видит в «Родном» новый канал продаж без затрат на маркетинг. Аудитория совместных закупок уже есть в Telegram — мы просто переносим её на платформу, где нет риска «провалился набор» (деньги под защитой) и нет ручной бухгалтерии (чеки 54-ФЗ уходят автоматически, акты с поставщиками раз в месяц, выгрузка в 1С). Верификация по ИНН становится маркетинговым бейджем, который в Telegram-СЗ невозможно подтвердить иначе, чем отзывами. Один человек ведёт 30+ пулов одновременно благодаря каталогу, реестру заказов и автогенерации накладных СДЭК. Главное — деньги приходят автоматически после подтверждения получения, T+1, без «переведите на карту, а потом исчез». Платформа берёт комиссию 4%, но взамен даёт готовый поток покупателей, защиту от скама со стороны покупателей и аналитику по собираемости пулов.
Покупатель видит в «Родном» доступ к оптовым ценам без обязательства «купи 50 штук». Присоединяешься к пулу из 20–50 человек — платишь как оптовик, экономия 15–40% относительно розницы. Главное — деньги под защитой: оплата замораживается платёжным шлюзом, поставщик получает деньги только после подтверждения получения. Если пул не собрался до дедлайна — авто-возврат за 3 рабочих дня. Поставщики проверены по ИНН (действующая компания, не в банкротстве, не массовый директор) — бейдж «проверен» виден в каждой карточке пула. Статусы прозрачны: «набор идёт» → «пул собран, деньги заморожены» → «отправлено» → «прибыло, подтвердите получение», с push в Telegram без необходимости спрашивать «ну как там?» в чате. Если что-то не так — открывается тикет, прикладываются фото, платформа разбирает и возвращает деньги. Все пулы — в одном кабинете, одна история заказов, вместо 10 разных чатов и 10 разных организаторов.
Структурированное описание преимуществ с карточками — в разделе Видение проекта ниже. Конкретные задачи — в Фазах реализации. Каждый компонент ядра и каждый модуль имеет своё обсуждение.
Зачем мы строим «Родной», какую проблему решаем и что получают с каждой стороны. Это раздел для общего разговора о смысле — комментируйте замысел в целом и каждое преимущество отдельно.
Сегодня совместные закупки в России живут в Telegram-чатах и WhatsApp-группах. Поставщик объявляет оптовую цену, собирает заявки, деньги переводят на карту — и весь этот процесс держится на личном доверии к организатору. Любой скам — даже случайный — обрушивает группу, и покупатели остаются без денег, а честные поставщики — без клиентов. Мы строим «Родной» — платформу, где совместная закупка превращается в защищённую сделку: деньги замораживаются платёжным шлюзом до подтверждения получения, поставщик верифицируется по ИНН, споры разбирает арбитраж платформы. Это не маркетплейс и не очередной Telegram-бот — это инфраструктура доверия для коллективных покупок, которая делает их безопасными настолько, что ими можно пользоваться ежедневно.
Архитектурно мы строим ядро (аутентификация, платежи, файлы, аудит) и 13 модулей поверх него — каждый модуль закрывает одну пользовательскую задачу и может разрабатываться отдельной командой. Пилот запускается в одном городе (Москва) с 3–5 поставщиками и 30–50 пулами за 13 недель. Если метрики сходятся — масштабируем на новые города и категории; если нет — пересматриваем гипотезу с реальными пользователями, а не с презентации.
Новый канал продаж без затрат на маркетинг и логистику. Платформа приводит готовую аудиторию, готовит чеки и закрывающие документы, защищает от скама со стороны покупателей.
Доступ к оптовым ценам без обязательства «купи 50 штук». Защита денег, прозрачные статусы доставки, все пулы в одном кабинете — без десятка Telegram-чатов.
План — живой документ. Комментируйте любой пункт: замечание, вопрос, правка срока. Статус комментария: новый → прочитан → учтён. Каждый компонент ядра и каждый модуль имеет свой раздел для обсуждения архитектурных решений.
Каждая задача имеет ID (например, P2-3, M-POOL, C-AUTH), статус, фазу и ожидаемый результат.
Под каждой задачей — кнопка с числом комментариев. Откройте и напишите замечание.
Комментарии разбираются раз в неделю, план обновляется, статус меняется на «учтён».
Платформа = Ядро (общая база) + Модули (независимые функции). Ядро делается первым и обязательно для всех модулей. Модули разрабатываются параллельно разными разработчиками: у каждого свой репозиторий, свои таблицы в БД и свой API-контракт. Это позволяет масштабировать команду без блокировок.
┌──────────────────────────────────────────────────────────────┐ │ МОДУЛИ (пользовательские) │ │ M-SUPPLIER M-CATALOG M-POOL M-VERIFY M-BUYER M-PAY │ │ M-LOGISTICS M-ADMIN M-ANALYTICS M-NOTIFY-TG M-CHAT │ └────────────────────────┬─────────────────────────────────────┘ │ API contracts (REST/JSON) ┌────────────────────────┴─────────────────────────────────────┐ │ ЯДРО │ │ C-AUTH C-DB C-API C-DESIGN C-NOTIFY C-FILES C-AUDIT C-CONFIG │ └──────────────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────────────┐ │ PostgreSQL · Redis · S3-совместимое хранилище · Bun │ └──────────────────────────────────────────────────────────────┘
Ядро — обязательная база. Без него не работает ни один модуль. Делается в первую очередь (Phase 0, недели 1–2). Каждый компонент — отдельный пакет с публичным API.
Телефон + СМС-код (без паролей), JWT access/refresh. Роли: buyer, supplier, admin. Ограничение по IP при админ-доступе.
Общие таблицы: users, organizations, addresses, audit_log, file_attachments. Миграции через Prisma. Каждый модуль имеет свой namespace (схему).
Единая точка входа для фронтенда и внешних интеграций. Роутинг по модулям: /api/{module}/.... Валидация, rate-limit, версионирование.
118 токенов, 18 компонентов (DC-01..DC-18). Машиночитаемый каталог design-index.json. Смена темы — правка одного файла tokens.css.
✓ готово · v1.0
Абстракция над каналами: SMS, email, Telegram, push. Шаблоны в БД, очередь отправки, retry-логика. Модули шлют события — ядро решает куда.
S3-совместимое (MinIO/Yandex Object Storage). Загрузка фото товаров, документов верификации, закрывающих актов. Превью и водяные знаки на лету.
Все изменения сущностей: кто, когда, что, было/стало. Для арбитража споров и комплаенса (152-ФЗ, хранение 5 лет). Неизменяемый лог.
Функциональные флаги (вкл/выкл модулей), тарифы комиссии, лимиты. Меняется без редеплоя. Админка для редактирования.
Каждый модуль — отдельный репозиторий. Имеет свой namespace в БД (schema_supplier, schema_catalog, ...) и публичный API-контракт. Зависимости от других модулей — только через их публичный API, не через прямой доступ к их таблицам. Это позволяет разработчикам работать независимо.
Анкета, реквизиты, банковские счета, дашборд. Создание пулов, реестр заказов, выгрузка CSV.
CRUD товаров, категории, теги, атрибуты. Фото, спецификации. Поиск по каталогу.
Жизненный цикл: черновик → активен → собран → отгружен → закрыт. Тиры цен, дедлайны, счётчики.
Проверка поставщиков по ИНН (Контур.Фокус), anti-fraud покупателей, арбитраж споров.
Профиль, адреса доставки, мои пулы (активные + история), подтверждение получения.
Подписки на события, статусы пула, напоминание за 24ч до дедлайна, подтверждение получения.
ЮKassa/CloudPayments, заморозка средств, авто-возврат, выплата поставщику, чеки 54-ФЗ.
Модерация пулов, управление пользователями, разбор споров, финансовая сводка, feature flags.
API СДЭК (накладные, трекинг), самовывоз у поставщика, статусы доставки, подтверждение получения.
Метрики пилота, дашборд поставщика и платформы, экспорт отчётов, NPS, retention.
Реферальная программа v2, промо-коды, email-рассылки, сеть блогеров с % с продаж.
Полнотекстовый поиск (MeiliSearch), персональные рекомендации, похожие пулы.
Внутренние сообщения, шаблоны ответов, эскалация в арбитраж. WebSocket + REST.
Правило зависимостей: модуль может зависеть от ядра (C-*) свободно, от других модулей (M-*) — только через их публичный API. Прямой доступ к чужим таблицам запрещён — это сохраняет изоляцию и позволяет заменять реализацию модуля без каскадных правок.
Шесть фаз, 13 недель. Каждой задаче — конкретная неделя. Внутри фазы работы идут параллельными треками (юрист / разработчик ядра / разработчик модуля). Фазы пересекаются на стыках: P1+P2 на неделе 5, P2+P3 на неделе 7, P3+P4 на неделе 9 — это нормально, команды переходят на новые модули, пока предыдущие доходят до релиза.
Цель: принять деньги легально + поднять ядро платформы. Без юр. базы нет доверия, без ядра — не на чем собирать модули. Три трека идут параллельно: юрист оформляет документы, разработчик ядра А поднимает C-DB + C-API (нед. 1) → C-AUTH + C-AUDIT (нед. 2), разработчик ядра Б — C-NOTIFY + C-FILES (нед. 2) + C-CONFIG (нед. 2).
ИП или ООО, УСН. Определить ОКВЭД (агентская деятельность, торговля). Регистрация 3–5 дней. Без этого нельзя открыть эквайринг и работать с чеками. Стартуем в первый день — без ИП/ООО нельзя подписать договор с ЮKassa.
Публичная оферта покупателя, договор-оферта поставщика, агентская схема с выделением комиссии. Шаблоны согласовать с юристом. Основа доверия и законной заморозки средств. Параллельно с P0-1: пока идёт регистрация, юрист готовит тексты.
ЮKassa или CloudPayments: карты + СБП по QR, агентская схема с отложенным расчётом. Арендованная касса (АТОЛ Онлайн / Orange Data) + ОФД. Чеки на email/телефон автоматически. Стартует когда ИП/ООО готово (после P0-1).
Политика конфиденциальности, согласия на ПДн, уведомление Роскомнадзора. Публичные правила под ФЗ-2725: верификация поставщиков, арбитраж споров, сроки возвратов, хранение данных 5 лет. Закрывает юридическую базу.
Phone + СМС-код (без паролей), JWT access/refresh. Роли: buyer, supplier, admin. SMS-провайдер: SMS.ru или SMSAero. Тестовый режим с кодом 1111 для дев-среды. Стартует после C-DB (нужна таблица users).
PostgreSQL с миграциями Prisma. Общие таблицы: users, organizations, addresses, audit_log, file_attachments. API gateway на Hono/Bun: роутинг /api/{module}/..., валидация, rate-limit, OpenAPI-схема. Стартует в первый день недели 1 — это фундамент для всех остальных компонент.
C-NOTIFY: абстракция над SMS/email/TG/push, шаблоны в БД, очередь BullMQ + Redis. C-FILES: S3-совместимое хранилище (MinIO или Yandex Object Storage), presigned URLs, генерация превью. Параллельно с C-AUTH (трек B), в команде разработчика Б.
C-AUDIT (трек B): append-only лог всех изменений сущностей (кто/когда/что/было/стало), для арбитража и комплаенса. C-CONFIG (трек C): feature flags и тарифы в БД, меняются без редеплоя через админку. Замыкают ядро — после них стартует P1.
Цель: поставщик зарегистрирован, верифицирован, завёл товары и создал пулы. Четыре модуля стартуют одновременно на неделе 3 (независимые репозитории), затем сходятся к неделе 5. Это самая плотная фаза — 4 разработчика параллельно.
Интеграция Контур.Фокус API: проверка ИНН/ОГРН, действующая ли организация, нет ли массового директора, не в банкротстве. Результат: статус «проверен» или «требует документов». Без верификации нельзя публиковать пулы. Стартует первой — без верификации остальные модули поставщика не имеют смысла.
Анкета поставщика: юр. реквизиты, банковские счета, контактные лица, публичное описание. После верификации (P1-1) — бейдж «проверен» в карточке пула. Профиль редактируется в любой момент, изменения логируются в C-AUDIT. Параллельно с P1-1 (независимый репозиторий).
CRUD товаров: название, описание, фото (через C-FILES), спецификации, состав. Категории и теги для навигации. Атрибуты категории (например, объём для косметики, вес для продуктов). Один товар может быть в нескольких пулах. Самый компактный модуль — обычно закрывается за одну неделю.
Товар из каталога (M-CATALOG), 3 тира цен, минимальный объём каждого тира, дедлайн сбора, лимит партии. Самовывоз да/нет. Жизненный цикл: draft → moderation → active → collected → shipping → closed. Стартует на нед. 4 — нужно дождаться готовности M-CATALOG на нед. 3.
Расчёт текущей цены по числу участников: если 5–19 — тир 1, 20–49 — тир 2, 50+ — тир 3. Живой счётчик «осталось N человек до скидки». Дедлайн в днях/часах. Логика в M-POOL, UI зависит от фазы P2 (когда появляется фронт покупателя). Делается сразу после P1-4 в той же неделе.
Список пулов со статусами, обороты за период, % собравшихся пулов, скорость набора, график выплат. Один экран, без избыточной аналитики. Позже расширится модулем M-ANALYTICS. Делается после того, как P1-2 профиль готов и есть данные для отображения.
Список оплаченных заказов пула, выгрузка CSV/Excel для сборки (состав, количество, адреса доставки). Отметка «отгружено» пачкой. Интеграция с M-LOGISTICS для генерации накладных (придёт в P4). Замыкает M-SUPPLIER.
Каркас разбора споров: покупатель и поставщик могут открыть тикет, прикрепить доказательства (фото, переписку), админ разбирает. Полный арбитраж приходит в P3 с M-ADMIN, но база нужна уже в P1 чтобы покрывать edge-cases при пилоте. Вторая задача Dev 1 после P1-1.
Цель: покупатель видит пул, понимает выгоду и присоединяется. Стартует на неделе 5, параллельно с финалом P1 (M-SUPPLIER P1-7 + M-VERIFY P1-8). Два модуля: M-BUYER (кабинет покупателя, нед. 5–7) + M-NOTIFY-TG (Telegram-бот, нед. 6).
Главная страница покупателя: активные пулы с актуальной ценой, счётчиком «осталось N до скидки» и дедлайном. Фильтры по категории и городу. Карточка пула: фото товара, состав, 3-уровневая лесенка цен (читает M-POOL), профиль поставщика с бейджем верификации (читает M-VERIFY). Read-only — пишется в M-BUYER, читает из M-POOL/M-CATALOG/M-VERIFY.
Телефон + СМС-код (через C-AUTH). Минимум полей: имя, телефон, город доставки. Адрес доставки добавляется при первом заказе. Восстановление по СМС. Роль buyer по умолчанию, может стать supplier через M-SUPPLIER. Параллельно с P2-1.
Кнопка «Участвовать» в карточке пула: выбор адреса доставки (или самовывоз), количество единиц, переход к оплате (M-PAY в P3). Счётчик участников обновляется в реальном времени. Подтверждение фиксирует цену на момент присоединения.
Мои пулы со статусами (набор → собран → отгружен → получен), история заказов, реквизиты доставки. Кнопка «Подтвердить получение» — запускает выплату поставщику (M-PAY P3-4). Управление подписками на уведомления. Параллельно с P2-3.
Подписка на события пула: «набор идёт», «пул собран, заморозка средств», «отправлено», «прибыло, подтвердите получение». Напоминание за 24 ч до дедлайна. Команды: /mypools, /settings, /invite. Встаёт поверх C-NOTIFY из ядра — отдельный канал отправки.
Покупатель подтверждает получение заказа — сигнал для M-PAY (P3-4) на выплату поставщику. Окно подтверждения: 7 дней с момента доставки, после — авто-подтверждение. Если есть претензии — открывается тикет в M-VERIFY (P1-8 арбитраж). Замыкает фазу.
Цель: главный дифференциатор от Telegram-СЗ — защита денег. Заморозка до подтверждения получения, авто-возврат при несостоянии пула, выплата поставщику T+1. Два модуля параллельно: M-PAY (нед. 7–9, критический путь) + M-ADMIN (нед. 7, каркас админки).
СБП по QR и карта. Чек 54-ФЗ уходит автоматически через онлайн-кассу (P0-3, уже готова с нед. 2). Фискализация в момент оплаты. Идемпотентность по Idempotency-Key — повторный клик не списывает дважды. Первая задача M-PAY — без неё нельзя принимать платежи.
Деньги не уходят поставщику сразу: расчёт — после подтверждения получения покупателем (P2-6). Реализация через split-payment ЮKassa или отдельный счёт-эскроу. В UI: одна строка «деньги под защитой». Все транзакции логируются в C-AUDIT.
Пул не собрался до дедлайна → средства возвращаются автоматически в течение 3 рабочих дней. Чек-коррекция в ФНС. Реестр возвратов доступен в админке (M-ADMIN). Уведомление покупателю через C-NOTIFY (email + TG). Параллельно с P3-2.
После подтверждения получения (P2-6): сумма за вычетом комиссии платформы 4%, T+1. Реестр выплат в админку. Электронные закрывающие акты с поставщиками раз в месяц. Банковские реквизиты берутся из M-SUPPLIER (P1-2).
Автоматический реестр операций для бухгалтерии: выгрузка по дате, по поставщику, по пулу. Чеки, акты, корректировки — всё в одном месте. Интеграция с 1С через CSV-выгрузку. Параллельно с P3-4.
Модерация пулов (до публикации), управление пользователями (бан, восстановление), разбор споров из M-VERIFY (P1-8), финансовая сводка из M-PAY, редактирование feature flags из C-CONFIG. Доступ только у ролей admin, ограничение по IP. Стартует параллельно с M-PAY — модерация нужна с первого дня пилота.
Цель: товар физически доходит до покупателя. Один модуль M-LOGISTICS (один разработчик): интеграция СДЭК (нед. 9) → самовывоз + трекинг + закрытие пула (нед. 10). После доставки — сигнал в M-PAY (P3-4) на запуск выплаты.
API СДЭК: автоматическое создание накладной на партию, расчёт стоимости доставки при оформлении заказа (калькулятор), трек-номер покупателю. Статусы синхронизируются раз в час, вебхук на изменение статуса. Стартует на стыке с P3 — пока M-PAY закрывает бухгалтерию, логист уже поднимает доставку.
Альтернатива доставке: покупатель забирает заказ у поставщика. Адрес самовывоза из профиля поставщика (M-SUPPLIER P1-2). Окно выдачи: дата + интервал времени. Подтверждение получения — кодовое слово (покупатель говорит код, поставщик вводит в системе).
В кабинете покупателя (M-BUYER P2-4) — карта со статусом доставки и трек-номером. Push через C-NOTIFY при смене статуса: «в пути», «прибыло в пункт выдачи», «готов к выдаче». История доставок в личном кабинете. Параллельно с P4-2.
Когда все заказы пула доставлены и подтверждены (через P2-6) — пул переходит в статус closed. Сигнал в M-PAY на финальные выплаты (P3-4), в M-ANALYTICS на расчёт метрик пула (P5-4), в C-AUDIT на закрытие сделки. Замыкает фазу.
Цель: доказать два числа — ≥40% пулов собираются и ≥25% участников возвращаются. На нед. 11 стартует пилот (поставщики + город + M-ANALYTICS), нед. 12 — привлечение первой волны, нед. 13 — решение go / no-go по метрикам.
Личные переговоры: кофейни/HoReCa или детские товары. Поставщик проходит верификацию (M-VERIFY), заводит каталог (M-CATALOG) и 5–10 SKU, создаёт пулы еженедельно. Без них пилот не стартует — договариваться лучше начать ещё на нед. 9–10.
Москва. Логистика одной рукой (один СДЭК-договор из P4-1), самовывоз работает (P4-2), время доставки предсказуемо. Feature flag в C-CONFIG: city=msk. По результатам пилота — добавление Питера и Екб.
Посевы в Telegram-чатах совместных закупок (главный болит — скам, предлагаем защиту денег), 2–3 кейса в тематические каналы. Рефералка v1 через M-NOTIFY-TG (P2-5): команда /invite даёт пригласительную ссылку.
Дашборд: конверсия в оплату, % собранных пулов, повторные покупки, средний чек, NPS. Смотрим еженедельно. Источники данных — C-DB (транзакции) и C-AUDIT (поведение). Экспорт в CSV/Google Sheets. Параллельно с P5-1/P5-2 — должна быть готова к моменту, как появятся первые пулы.
Неделя 13: сверяем метрики с целевыми (≥55% пулов собрано, ≥30% повторных, ≥8% конверсия, ≤3% споров). Go — второй город, рефералка v2 (M-MARKETING), полный чат (M-CHAT), поиск (M-SEARCH). No-go — разбираем причины с поставщиками и покупателями, меняем гипотезу. Решение логируется в C-AUDIT с обоснованием.
Не «никогда» — «после подтверждения product-market fit». Каждая позиция возвращается в план по результатам пилота и активирует соответствующий модуль.
Покупатели формируют спрос → поставщики делают слепые ставки. Самая актуальная механика для B2B, но требует базы верифицированных поставщиков.
Пригласи друга — цена пула снижается. Виральность Pinduoduo, но только когда есть что виралить.
Каталог блогеров и каналов, % с продаж. На старте заменяется 5–10 ручными договорённостями.
4 900 ₽/мес: приоритет в выдаче, расширенная аналитика. Нет базы платящих — нет продукта.
Flash/slot-аукционы, каскадные пулы. Красиво на бумаге, смертельно для онбординга на старте.
Внутренний чат buyer↔supplier (M-CHAT), кэшбэк 1%, 9 типов бейджей, альтернативные пулы. Улучшения второго порядка.
Четыре цифры, по которым неделя 13 принимает решение go / no-go. Источник данных — модуль M-ANALYTICS, питающийся из C-DB и C-AUDIT.
| Метрика | Цель | Минимум | Что означает провал |
|---|---|---|---|
| Пулы собрались до дедлайна | ≥ 55% | 40% | Механика не цепляет — пересматривать категории и пороги |
| Повторные участники за 60 дней | ≥ 30% | 25% | Нет удержания — экономика не сойдётся |
| Конверсия посетитель → участник | ≥ 8% | 5% | Плохая витрина или невыгодный оффер |
| Споры и возвраты | ≤ 3% | 5% | Проблема с поставщиками или ожиданиями |