Привет. Меня зовут Пётр, я разбираю идеи продуктов и автоматизацию для малого бизнеса. Сегодня — про MVP, который реально работает, а не про красивые презентации.

Главная ловушка

«Нам нужен бот + CRM + аналитика» — слышу это постоянно. Открываю переписку — и в 80% случаев боль в одном месте: заявка из Telegram доходит с задержкой или теряется. Остальное можно отложить.

MVP продукта — не мини-копия всего ТЗ. Это проверка одной рискованной гипотезы за 1–2 недели: один операционный сценарий, явный критерий «готово» и список того, что вы сознательно не делаете.

ИИ ускоряет прототип, но агент в ноутбуке без прод-метрики — не MVP.

Шесть шагов (код — последний)

# — Шаг — Суть

1 — Гипотеза — Что должно измениться в операции

2 — Сценарий — Кто → что → куда записано

3 — Критерий — Порог: число, срок, допустимые потери

4 — Anti-scope — Что НЕ делаем в этом цикле

5 — Живые заявки — Не демо-аккаунты

6 — Решение — Масштаб / смена гипотезы / стоп

Заказ кода — шаг 6, не шаг 1.

Гипотеза: плохо vs хорошо

❌ «Клиентам будет удобнее с ботом»

✅ «Если заявка из Telegram попадает в таблицу за 3 минуты без ручного копирования, ночные обращения перестанут теряться до утра»

Вторая формулировка можно опровергнуть. Первая — просто пожелание.

Concierge — это нормально

Владелец салона пересылает сообщения в чат, админ вносит строку в таблицу — это валидный MVP, если есть гипотеза и метрика потерь. Ручной процесс на старте — не стыдно. Стыдно — заказать разработку до проверки.

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

MVP scorecard — четыре поля

Заполняю до любого прототипа:

Поле — Пример

hypothesis — Ночные заявки из Telegram не теряются до 10:00

scenario — Клиент → бот → уведомление менеджеру → строка в таблице

done_criterion — 5 реальных заявок без потерь за 7 дней

anti_scope — Оплата, ЛК, 1С, аналитика

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

ИИ: ускоритель, не замена проверки

Cursor/n8n соберут webhook за вечер. Ловушка — пустой scorecard. NIST называет confabulation риском: агент уверенно генерит код, который пишет не в ту таблицу.

До продакшена фиксирую:

- HTTPS webhook + «secret_token«

- Не смешивать «setWebhook« и long polling

- Лог каждого Update

- Алерт, если запись не создалась за 60 секунд

- Human-fallback, если бот молчит

Зелёный lint агента ≠ production MVP.

Типичные косяки

1. Весь ТЗ в MVP — оплата, ЛК, три интеграции «на всякий случай»

2. Тест на своих — бот работает у команды, живых заявок ноль

3. Vanity-метрики — считают клики, не потери ночных сообщений

4. Нет запасного канала — webhook упал ночью, клиенты в пустоту

Когда идти в разработку

- Критерий выполнен (или провален) с цифрами

- Anti-scope согласован

- Сценарий описан так, что разработчик напишет ТЗ на один поток

- Понятна цена ошибки

Не когда «выглядит готово».

Если у вас заявки живут в Telegram, а учёт — в таблице, начните с одного scorecard на неделю.

Пётр Пашкуров, наставник

Сел и за неделю собрал MVP. Назвал Пинта. Лежит на pintly.ru.

Что там сейчас работает:

• Telegram-бот @pintly_bot для чек-инов (написал, сфоткал, поставил оценку — пиво уехало в твою историю и в ленту)

• Веб-каталог пива и пивоварен (на старте ~1000 SKU, добавляем дальше)

• Лента друзей, лайки, комментарии

• Карточки пивоварен с историей и контактами

• AI-рекомендации «что попить, если нравится вот это» — пока в зачаточном виде, но работает

Что планирую дальше:

• Распознавание этикеток с фото (сфоткал банку — бот сам нашёл в каталоге)

• Карта крафтовых баров и магазинов разливных

• Бейджи и геймификация (без этого никуда)

• Личный чат-бот «посоветуй сорт под настроение» через AI

К чему я это всё пишу.

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

Инвайт-ссылка: pintly.ru/i/pikabu-2026 (одноразовых сделал 200 штук — кто первый, того и тапки)

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

• Что зашло — какой момент в боте/сайте показался удачным

• Что не зашло — где затупили, где криво, где не нашли что искали

• Чего не хватает — фичи, без которых вы бы Untappd не сменили

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

P.S. Если ты пивовар или владелец крафт-бара и читаешь это — напиши, у меня для вас есть отдельная история, расскажу в личке.

P.P.S. Это не реклама, я не зарабатываю на этом ни копейки в данный момент. Это пет-проект, который, если получится, может перерасти во что-то большее. Но пока — пробуем.

Хорошего пива.

Мы добавили в приложение следующее:

1. Рассылка кодов авторизации

2. Поиск серверных чатов

3. Подписка у пользователя в сообщениях какая это роль

4. Переработали дизайн тредов, теперь у него больше настроек

5. Сохранение сообщений

Поиск общих чатов

Не есть что конечно, слизано с приложения Discord, но мое виденье его внутри компании немного другого формата.

В чем вообще задумка его для корпоративного мессенджера? Для начала легко найти чаты внутри команд или структур. Группировка - это настраиваемые элементы, мы вывели их в отдельный конфиг, так что поправить под компанию - 5 минут. Настраивается из настроек чата.

Подписка у пользователя в сообщениях какая это роль

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

Переработали дизайн тредов, теперь у него больше настроек

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

1. Мы расширили настройки на создание тредов

Теперь кроме названия треда и иконки можно:

• Проставить теги

• Написать нормальное описание

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

• Отфильтровать по названию, даже по одному слову в середине текста названия или описания

• Отфильтровать по тегам, идет сортировка по часто используемым

• Закрепить тред (все закрепленные всегда будут вверху, только потом будут идти не закрепленные, даже при поступлении в них новых сообщений)

Возможно, предвижу, кому-то удобнее прям внутри сообщений писать, тем самым создавая обсуждения. Потом мы добавим такое, но не в рамки обсуждения, а в рамках внутренних комментариев.

Рассылка кодов авторизации

Инфраструктура под это дело заложена в сервис авторизации. При регистрации или авторизации сервис будет отправлять на почту пользователя сообщение в формате HTML.

Пока еще не заводили отдельную почту для нашего сервиса.

Рефакторинг back-end сервисов

• Мы изменили логику проверки прав, она стала более замудренная, но в тоже время и более правильная.

Теперь Gateway (основной сервис который либо пропускает запрос, либо нет) - подключен к redis pub/sub, инвалидирует версию прав и бит маску. Если не было события изменения - берет из мемори, если была - обновляет свой кеш. Кеш одного пользователя занимает 600.B. что не является слишком много. Для тяжелых прав на 2000 пользователей в одном сервер чате это около 4.5мб. В целом - пойдет.

Кеш хранимый в gateway:

• Сервис топиков тоже потерпел изменения. теперь он не ходит в Permission сервис что бы уточнить права пользователя на просмотр, а Gateway: ProxyRouter приклеивает заголовки:

А сервис топиков их начинает парсить:

На выход топик сервис уже отдает отфильтрованные темы которые соответствуют правам пользователя внутри его роли:

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

• 50% сервисов перевели в режим публикации событий. Т.е. раньше было много HTTP вызовов между ними, что пораждало лишние задержки в 1-4мс. Мелочь, но в рамках 1000 или 10000 пользователей это уже существенная нагрузка. Теперь HTTP вызовы служат только для получения информации от другого сервиса, все события которые раньше были - переложены на Redis. Пример: Пользователь зашел в новый чат. Сервис чата сформирует событие что у него появился новый memories, сервис прав подхватит это событие и присвоит ему права и положит их в Redis, сервис Gateway увидит новые данные и заберет их к себе.

  • Мы работаем над переводом остальных сервисов, но не все так быстро))

Удаление легаси кода

При создании проекта, я вообще ничего не знал о методах разработки фронтенда. Сейчас когда нас несколько уже и мы отходим от AI разработки - начинаем сталкиваться с проблемами. Например тогдлы переключения - так как фронт писал ИИ, он в каждую форму где есть тогл - делал новый стилевый файл, и таких файлов скопилось 15+ ед. Мы перевели их на shared и пере-используем. И таких компонентов было очень много. В итоге нам получилось подчистить примерно 2к стилевых строк кода, сократить в JSX около 150 строк, потому что теперь это общие подключения.

Выделили отдельные сервисы кеша. Тонкие обёртки над универсальным key-value store для кэширования. Не хранят данные сами — только формирует ключи и инкапсулирует логику работы с одним конкретным namespace. Пример ниже:

Аналогично сделали и с WS сервисом, вынесли все WS действия в отдельные сервисы, для сообщений, топиков, прав, тредов и тп. Раньше это были одни монолитные файлы.

Большую часть действующих фронт сервисов перевели на isMobile проверку. Например анимации фона на мобилке - не нужны, мы их не грузим и в сборку они так же не попадут.

Изменения в UI

Часть изменений и доработок написал выше.

Изменение в тулбаре голосовой комнаты:

Добавили выбор устройства на ПК:

Тоглам кнопкам добавили плавный переход при нажатии, на фото это не будет видно.

Для мобильной версии сделали 2 вида тапа.

Короткий: Открывает меню взаимодействия с сообщениями

Длинный: позволяет выбрать несколько сообщений сразу. Удалить, переслать или ответить

Итог

За 25 дней мы проделали огромную работу над проектом. Работали порой и до часу ночи. Все прошлые выходные провели с утра до ночи в нашем проекте.

Сейчас у нас:

16 микросервисов бэка + 5 инфраструктурных

137 микрофронтенд сервисов. Да и кажется что "Как-то много" - действительно так, много логики.

Что сейчас:

Наши инфраструктурные сервисы готовы. Мы начинаем фазу тестирования. Активно ищем сервер в аренду с простой поддержкой и не очень дорогой. Хотели 20.04 уже запуститься, но не успели, мысли приходили на лету и где то правили, где-то дорабатывали. Плюс еще потратили кучу времени на обучение RNNoise модели. Вроде теперь давит шумы хорошо, не уровень Krisp конечно.

Спасибо за то что прочитали! Задавайте вопросы если интересно. Готовы версии для PC, IOS, Android. Они на WebWiev, но мы старались мобильные версии оптимизировать.

P.s. Если есть небольшая компания со своими мощностями в которую можно запустить тест для сотрудников не Free основе - напиши в ТГ: AN_Cayo. Настроем под вас наши конфиги и поможем расскатиться) (Ну мало ли повезет и найдется такая возможность. Без буллинга плиз)

Upd. Мессенджер не только для корпоративного общения. Для общего с функциями друзья, черные списки, E2E шифрования лс - будет чуть позже.

Самая опасная мысль на старте звучит красиво:
«Сначала сделаю нормально — потом покажу людям».

И вот тут всё и ломается.

Ты начинаешь допиливать продукт. Чуть улучшить интерфейс. Чуть доделать фичу. Чуть переписать логику. Вроде мелочи — а в итоге проходит месяц, второй… и запуска всё ещё нет.

Это классическая ошибка старта продукта: попытка сделать идеальную первую версию.

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

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

MVP как раз про обратное. Это не «урезанная версия продукта». Это способ быстро проверить: вообще есть ли смысл в этой идее или нет.

Поэтому первая версия должна быть не идеальной.
Она должна быть достаточной, чтобы ответить на один вопрос:
это кому-то нужно или нет?

Всё остальное — потом.

Самое болезненное осознание приходит не тогда, когда нет клиентов.
А когда понимаешь — ты всё это время делал не то.

Не “плохо сделал”.
Не “не дожал маркетинг”.
А просто — не то.

Самая дорогая ошибка на старте — делать продукт в вакууме.
Без понимания, как проверить спрос на идею, без попытки поговорить с реальными людьми, без ответа на простой вопрос: это вообще кому-то нужно?

Кажется, что сначала надо “сделать нормально”, а потом уже показывать.
Но по факту ты 2–3 месяца собираешь идеальную версию того, что никому не нужно.

И вот здесь ловушка:
ты не видишь ошибки, потому что ты внутри продукта.
Тебе всё логично. Удобно. Красиво.

А снаружи — тишина.

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

И самое обидное — это не техническая ошибка.
Это ошибка мышления.

Сначала кажется: “ещё чуть-чуть допилю — и пойдёт”.
Но нет. Не пойдёт.

Потому что запуск продукта — это не финальный этап.
Это и есть проверка реальности.

Вопрос простой:
ты сейчас улучшаешь продукт… или откладываешь момент, когда станет ясно, что он не нужен?

Самый неприятный момент — это не когда ты не начал.
А когда ты сделал… и тишина.

Продукт готов. Сайт есть. Кнопки нажимаются.
Ты думаешь: ну теперь-то пойдут пользователи.
Но никто не приходит.

И вот тут начинается главный вопрос:
почему продукт не получает клиентов, хотя вроде всё сделано?

Ответ обычно простой и неприятный:
ты сделал продукт без проверки спроса.

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

Кажется логичным: сначала сделать нормально, потом показывать.
Но в реальности работает наоборот:
сначала проверка → потом продукт.

Проблема в том, что люди думают:
“если сделаю хорошо — клиенты сами придут”.

Не придут.

Потому что клиентам не нужен “хороший продукт”.
Им нужно решение конкретной проблемы, о которой ты мог вообще не угадать.

И вот ты сидишь с готовым MVP,
гуглишь “как найти первых пользователей”,
и понимаешь, что надо было делать это на два месяца раньше.

Самое болезненное — ты потратил время не туда.

Не на то, чтобы понять рынок.
А на то, чтобы сделать “красиво”.

И теперь вопрос:
ты будешь дорабатывать дальше…
или сначала наконец проверишь, кому это вообще нужно?

Отсюда и возникает классическая история:
человек месяцами “готовится”, но так и не проверяет спрос на идею.

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

Не идеальный. Не красивый.
Просто существующий.

И да, это и есть тот самый MVP, про который все читают… но не делают.

В какой-то момент стоит честно спросить себя:
ты реально работаешь над запуском или просто откладываешь момент, когда придётся узнать правду?