От сотни идей в тетради до работающего стартапа: честная история «Вот бы!»

• Наша площадка https://votby.ru

• Мой блог в телеграм https://t.me/fe_notes

• Мой телеграм https://t.me/usersavchenko

Предисловие

Привет! Меня зовут Савченко Виктор и я уже почти десять лет как Frontend разработчик. За это время я дорос до позиции Senior, больше двух лет проработал тимлидом и однажды даже пытался открыть веб-студию, но разработка собственного IT-продукта долгое время так и оставалась мечтой, которую я постоянно откладывал.

18 июля 2026 года я собрал команду из числа подписчиков в телеграм и мы приступили к работе. У нас не было ни инвестиций, ни зарплат, ни готового дизайна, ни тестировщика, ни даже уверенности в том, что продукт хоть кому-нибудь будет нужен. Через месяц продукт был готов, а 7 сентября мы открыли его для пользователей.

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

Более ста идей, но ни одного продукта

В студенческие годы я сильно горел желанием создать собственный IT-продукт. Идей было так много, что я даже начал выписывать их в тетрадь. Со временем их становилось всё больше и больше и, в конце концов, накопилось больше сотни пунктов.

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

Долгие годы я ничего не предпринимал. Я строил карьеру, изучал новые технологии, рос в должности и зарплате. Работа забирала почти всё время, а собственный продукт неизменно оставался планом "на потом".

В 2026 году ситуация изменилась. Начались волны сокращений, карьерный рост остановился, а уверенность в стабильной работе исчезла. Я пробовал развивать собственный канал, проводить прямые эфиры с подписчиками и запускать платное обучение по разработке, но все эти направления не дали какого-то значимого результата, на который я рассчитывал.

Тогда, перебрав все оставшиеся варианты, я вернулся к старой мысли, отложенной на долгие годы пылиться на полке.

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

Так появилась концепция площадки, на которой один человек описывает идею или проблему, а другие могут её оценить не только лайком, комментарием, но и конкретным намерением:

• готов этим пользоваться

• готов за это платить

• готов присоединиться к разработке

• готов в это инвестировать.

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

Сообщение в телеграм, с которого всё началось

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

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

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

В команду попали люди с очень разным уровнем: некоторые ещё не работали с React, а кто-то впервые столкнулся даже с Git. Сам по себе небольшой опыт не был проблемой. Часть ребят быстро обучилась и со временем стала показывать вполне хороший результат. Проблемы возникали там, где недостаток знаний сочетался с безответственностью, плохой обучаемостью или нежеланием принимать обратную связь.

Вместо ускорения проекта опытные разработчики тратили всё больше времени на разбор одних и тех же ошибок. Количество замечаний в merge request не уменьшалось, а время уделяемое проекту падало. По этой причине пришлось принять крайне трудное решение о расставании с некоторыми участниками.

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

Вывод оказался простым: нейросеть хорошо усиливает специалиста, но не заменяет знания, необходимые для проверки её ответа.

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

За всё время через проект прошло около 18 человек, примерно шесть из них ушли. Сейчас вклад в разработку в среднем вносят около 12 участников. Примерно две трети из них занимаются frontend, одна треть - backend и 1 человек на devops. Состав постепенно меняется, но сформировавшееся на старте ядро оказалось самым устойчивым.

Месяц на MVP - срок, взятый с потолка

Мы решили попробовать собрать MVP ровно за один месяц. За этим сроком не стояло каких-то сложных расчётов: у меня не было опыта запуска собственного продукта и точного понимания объёма работ. Нам просто требовалась близкая и достаточно амбициозная цель, которая не позволит бесконечно улучшать продукт до первого релиза.

В MVP вошли:

• регистрация и авторизация

• профили пользователей

• создание и модерация идей

• главная страница со списком идей

• страница отдельной идеи

• голосование и лайки

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

К 20 августа основной функционал был готов. Ещё около десяти дней ушло на то, чтобы развернуть и обезопасить систему на сервере. Затем мы принялись исправлять критические ошибки, и 7 сентября состоялся публичный релиз.

Мы действительно успели сделать MVP примерно за месяц. Правда, как позже выяснилось, это было только первой половиной успеха.

Почему scrum нам не подошёл

Сначала мы пытались работать двухнедельными спринтами и ориентироваться на подходы scrum. В теории всё выглядело знакомо и правильно. Но на практике у каждого участника была основная работа, собственный график и разное количество свободного времени. Человек мог активно заниматься проектом одну неделю и почти полностью выпасть на следующей.

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

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

Мы используем упрощённый git flow с ветками feature, fix, release и main. Исправления текущего релиза попадают в release, а затем автоматически переносятся в main. Новый функционал - только в main. После того, как все фичи в main готовы, создаётся новая релизная ветка. Весь код версионируется. Это помогает понимать, что именно сейчас находится на сервере, а также легче управлять развёртыванием.

Пока деплой выполняем вручную. От полноценного CI/CD временно отказались, потому что для этого потребовались бы дополнительные серверные ресурсы. Пока проект не приносит прибыли, мы стараемся экономить практически на всём.

Что находится под капотом

Frontend построен на Next.js, React и TypeScript. Для организации кода выбрали Feature Sliced Design. В качестве стейт-менеджера используем TanStack Query, для форм - React Hook Form, для валидации - Zod, стили написаны на Sass.

Мы долго выбирали UI kit и в какой-то момент поняли, что уже само сравнение неидеальных библиотек начинает отнимать слишком много времени и из-за этого мы находимся в подвешенном состоянии. В итоге решили собрать собственный набор компонентов. С помощью нейронок, а также опираясь на архитектуру Chakra UI, удалось быстро сформировать основу собственной библиотеки компонентов без существенной просадки по срокам.

Backend написан на NestJS и Fastify. В качестве базы данных используем PostgreSQL, для части сценариев - Redis. Изначально backend имел обычную модульную архитектуру, но с ростом количества кода команда приняла решение перейти на FBCA (feature-based clean architecture).

В отдельном репозитории держим OpenAPI-схему. И frontend, и backend могут локально подтянуть из него актуальный контракт. Kubb генерирует из него типы и Zod-схемы, благодаря чему мы экономим значительное время на ручную правку всех этих данных.

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

Любопытно, но frontend задач у нас приблизительно в 2 раза больше, чем backend. На старте это отчасти совпало со структурой команды, но даже сейчас этот разрыв продолжает поддерживаться.

Как мы применяли нейросети

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

Мы использовали ИИ в нескольких направлениях.

1. Название платформы

Изначально проект должен был называться nado.ru, но подходящий домен оказался бы для нас неподъёмным в плане денег. Нейросеть провела глубокое исследование вариантов и предложила среди прочих название Вот бы!. Оно хорошо передавало саму механику площадки: "Вот бы кто-нибудь сделал…", а также было полностью свободным.

2. Разработка макетов

Первые UX интерфейсы я собирал вручную, и выглядели они достаточно плохо, UI макетов в самом начале впринципе не было.

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

3. Проектирование API

ИИ крайне хорошо показал себя в продумывании OpenAPI контракта. У него неплохо получается находить пропущенные сценарии и крайне точно править указанные данные.

4. Создание документации

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

5. Ревью кода

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

Моё субъективное мнение

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

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

Семь проблем, с которыми мы столкнулись

Если собрать главные ошибки и ограничения проекта, то получится следующий список.

1. Отсутствие отбора

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

2. Технический долг на старте

Недостаточный контроль первых реализаций привёл к переделке части backend. Здесь проблема в основном заключалась в том, что в этой части разработки я слаб и не мог в достаточной мере оценить происходящее в коде.

3. Сильный перекос команды в сторону frontend

Набирать людей только среди собственной аудитории удобно, но состав такой команды может быть не очень разнообразным. Нам пришлось отдельно в ускоренном темпе искать backend разработчиков.

4. Слишком много процессов было завязано на мне

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

5. Недостаток документации и размытая граница MVP

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

6. Отсутствие дизайнера и готовых макетов

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

7. Отсутствие устойчивого трафика

Эту проблему мы пока не решили. Во время активного продвижения площадка получает до 800 просмотров и около 150 уникальных пользователей в день. В такие дни появляются две-три идеи, около десяти лайков, пятнадцати голосов и трёх-четырёх комментариев. Но, когда публикации в социальных сетях прекращаются, вместе с ними снижается и активность на сайте.

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

Запуск: много поддержки и сломанная почта

1 сентября мы опубликовали проект. Я рассказал о нём в своём telegram канале, во frontend сообществах и других профессиональных чатах.

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

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

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

Релизы после MVP: продукт готов, сообщества ещё нет

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

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

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

Главный проблема сейчас - не ещё одна крутая фича, а активность сообщества.

Код можно разбить на задачи, распределить по участникам и быстренько реализовать, а вот с сообществом похоже, что это работает не так просто.

Сколько это стоит

Никто в команде не получает зарплату - пока проект держится чисто на энтузиазме.

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

Инфраструктура обходится примерно в 6000 рублей в месяц. Ещё около 2000 рублей я трачу на подписку на нейросеть. Платную рекламу пока не используем и продвигаемся полностью вручную.

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

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

Что дальше?

В будущем мы планируем добавить рекламные баннеры и платное продвижение идей. Но сейчас деньги не являются главным критерием успеха.

Если через полгода на площадке стабильно будут появляться хотя бы одна-две новые идеи в день без необходимости постоянно приводить людей вручную, я буду считать это главной победой. Это будет означать, что проект сдвинулся с мёртвой точки и начал жить своей жизнью.

Сейчас Вот бы! особенно нужны пользователи, авторы идей и люди, которые умеют развивать сообщества и продвигать продукты.

Лучший способ нам сейчас помочь - открыть наш сайт, найти идею, которая вам близка, и честно отметить, готовы ли вы ею пользоваться, платить, присоединиться к разработке или даже инвестировать. А если вам самим не хватает какого-то IT-продукта - описать его суть и опубликовать. Возможно, среди читателей найдётся и тот человек, который захочет её решить.

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

А если вы занимаетесь развитием IT-сообществ или продвижением продуктов и вам интересен наш эксперимент, буду рад познакомиться!