Меня зовут Никита, я бэкендер из Краснодара. Плотно сижу на NestJS/TypeScript в продуктовой команде. Параллельно с основной работой веду формат Proof of Work — 30-дневные публичные спринты по своим инди‑проектам: каждый день рассказываю, что сделал, и не бросаю свои идеи в заметки Obsidian/Notion на годы (по крайней мере, теперь).
За последние четыре месяца провёл четыре таких сезона: четыре продукта, четыре разных стека, четыре разных способа облажаться. Один продукт вообще не дожил до релиза. Три выпустил, ими пользуются люди, у одного есть публичный дашборд с метриками. Ни один пока не зарабатывает — и это часть истории, к которой я ещё вернусь.
По итогам четырёх сезонов я мог бы написать «10 советов как сделать стартап», но таких текстов и без меня хватает. Здесь — конкретный разбор того, что у меня сработало, что не сработало и какой ценой. С цифрами, с названиями инструментов, с граблями, на которые я наступил лично.
Если вы делаете свой инди‑продукт или думаете начать — возможно, часть моего опыта сэкономит вам пару недель и замотивирует наконец начать.
TL;DR. Без одного конкретного человека, который скажет «да, я этим воспользуюсь», лучше не начинать. Учить новый стек и параллельно гнать сроки — не получается, что‑то одно. Email‑верификация как блокер на регистрации убивает воронку. В РФ холодный аутрич без явного обмена «делаю → получаю» работает плохо. И выпуск продукта — начало работы, а не конец. Ниже подробно по каждому пункту, плюс отдельный раздел про юридическую часть и Telegram‑релей в обход блокировок российского хостинга (которые как раз недавно начались в 2026).
Четыре проекта за четыре месяца: краткий обзор
Чтобы дальше было понятно, о чём речь, коротко по проектам.
Сезон 1. Stars Marketplace. Telegram BOT который должен был покупать через Fragment звезды/премиум для Telegram на 30–40% дешевле чем у официальных магазинов. Сделал всё — бэкенд, бот, инфраструктуру. До запуска не дошёл: подряд три российских платёжных процессора (ЮKassa, Т‑Банк (тогда Tinkoff), Robokassa) отказались работать с такой моделью. Закрыл сезон с продуктом, который не может принимать деньги, и пошёл дальше.
Сезон 2. LifeTrack. Минималистичный трекер привычек. iOS на SwiftUI с нуля (ни строчки на Swift до этого не писал) и Android‑версия на React Native. Выпустил в App Store и Google Play, идёт органика, люди пользуются.
Сезон 3. TripTrack. «Strava для машин» — приложение для трекинга поездок. SwiftUI, MapKit, Core Location. Fog‑of‑war карта, геймификация, карточки поездок. Тоже в App Store, тоже работает. Так как в проекте пришлось придумывать небольшой велосипед с фильтром Калмана, писал об этом статью на Хабре.
Сезон 4. TeachTrack. Веб‑сервис для частных репетиторов: расписание, ученики, оплаты, Telegram‑бот с автоматическими напоминаниями. Полный стек: NestJS, React, PostgreSQL, Kubernetes на российском хостинге. Юридически по‑белому: оператор ПДн, сервер в РФ, уведомление в Роскомнадзор отправил 2 мая 2026 года. Этот сезон как раз заканчиваю — поэтому материала по нему больше всего. Технический разбор инфраструктуры с конфигами вышел отдельной статьёй на Хабре, здесь — про общие выводы.
Теперь — по разделам.
Откуда брать идеи для инди‑проекта
У меня было четыре источника, и они дали радикально разный результат.
Stars Marketplace родился из рыночной гипотезы и из задачи на основной работе: «Telegram Stars — новая платёжная штука, наверняка в этом есть бизнес». У меня не было конкретного человека, у которого болела эта проблема, я просто решал точно такую же задачу на основной работе и решил, что будет круто, сделать свой отдельный сервис, который как раз можно было бы интегрировать к себе потом в продукт, но в компании. Идея была в том, чтобы покупать звезды через Fragment, найдя способ через их незадокументированное API брать их автоматизированно. Так как точно такая же задача была дана мне по работе, я такой способ нашел.
LifeTrack пришёл из личной боли — нужен был трекер привычек, который не превращает в раба сложного интерфейса. Мне лично требовался бы трекер, который мог бы помогать мне не забывать следить за моими привычками необходимыми для поддержания здоровья. Я был получается одновременно пользователем и разработчиком.
TripTrack — тоже личная боль, но уже шире. Я часто за рулём, причем обожаю долгие поездки, мне нравится вспоминать о том, где я был и когда, а Strava‑подобной штуки для машин на рынке просто нет. Тут уже было ощущение, что это нужно не только мне.
TeachTrack. Два года назад моя девушка, преподаватель английского, пожаловалась, что ученики постоянно забывают о занятиях. Я за один вечер собрал Telegram‑бот, который рассылал её ученикам напоминания о расписании. Она пользуется им до сих пор. Через два года я решил сделать из этого нормальный сервис — и оказалось, что у меня уже есть валидированная идея, живой пользователь и работающий прототип.
Что из этого вышло: из четырех проектов, единственный, который умер до релиза и не смог все‑таки принести кому‑то пользу — это Stars Marketplace. У него на старте не было ни одного потенциального пользователя — даже меня самого. Совпадение или нет, судите сами.
Правило, которое я для себя сформулировал: если ни одного конкретного человека‑пользователя нет — стоит остановиться и подумать ещё раз. Идея может быть отличной, но без живого человека за ней вы работаете вслепую, глаз настолько замылится от ежедневного кодинга и проработки бизнес‑идеи, что вы не заметите, что делаете, если нет валидатора в виде реального юзера. Когда такой человек есть, даже посредственная идея даёт обратную связь, на которой продукт можно докручивать.
Валидация идеи до первой строки кода
С Stars Marketplace я ничего не проверял. Просто увидел тренд, сам загорелся, понял быстро, что это работает как бизнес‑модель, сел и начал писать архитектуру. Через месяц у меня был полноценный бэкенд, бот, инфраструктура — и три отказа от платёжных процессоров подряд. Никто из них не хотел работать с моей моделью оборота Stars. Я узнал об этом, потратив на разработку 30 дней. Если бы я за неделю до начала позвонил в три платёжных процессора и спросил, готовы ли они работать с такой схемой, сэкономил бы месяц.
С TeachTrack валидация произошла сама, без моего ведома. Тот самый бот за вечер два года назад был полноценным MVP. Он решал живую проблему конкретного человека. К моменту, когда я сел делать «настоящий продукт», я уже знал, что фича напоминаний работает и нужна.
Урок отсюда такой: до первой строки кода нужна хотя бы одна история человека, который сказал «да, я бы этим пользовался». Не в общем — «да, идея классная», а конкретно — «я завтра установлю на свой телефон и попробую».
Без этого можно построить технически идеальную штуку, в которой никто не нуждается. Я построил.
Как я реально собираю MVP за 30 дней: пошаговый конвейер
В книжках про MVP обычно пишут «неделя 1 — авторизация, неделя 2 — основная логика, неделя 3 — дизайн». Так у меня не получается. Большая часть работы происходит до первой строки продакшен‑кода — в документах и блок‑схемах. А благодаря AI‑агентам сама реализация занимает уже не недели, а дни.
Ниже — конвейер из девяти этапов, как я его собрал за четыре сезона подряд. На каждом этапе пример из TeachTrack, чтобы было предметно.
Этап 1. Идея и алгоритм в голове
Сначала есть бизнес‑задача в чистом виде. Например: «отправлять каждому ученику напоминание за 30 минут до начала урока».
Дальше в голове провожу мини‑исследование решений:
Удобно через Telegram‑бота.
Бот пишу на NestJS — мой рабочий стек.
Бот по
cronраз в минуту проверяет расписание и для уроков, до которых осталось 30 минут, шлёт сообщение в личку привязанному ученику.
Дальше упираюсь в мысль: «а как технически бот напишет ученику». Telegram не разрешает боту писать первым — ученик сам должен нажать /start. Самый простой вариант:
Каждый репетитор получает своего персонального бота.
Препод присылает ссылку на бота своим ученикам.
Ученик запускает
/start— препод видит у себя в диалоге со своим ботом, что подключился новый ученик с такими‑то данными.Дальше препод в админке создаёт записи учеников, привязывает к ним занятия, бот сам шлёт напоминания.
Минут за 20 в голове появляется простой работающий MVP‑алгоритм. Edge‑кейсы (несколько часовых поясов, отмены, повторяющиеся занятия) продумываются здесь же.
На этом этапе важно остановиться, когда алгоритм работает, а не когда он идеален. Идеальный алгоритм находится на этапе 7, не раньше.
Этап 2. Алгоритм на бумаге или в виде блок‑схемы
Цель — увидеть придуманное в голове снаружи. Беру Obsidian / любой блокнот / лист А4, рисую блок‑схему: сущности, события, ветвления.
Обычно после этого находятся изъяны: что‑то не сходится математически, есть пробел в логике, забыл какое‑то из состояний пользователя, в общем, проверяю на стандартную схему конечного автомата. Фикшу алгоритм, чтобы он работал без дыр, если требует. Таким образом и получается основная бизнес‑логика будущего приложения.
Если алгоритм совсем простой и в голове умещается без напряжения — можно пропустить рисование. Но если есть хоть какая‑то развилка — рисуйте. Я лично пропускал в первых сезонах, потом возвращался и переделывал.
Этап 3. Брейншторм с AI‑агентом
В Cursor создаю новую папку под проект и закидываю агенту промпт примерно такого содержания:
Делаем такой-то продукт для такой-то аудитории. Бизнес-задача: ... Алгоритм работы (см. блок-схему во вложении): ... Стек: ... Помоги: 1) пройтись по алгоритму и найти дыры, 2) задать неудобные вопросы по edge-кейсам, 3) предложить альтернативы там, где видишь смысл.
Если у вас в Claude Code подключён плагин Superpowers (или аналог) — агент сам подтягивает брейншторм‑флоу и начинает задавать неудобные вопросы. Это тот этап, на котором сам бы я не остановился.
Этап 4. Бизнес‑требования и техническое решение
Когда вместе с агентом дочистили концепцию, прошу его зафиксировать всё в два документа в docs/ репозитория:
docs/bizreq.md— бизнес‑требования или БТ: что делаем, для кого, зачем, какие сценарии пользователя, что считается успехом MVP.docs/tech.md— техническое решение или ТР: какой стек, какие сервисы и внешние API, методология по каждой ключевой фиче, и главное — контракты: бэкенд ↔ БД (схемы таблиц, индексы), бэкенд ↔ клиент (endpoint'ы, форматы запросов/ответов), бэкенд ↔ внешние сервисы (Telegram, платёжные процессоры и тому подобное).
Эти два документа — переломный момент конвейера. До них вся инфа была у меня в голове. После них её сможет прочитать любой следующий агент в новой сессии, не теряя контекста.
Уточню: что конечно, у вас в идеале еще должно быть ТЗ — техническое задание, но в процессе реализации своего же проекта из вашей же головы, тем более в такой ужатый срок, думаю это уже излишнее.
Если для кого‑то важно выполнить сторонний заказ, сделать для кого‑то приложение за те же 30 дней, то обязательно составьте техническое задание, так как в голове вы вряд ли удержите весь контекст той идеи, которой вы сами не загорелись изначально.
Очень советую посмотреть вот эти материалы от Диджитализируй. Фундаментальная база:
#1 Покажем, как создаются ИТ продукты с нуля. Идея, разработка ТЗ и прототипов интерфейса. Стартуем!
#2 Разработка схемы работы сервиса, прототипов интерфейса и дизайна
К концу данного этапа в репозитории лежат два (а может и три) структурированных документа, на которые опираются все следующие шаги.
Этап 5. UX/UI через генеративный дизайн
Для дизайна сейчас использую Figma Make (Claude Design тоже умеет, но пока справляется хуже). На входе:
два документа из этапа 4,
описание целевых сценариев пользователя.
На выходе — готовые JS‑файлы интерфейса (для веба) или продуманные сценарии экранов/кнопок (для бота). Забираю эти файлы в отдельную папку в проекте — например, frontend/generated/.
Для Telegram‑бота отдельного визуального дизайна нет, но есть UX‑сценарий: какие inline‑кнопки в каком состоянии показываются, что появляется, что исчезает, в каком порядке. Это тоже прогоняю через агента — на выходе получаю описание состояний и переходов, которое потом ляжет в код.
Этап 6. Реализация одним прогоном
Возвращаюсь к code‑агенту — это уже Claude Code с Opus и плагином Superpowers. На входе у него три источника правды:
1. docs/bizreq.md
2. docs/tech.md
3. Папка с дизайном
Промпт примерно такой: «Реализуй MVP согласно bizreq.md и tech.md, опираясь на дизайн из frontend/generated/. Работай в auto‑режиме, не жалей токенов, поднимай суб‑агентов под подзадачи, делай self‑review между шагами».
Не считаю нужным придумывать здесь супер пупер качественный промпт‑инжиниринг. Лучше потом после первого прогона, исправить какие‑то неточности уже указывая на ошибки.
Дальше Opus идёт прогон за прогоном: пишет → проверяет себя → находит косяк → чинит → переходит дальше. Я подключаюсь смотреть поднятый локально frontend + backend, делаю скриншоты и говорю «вот тут не так», и снова отхожу по своим делам.
На 6-м этапе появляется первый рабочий каркас приложения — обычно к 10–14 дню сезона. Это и есть момент, после которого основная разработка фактически закончена, и дальше идёт уже полировка и маркетинг.
Этап 7. Итерации тестирования
Тестирую сам, потом отдаю на тест первому живому человеку (если он есть). Найденные косяки записываю списком и отдаю агенту на доработку.
Цикл «тест → правка» повторяется 3–5 раз. К концу — рабочий MVP с покрытой основной функциональностью.
Здесь критично подключить живого человека, а не только себя. Один живой пользователь за 30 минут находит больше дыр, чем я за неделю — проверено на каждом из четырёх сезонов.
Этап 8. Финальный ревью кода
Перед тем как раскатывать в прод, прошу агента прогнать три встроенные команды (касается Claude Code, но для Cursor или любого другого агента можно свои кастомные команды создать):
review— общий ревью всего выполненного кода;security-review— отдельная проверка на типичные уязвимости: аутентификация, валидация входа, rate‑limit, обработка ПДн;simplify— упрощение по принципам SOLID / KISS / DRY, чтобы потом я, другие разработчики или следующие агенты могли читать код без боли.
Безопасность бэкенда я после этого всё равно прохожу руками. Любые куски, связанные с аутентификацией, rate‑limit, валидацией входа, обработкой ПДн — читаю сам, переписываю по ощущениям, гоняю свои тест‑кейсы. Здесь агенту не доверяю на автопилоте, так как сам бекендер, плюс мне это интересно.
Этап 9. Инфраструктура и деплой
Снова через AI‑агента: Dockerfile, манифесты Kubernetes (или systemd‑юнит на VPS, если масштаб поменьше), CI/CD‑пайплайн на GitHub Actions / GitLab CI, мониторинг через Prometheus + Grafana + Loki.
Раскатываю на сервер. К этому моменту у меня работающий сервис в проде, доступный по домену. К примеру:
TeachTrack — лендинг + в целом, всё приложение;
TripTrack — здесь я уже отдельный лендинг делал для SEO продвижения. Основное приложение все‑таки было выполнено на SwiftUI.
Если разложить по 4-недельной канве
Неделя | Что происходит |
1 | Этапы 1–3: бизнес‑идея, алгоритм на бумаге, брейншторм с агентом, проверка концепции вайб‑кодом на быструю руку. |
2 | Этапы 4–6 (начало): финальные |
3 | Этапы 6 (продолжение) — 7: основная реализация и несколько раундов «тест → правка» до рабочего MVP. |
4 | Этапы 8–9 + маркетинг: ревью кода, деплой, доработка по фидбэку первых живых пользователей, лендинг, SEO, выкладка в App Store / Google Play или приём пользователей через веб. |
Когда я после первого прогона с ai‑агентом дал TeachTrack своей девушке‑преподавательнице на тест — она за 30 минут нашла десяток проблем: от багов с часовыми поясами (бот прислал напоминание на 3 часа раньше, потому что я не определял пояс пользователя) до плавающей ошибки кнопки «Попробовать бесплатно», которая срабатывала через раз. Это та самая четвёртая неделя в действии: живой человек за час даёт больше, чем я сам за неделю.
Главное правило поверх конвейера
Если какая‑то фича делается на будущее или на всякий случай, ну вот горит и не выполняет изначальное, главное обещание продукта — её нет в MVP. Она в бэклоге, в плане на потом, в v1.1. Но не в первой версии, которую вы покажете.
В сумме получается, что соло‑разработчик с грамотным AI‑сетапом за месяц без вложений и без команды собирает MVP, который раньше требовал двух‑трёх человек на пару месяцев. У меня это работает уже четыре сезона подряд — и каждый следующий конвейер быстрее, потому что обкатываются документы‑шаблоны, промпты и команды агентов.
Надеюсь у вас будет также и даже лучше!
Стек и инструменты для быстрого запуска
Для LifeTrack и TripTrack я изучал SwiftUI с нуля. Это был осознанный выбор — я хотел в iOS, в свою первую любовь как пользователя, и был готов платить временем на обучение + непонимание как работать с агентами с мобилками.
С TeachTrack я вернулся в свой стек: NestJS, React, PostgreSQL, всё то, в чём я работаю плотно. И разница в скорости была кратной. Здесь уже основная реализация завершилась буквально за первую же неделю. Полторы последних недели сезона я просто занимался маркетингом и даже поболеть успел.
В iOS‑сезонах большая часть времени уходила не на построение продукта, а на разбирательство с фреймворком. Почему этот modifier ломает layout. Почему MapKit не даёт держать tracking mode и одновременно крутить зум камеры. Почему Combine ведёт себя не так, как я ожидал. Да и просто — как вообще правильно отправлять на ревью свое приложение?
В TeachTrack я не думал о фреймворке вообще. Архитектура модулей в NestJS у меня в пальцах. PostgreSQL‑запросы — это просто инструмент. React + TypeScript + Tailwind — каждый день в работе.
Простой вывод: учёба и скорость не совмещаются. Если хотите учиться — закладывайте двойное время и не ставьте себе амбициозных задач по продукту. Если хотите скорость — идите в свой стек.
Я не жалею, что учил SwiftUI два сезона подряд: это долгая инвестиция, и она окупится. Но если бы начинал заново, не пытался бы одновременно учить Swift и держать цель «выпустить в стор за 30 дней». Что‑то одно.
Как я пишу код: Cursor и Claude Code
AI‑инструменты в коде меняются быстро, статьи про них устаревают за месяц. Поэтому коротко — что у меня сейчас и почему.
Сетап: Cursor ($20/мес подписка) для мелких правок и работы с несколькими репо одновременно, Claude Code (у меня по API, выходит $100–200/мес — у Anthropic есть и подписочные тарифы Max) для больших задач, где нужно много контекста и долгий agent‑цикл. Для Claude Code включён плагин Superpowers — набор готовых сценариев под брейнсторм, отладку, тесты.
Когда задача большая и многошаговая — открываю Claude Code, описываю детально, что хочу, гоняю модель в plan mode или даже auto mode (это когда она сначала строит план, потом пишет код). Когда задача мелкая — правлю в Cursor. Это разделение даёт мне предсказуемость по затратам и не мешает фокусу. При этом, пользуюсь Cursor еще затем, что там куда удобнее можно создавать кастомные команды или скиллы под себя. С Claude как по мне делать это не так гибко, он крут уже готовыми решениями от сообщества, чтобы не создавать велосипед.
Один момент я держу всегда перед собой зачем‑то, просто уже на автомате, иногда не знаю оправдано ли: безопасность бэкенда. Любые куски, связанные с аутентификацией, rate‑limit, валидацией входа, обработкой ПДн — читаю руками, переписываю по ощущениям, гоняю свои тест‑кейсы. Здесь я сам себе ревьюер, агенту не делегирую чаще всего.
Если интересна более развёрнутая раскладка по AI‑сетапу — есть отдельный пост в канале. Сюда не пихаю, чтобы не превращать материал в обзор инструментов.
Юридическая часть, про которую все молчат
Дальше — факты моего опыта, без рекомендаций.
iOS‑релизы из России
Я выпускал LifeTrack и TripTrack в App Store с российским аккаунтом разработчика. Аккаунт работает, ревью проходит, приложения публикуются. Но есть один критичный момент: российский аккаунт Apple Developer не может принимать платежи через In‑App Purchase. То есть платная версия, подписки, разовые покупки внутри приложения — недоступны.
Я это сразу принял и оба iOS‑приложения сделал бесплатными. Если в какой‑то момент захочу включить монетизацию — потребуется иностранное юрлицо. Грузия и UAE Freezone — варианты, которые я изучал, но пока не пробовал. Это отдельная история — регистрация компании, банковский счёт, налоговая отчётность в чужой юрисдикции. Вход с порогом, причем денежным, я пока к этому просто не готов, ни морально, ни по кошельку.
Если вы думаете начинать iOS‑проект из России — учитывайте это с самого начала. Если в планах монетизация через IAP — либо закладывайте бюджет и время на иностранное юрлицо, либо принимайте, что монетизация будет внешней (например, через сайт с подпиской и доступом по логину в приложении).
Веб‑сервис с пользователями из РФ
С TeachTrack я пошёл «по‑белому» в российской юрисдикции. Логика простая: продукт для российских преподавателей, инфраструктура в РФ, ПДн обрабатываются на территории РФ согласно ч. 5 ст. 18 152-ФЗ.
Что для этого сделал:
Хостинг — Timeweb, всё в РФ‑локации. БД с персональными данными физически в дата‑центре в РФ, первичная запись/обновление ПДн происходят там же.
Уведомление оператора ПДн в Роскомнадзор — отправил 2 мая 2026 года. Процедура несложная, делается через Госуслуги для ИП. Главное — корректно описать, какие данные собираете и зачем. Те же самые AI‑агенты вам в помощь.
Политика конфиденциальности и пользовательское соглашение — оформил с учётом 152-ФЗ. Шаблоны есть в открытом доступе, под свой случай подгонял сам.
Один технический сюрприз, на котором я потерял день: на Timeweb режутся исходящие запросы к api.telegram.org. Webhook от Telegram приходит нормально, а ответ обратно — ETIMEDOUT. У других хостеров поведение может отличаться (у людей на Selectel/Yandex Cloud это работает), но конкретно у меня выглядело так:
webhook (incoming, ok) ────────────────────────────→ TeachTrack backend api.telegram.org (NestJS, Timeweb RU) │ │ outbound HTTP ▼ ✕ ETIMEDOUT (режется хостингом)
Стандартные обходы (polling, разные webhook‑стратегии) не помогают. Local Bot API Server теоретически может работать — если поднять его на той же зарубежной VPS. Тогда из РФ идём к нему, а он уже общается с MTProto. Это рабочий вариант, особенно для больших файлов и долгоживущих соединений. Я выбрал свой минимальный релей — мне нужны были метрики, аутентификация и потенциальная логика per‑bot, без накладных расходов на полный Local Bot API.
Архитектура после фикса:
webhook (incoming) ──────────────────→ TeachTrack backend api.telegram.org (NestJS, Timeweb RU) │ │ outbound HTTP + auth header ▼ tg-relay (DigitalOcean, Frankfurt) stateless proxy │ ▼ api.telegram.org
Релей — короткий Fastify‑сервис. Минимальный рабочий вариант, который покрывает текстовые методы Bot API (sendMessage, editMessageText и тому подобное):
// tg-relay/src/index.ts import Fastify from 'fastify'; const app = Fastify({ // важно: не пишем url в access-log, иначе токен бота уедет в логи logger: { level: 'info', serializers: { req: (r) => ({ method: r.method, host: r.hostname }) }, }, }); const TG_API = 'https://api.telegram.org'; const RELAY_SECRET = process.env.RELAY_SECRET!; const TIMEOUT_MS = 10_000; // catch-all: /bot<token>/<method> app.post('/*', async (req, reply) => { // shared-secret заголовок: иначе релей превращается в open proxy к чужим ботам if (req.headers['x-relay-auth'] !== RELAY_SECRET) { return reply.code(401).send({ ok: false, error: 'unauthorized' }); } const ctrl = new AbortController(); const timer = setTimeout(() => ctrl.abort(), TIMEOUT_MS); try { const upstream = await fetch(${TG_API}${req.url}, { method: 'POST', headers: { 'content-type': 'application/json' }, body: JSON.stringify(req.body ?? {}), signal: ctrl.signal, }); // проксируем как есть — в т.ч. 4xx/5xx от Telegram const buf = Buffer.from(await upstream.arrayBuffer()); return reply .code(upstream.status) .header('content-type', upstream.headers.get('content-type') ?? 'application/json') .send(buf); } catch (err: any) { req.log.error({ err: err.message }, 'relay upstream error'); return reply.code(502).send({ ok: false, error: 'upstream_failed' }); } finally { clearTimeout(timer); } }); (async () => { try { await app.listen({ port: 3000, host: '0.0.0.0' }); } catch (err) { app.log.error(err); process.exit(1); } })();
На стороне бэкенда меняется одна переменная — базовый URL — и добавляется заголовок:
// На бэкенде в РФ const TG_BASE = process.env.TG_RELAY_URL ?? 'https://api.telegram.org'; await fetch(${TG_BASE}/bot${token}/sendMessage, { method: 'POST', headers: { 'content-type': 'application/json', 'x-relay-auth': process.env.RELAY_SECRET!, // только если идём через релей }, body: JSON.stringify({ chat_id, text }), });
Что важно по данным. Через релей проходит только то, что я ему отдаю: chat_id и текст уведомления. Шаблон уведомления у меня нейтральный («Напоминаем: занятие через 30 минут»), без ФИО ученика, без предмета, без других ПДн — этого достаточно, чтобы напоминание сработало. Сами ПДн остаются в PostgreSQL на Timeweb. Я для себя считаю, что в этом контуре трансграничной передачи ПДн нет, но это моя личная трактовка, у юриста не валидировал — если делаете подобное под продакшен с большим потоком пользователей, лучше посоветуйтесь.
Чего в этом сниппете нет (и чего хватит для production‑проекта, но не хватит для статьи): retry на 429 с учётом retry_after, rate‑limit per chat_id, поддержка multipart/form-data для отправки файлов (sendPhoto/sendDocument через стрим, не через JSON), мониторинг в общем Prometheus, systemd‑юнит, Caddy с TLS перед Fastify. Полный продакшен‑разбор лежит в моей предыдущей статье — там код‑под‑нагрузку.
Если для вашего кейса достаточно proxy_pass без логики — задачу решает Caddy в три строки конфига, без своего кода. Я выбрал Node‑сервис именно потому, что хотел потом дописать туда auth‑проверку токена бота, метрики, rate‑limit per chat — для Caddy это уже было бы лишним.
Публичные метрики проекта: Prometheus, Grafana, Loki
Один из побочных эффектов формата Proof of Work — я стараюсь делать процесс прозрачным. Это касается не только постов в канале, но и метрик.
Для TeachTrack я поднял Prometheus + Grafana + Loki + Promtail на той же инфраструктуре, что и сам сервис. Логи, метрики приложения, метрики хостов — всё в одном месте. И отдельный публичный дашборд, доступный всем: stats.teachtrack.ru. Там видны живые цифры — сколько преподавателей зарегистрировано, сколько учеников создано, сколько занятий проведено, сколько напоминаний бот разослал.
Я не планировал это как «фичу для аудитории». Это рабочий инструмент мониторинга, который я делал в первую очередь для себя — без метрик невозможно понимать, что происходит в продукте. Но публичная часть оказалась побочным бонусом: подписчики канала видят рост или его отсутствие в реальном времени. Это работает на доверие сильнее, чем любые слова.
Первые пользователи: что не работает
Этот раздел — самый болезненный для меня лично. Потому что построить продукт за 30 дней — это понятная инженерная задача. Привести в него людей — задача совершенно другого порядка.
Холодные сообщения в Telegram
В сезоне TeachTrack я попробовал самый прямой подход — нашёл тематический канал в Telegram для репетиторов, выписал из него тех, кто пишет про преподавание, и отправил каждому персональное сообщение с предложением попробовать сервис бесплатно.
Цифры за один день:
30 сообщений отправлено
3 ответа «спасибо, не нужно»
2 ответа «интересно, а что от меня нужно?»
1 ответ с предложением партнёрства
24 молчания
И ровно один человек дошёл до регистрации, подтверждения почты и захода в кабинет. Один из 30. Этот один не создал ни одного ученика, ни одного занятия. Конверсия в «активного пользователя» — нулевая. (Сразу оговорка: выборка крошечная, n=30 — это не статистика, а наблюдение, на основе которого я решил поменять подход)
Потом я рассказал об этом своей девушке‑преподавательнице и как она предположила — основная проблема была не в продукте, а в формулировке. Я писал в духе «делаю проект, попробуй бесплатно, не зайдёт — не страшно». В моей голове это звучало как искреннее «без подвоха». Но со стороны читалось как «незнакомый парень в Telegram что‑то бесплатно предлагает».
«Бесплатно от незнакомого» по умолчанию читается как подвох — на холодную в любом мессенджере, не только в РФ. Либо MLM, либо сбор данных, либо новая схема развода. Презумпция подозрения. А подвоха‑то и нет: сервис правда бесплатный, данных я не собираю сверх необходимых. Но логика рассуждения адресата работает не от фактов, а от шаблонов.
Я переписал шаблон сообщения. Добавил явный обмен: попробуйте сервис, взамен прошу один отзыв, размещу на главной странице сайта. Всё. После этого ответы пошли — потому что обмен теперь явный, а не «бесплатный сыр».
Парадокс, который меня правда удивил: бесплатно — даром не надо. А если за что‑то конкретное — пожалуйста. Дело не в деньгах, а в том, что человек должен понимать, что он даёт и что получает. Когда непонятно — мозг лепит ярлык «развод» по умолчанию.
Если делаете холодный аутрич — даже когда вам реально ничего не нужно от собеседника, придумайте явный обмен. Иначе будете получать либо молчание, либо вопрос «в чём подвох».
Второй риск: рассылка 30+ сообщений в день с одного аккаунта почти гарантированно ведёт к временной блокировке в Telegram. Обходил через второй аккаунт, но в долгую так не масштабируется. Холодный аутрич через личку Telegram с одного аккаунта — не масштабируемый канал привлечения. Если делать это серьёзно, нужны прогретые аккаунты, ротации, шаблоны разной длины — а это уже отдельная инженерия, которую соло‑разработчику тащить не хочется. По крайней мере пока, в данный момент.
Кажется есть эффективнее способы настроить маркетинг. Попробую как раз в августе 2026 года, уже совсем скоро.
Email‑верификация как тормоз конверсии
Здесь я понял, как чек‑лист security best practices может убить конверсию.
Я сделал в TeachTrack стандартную регистрацию — email + пароль + подтверждение почты. Без подтверждения email пользователь не мог создавать учеников и занятия. Логично, безопасно, как у всех.
Через две недели после открытия беты залез в админку. К тому моменту в системе скопилось 17 регистраций — пришли с разных каналов: канала OneZee, ссылки в 21 день челленджа из 30, на Хабре, сарафана. И из этих 17 — 11 застряли на этапе «email не подтверждён, 0 учеников, 0 занятий». Почти 65%. Не все потеряны именно на этом шаге, но точно ощутимая часть.
Полез в логи — письма уходили нормально. Запрос на повторную отправку приходил. То есть человек открывал почту, видел письмо, переходил по ссылке — и не нажимал кнопку подтверждения на открывшейся странице. Видимо, ожидал, что переход по ссылке = и есть подтверждение, как у многих сервисов.
Параллельно одна преподавательница написала: «зарегалась, не могу подтвердить, даже повторная ссылка не работает». А по логам у неё всё ок — письмо ушло, ссылка валидная, на страницу она перешла. Просто не нажала кнопку.
Решение: убрал email‑верификацию как блокер. Регистрация теперь даёт полный доступ к функционалу сразу. Email‑верификация осталась необязательной — для будущего восстановления пароля. Так, кстати, живут Notion и Vercel — посмотрите, у них первый вход без лишних шагов.
Бонусом починил silent‑баг: раньше повторная отправка письма возвращала «ок», даже если SMTP реально лежал. Пользователь думал «отправили, жду», а ждать было нечего.
Email‑верификация как блокер на регистрации в моём случае была security theater. Бомбинг регистраций я останавливал rate‑limit‑ами на эндпоинте регистрации, защиту от typo в почте можно сделать после первого захода, имперсонация в B2C‑сервисе для одного учителя — несущественный риск. А вот воронку этот блокер реально убивал. «Правильное» решение из чек‑листа оказалось ловушкой для продукта.
Первые пользователи: что (вероятно) работает
«Вероятно» — потому что я в начале этого пути и не могу с уверенностью сказать «вот этот канал работает». Могу только описать то, что попробовал, и что показало признаки жизни.
Технические статьи для SEO. В разгар сезона я написал статью на Хабр про инфраструктуру TeachTrack — релей‑микросервис, Kubernetes‑сетап, дебаг блокировки api.telegram.org. Статья начала индексироваться, на сайт пошёл трафик из поисковиков. Это не быстрый канал — эффект разворачивается за недели, — но это «вечный» актив, который работает в фоне без моего участия.
Один живой пользователь даёт больше, чем custdev в вакууме. Та самая девушка, для которой я когда‑то делал бота, дала мне больше фидбэка за час разговора, чем все мои самостоятельные размышления о продукте за неделю. Качество другое: человек реально пользуется, а не отвечает на гипотетические вопросы.
Опрос аудитории канала про продукты. Подписчики OneZee telegram канала — люди, которые уже интересуются продуктом. Это не случайная выборка с улицы, но качественный сигнал они дают. Опросы среди них помогают понять, какой из моих продуктов больше резонирует, на что обратить внимание.
Каналы, которые я ещё не пробовал, но хочу. Реклама в тематических Telegram‑каналах (если найду каналы для преподавателей с адекватной ценой размещения). Видео‑контент на YouTube и Reels (у меня уже есть план и сценарии). Партнёрства с сервисами для онлайн‑обучения. Это всё гипотезы — буду проверять в следующих сезонах.
Ловушка нового сезона: почему запуск — не финиш
К концу четвёртого сезона у меня в кармане три рабочих продукта: LifeTrack, TripTrack, TeachTrack. Каждый работает, у каждого есть пользователи (от единиц до десятков), у каждого видно, куда расти дальше.
И ровно в этот момент включается голос: «Окей, TeachTrack выпущен. Через пару недель стартую пятый сезон с новым продуктом. У меня уже есть идея — idle‑игра, которую хочу сделать уже пять лет. Поехали».
Вот эта ловушка и собирает коллекцию заброшенных проектов. У меня таких в архиве уже хватает: недозапущенные эксперименты, наполовину готовые MVP, идеи в виде Figma‑макетов. Каждый в момент создания казался важным. Сейчас — мёртвый код в репозитории.
Решение для себя: следующие сезоны Proof of Work будут не про новые продукты, а про маркетинг существующих. Каждый сезон — 30 дней фокуса на одном продукте. Конкретный план: июнь — TripTrack (лето = сезон поездок, выход на англоязычную аудиторию), июль — LifeTrack (редизайн, потом маркетинг), август — TeachTrack (учебный год начинается в сентябре, август — окно «готовлюсь к новому году»).
Цель каждого сезона — не «1000 скачиваний» (это бесполезная по сути метрика для настоящего продукта), а 10 живых пользователей в день, которые открывают приложение и пишут фидбек.
Звучит мало. Но 10 живых пользователей дают больше понимания продукта, чем 10 000 закачек‑однодневок. И только когда у продукта есть стабильное ядро, для меня имеет смысл думать о монетизации. Раньше — гарантированный провал, проверял.
Выпустить продукт — начало работы, а не конец. Я к этому пришёл к четвёртому сезону. Возможно, у вас уйдёт меньше попыток.
Психология сезонов: одно наблюдение, которое не описывают в гайдах
Одно наблюдение про психику, которое повторилось во всех четырёх сезонах и сильно повлияло на план дальше.
После каждого из четырёх сезонов было одно и то же: закрыл проект, выдохнул — и накрыло. Усталость, апатия, ощущение «не знаю, что дальше». Первый раз я думал, что со мной что‑то не так. Сейчас понимаю: это нормальная реакция организма на 30 дней спринта без выходных. Тело так говорит «не запускай следующий марафон в понедельник».
Поэтому в плане на следующие сезоны у меня есть пункт «обязательная неделя паузы между сезонами». Не считаю её потерянной: за эту неделю успеваешь посмотреть на сделанное со стороны, поправить очевидные косяки в продакшене и придумать, что вообще делать в следующем спринте. Раньше я этой паузы не давал — отсюда и кумулятивная усталость к четвёртому сезону.
Зачем вообще устраивать такие марафоны?
В смысле зачем? А ради чего еще каждый день просыпаться? У нас у каждого отведено достаточно мало времени на здоровые моменты, когда мы можем видеть, сидеть на кресле и нажимать на кнопки клавиатуры. Надо пользоваться моментом и пытаться как можно скорее, качественнее при этом создать полезные вещи для себя и общества.
Немного лирики...
Что я бы сделал иначе, начиная сейчас
Если бы я сегодня начинал пятый сезон с нуля, зная всё, что узнал за четыре, вот что было бы по‑другому.
Про продукт:
Не начинать ничего без одного конкретного человека‑пользователя. Stars Marketplace — пример того, как красивая рыночная гипотеза без живого пользователя превращается в технически рабочий продукт, который не может принимать деньги.
Не учить новый стек одновременно с агрессивными сроками. Что‑то одно. Либо учусь и не давлю на скорость, либо иду в свой стек и фигачу.
Никаких подтверждений email на старте. Пользователь попадает в продукт за минуту, верификация добавляется потом, когда понятно, что она действительно нужна.
Делать инфраструктуру наблюдаемости с первого дня. Открытый дашборд с метриками — это не маркетинг, это рабочий инструмент, который сильно ускоряет понимание собственного продукта.
Про маркетинг и процесс:
Готовить холодный аутрич с явным обменом. Бесплатно в РФ читается как подвох — собеседник должен понимать, что он даёт и что получает.
Не закрывать сезон с мыслью «дальше — новый продукт». После релиза работа только начинается, и продукт без хотя бы 10 живых пользователей — скорее файл в архиве, чем запуск.
Заранее закладывать паузы между сезонами. Послесезонный тильт — не баг моей психики, это нормальная реакция. К ней лучше готовиться.
Не относиться к каждому проекту как к финальной ставке. Stars Marketplace умер — и это нормально. Я узнал из него больше, чем из любой статьи про платёжные системы. Готовность к провалу — нормальное рабочее состояние, не цинизм.
Главный вопрос, на который у меня нет ответа
Если читать всё, что выше, может показаться, что я разобрался. Это не так.
После четырёх сезонов у меня есть три выпущенных продукта и довольно чёткое понимание, как их строить за 30 дней. Чего у меня нет — рабочей системы привлечения первых пользователей в инди‑продукт без бюджета. Холодные DM не масштабируются и ведут к бану аккаунтов на разных соц. площадках. SEO разворачивается за месяцы, а не недели. Реклама в тематических каналах стоит денег, которых у бесплатного продукта по определению нет. Сарафан требует уже существующих пользователей — то есть как раз того, чего у вас нет на старте.
То, что обычно советуют («идите в комьюнити», «делайте контент», «найдите евангелистов»), для русскоязычного B2C/B2B без бюджета работает медленно. Я не нашёл здесь ни одного канала, про который мог бы честно сказать «вот, делайте так — и будут пользователи».
Что буду пробовать в следующих сезонах:
Видео‑контент с механикой пользы. Не «я выпустил продукт, заходите», а короткие практические ролики для конкретной аудитории (например, для репетиторов — «как выставить расписание с нерегулярными уроками в TeachTrack за 3 минуты»). Гипотеза: ролики ранжируются в YouTube/Reels по сути запроса, а не по тому, насколько ты популярен.
Партнёрства с микро‑сообществами. Не покупка рекламы, а обмен: я делаю им бесплатно полезный отчёт/интеграцию/мини‑фичу, они один раз рассказывают про продукт своей аудитории. Гипотеза: 5 точечных партнёрств с малыми, но релевантными аудиториями дают больше, чем одна реклама в большом канале не по теме.
Обе гипотезы спорные, обе могут не сработать. Если у вас есть кейсы — что у вас реально сработало для первых пользователей в РФ без бюджета — расскажите в комментариях. Это мне сейчас интереснее любого технического совета.
Если делаете свой инди‑продукт, надеюсь, что‑то из этого вам пригодится. Хотите следить за процессом дальше — веду канал OneZee, каждый день пишу, что делал по текущему сезону. Сейчас закрыл четвёртый, дальше — серия маркетинговых сезонов: довожу то, что уже сделал, до живых пользователей.
Кстати эту статью с гайдом того, как делать все‑таки свои проекты я также создал так, как пообещал в рамках поста в Telegram канале.
Ссылки на проекты:
TeachTrack — teachtrack.ru, открытый дашборд метрик stats.teachtrack.ru, технический разбор инфраструктуры
TripTrack — лендинг trip‑track.app, tg‑канал @triptrack_app, приложение в App Store
LifeTrack — в App Store и Google Play
Пишите в комментариях, если хочется обсудить какой‑то из разделов глубже — у меня по каждому ещё много деталей, которые в одну статью не влезают. Не хочу увеличивать контекст здесь, поэтому стараюсь максимально кратко и по делу.
