Собрал SaaS в одиночку за месяц на подписке за $20. За пять месяцев заработал 200 ₽

Сильная модель принимала решения и писала ТЗ, доступные писали код. За пять месяцев так собрались семь модулей, 110 аккаунтов и одна оплата от внешнего пользователя. Разбираю по цифрам, где схема сработала и где я провалил всё, кроме разработки.

Пятого апреля 2026 года я начал эксперимент с одним ограничением. Можно ли собрать работающий MVP SaaS за месяц, если работать по три-четыре часа четыре вечера в неделю и не покупать ничего, кроме подписки Cursor за $20 в месяц. Через месяц MVP был.

Сейчас, спустя пять месяцев, в проде семь модулей, 110 активных аккаунтов владельцев и одна оплата от внешнего пользователя на 200 ₽. Разработка получилась, все остальное пока нет, и именно про это интереснее всего рассказывать.

Оговорюсь сразу. RetroPoint делаю я, так что читайте это как рассказ заинтересованного лица. Разработчик в проекте один, но не с чистого листа.

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

Все числа ниже это обезличенный read-only срез рабочей базы на 10 сентября 2026 года. Никаких оценок «примерно» и «около» в них нет.

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

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

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

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

$20 в месяц это стоимость подписки Cursor, внутри которой шли и обращения к Claude Opus. Это было условие эксперимента, а не бюджет продукта.

В эти $20 не входило:

Здесь стоит быть точным, потому что разница принципиальная. Код приема платежей я написал внутри того же первого месяца и внутри той же подписки: биллинг появился в репозитории 12 апреля, аддоны к нему 22 апреля, вместе с фискальными чеками по 54-ФЗ. Подписка закрыла именно разработку.

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

Поэтому формулировка «продукт за $20» была бы враньем. Правда в другом: за $20 в месяц я закрыл ту часть работы, которая раньше требовала команды разработки. Все, что вокруг разработки, никуда не исчезло.

Это главное, что я вынес из пяти месяцев, и оно переносится на любой продукт.

Скорость дала не одна сильная модель, а разделение труда между двумя уровнями. Claude Opus внутри Cursor снимал неопределенность: выбирал продуктовое и архитектурное решение, а потом превращал его в подробное ТЗ с критериями готовности. Реализацию по готовому контракту забирали более доступные модели.

Экономия появилась даже не на цене запроса. Дорогая модель принимала решение один раз, и дальше его не приходилось изобретать заново в каждом исполнительском чате.

По ходу работы я изобрел свой велосипед, локальную версию Spec-Driven Development. Вместо готового фреймворка постепенно собрал процесс вокруг проектных спецификаций, которые живут рядом с кодом. Каждая фаза начинается с плана, который появляется до кода. Отдавать его исполнителю можно, когда в нем приняты все ключевые решения и тому не нужно угадывать:

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

Ровно так же вышло с дизайном. Дизайнер отдал несколько публичных экранов, раздел ретро и карту цветов с типографикой, а остальные модули я проектировал в Claude Design поверх той же системы. Помог не запрос «нарисуй красиво». Помогло то, что у агента была формализованная визуальная грамматика: семантические роли цвета, шкала типографики, сетка отступов, радиусы и размеры контролов. Макет показывает одно правильное решение, а токены объясняют агенту, почему это решение принадлежит именно этому продукту. Иерархию, плотность, состояния и права по-прежнему принимал я.

Третье, без чего все рассыпалось бы: повторяемое требование должно уходить из чата в репозиторий. Правила проекта, редакционный стиль и архитектурные ограничения лежат рядом с кодом и версионируются, а не пересказываются заново в каждой новой сессии. Критичные публичные обещания проверяются тестами. Один сверяет цифры на странице тарифов с лимитами в бэкенде, другой держит в актуальном состоянии карту сайта для AI-агентов. Агент может уверенно написать «до 10 активных досок», и остановит его только красный тест.

Семь самостоятельных модулей: ретроспективы, Planning Poker, OKR, встречи один на один, Performance Review, рабочие встречи и командный календарь отсутствий. Подключаются по одному, независимо друг от друга.

Стек намеренно скучный: Python и FastAPI, PostgreSQL, React с TypeScript, Docker Compose и GitLab CI на обычном VDS. Данные хранятся в России, оплата идет в рублях, а 27 июля продукт включили в реестр операторов персональных данных. Для части российских команд это входное требование к новому сервису.

Я собрал четыре тарифа и шестнадцать дополнительных пакетов с отдельной таблицей возможностей для каждого. Вышла страница высотой около 28 500 пикселей с восемью таблицами. Мне казалось, что так честнее: человек видит все и выбирает точно. На деле выбор такой сложности человек не делает, он закрывает вкладку.

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

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

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

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

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

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

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

Причина внешняя. Часть 10 статьи 8 закона № 149-ФЗ ограничивает способы авторизации пользователей в России для российских владельцев сайтов и приложений, а с 7 июля 2026 года закон № 199-ФЗ ввел за нарушение административную ответственность.

Яндекс ID уже был подключен и закрывал часть потребности. Неожиданным оказалось другое: 12 из 38 регистраций через него пришли с корпоративных доменов, всего с семи разных. Корпоративные сервисы Яндекса привели аудиторию, которую я не ожидал увидеть в этом канале.

После отключения Google я стал искать российский способ входа, который с высокой вероятностью уже есть у целевой аудитории, и выбрал Сбер ID. Он появился в продукте шестого августа и дал восемь регистраций. Для сравнения: у Яндекса за пять месяцев 38, у отключенного Google 25, у VK ни одной.

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

Срез рабочей базы на 10 сентября выглядит так:

Про повторение стоит отдельно сказать, как я его считаю, потому что сначала считал неправильно. Я взял за признак вторую содержательную доску и получил трех человек из 43. Цифра оказалась неверной: многие проводят несколько ретроспектив на одной доске и просто правят ее заново, второй доски у них не появляется. Поэтому теперь повторением я считаю либо вторую доску, либо возврат на ту же доску в другой день. Так получается 11 человек из 43, и это в четыре раза больше первой оценки.

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

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

Первое: перестаю добавлять модули. Восьмой модуль не сделает второй ретроспективы у тех 43 человек, которые провели первую.

Второе: ставлю аналитику воронки и разметку переходов. Сейчас я не могу сказать, откуда пришли 110 аккаунтов, потому что поля источника регистрации в базе просто нет.

Третье: беру одну метрику вместо всех и смотрю на нее. Доля владельцев с признаком повторения. Сегодня это 11 из 43.

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

Продукт, о котором идет речь, это retropoint.ru.

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