Операционная система для соло-разработчика. Без команды, без инвестора, без хаоса

Меня зовут Батраз, я основатель GoToBook

Есть такой момент в жизни каждого соло-основателя, когда понимаешь: продукт вырос настолько, что ты сам в нём уже не ориентируешься. Открываешь файл — не помнишь зачем. Меняешь одно — ломается другое. Нанимать некого и не на что. А пользователи уже есть, и они ждут.

Я через это прошёл. И придумал выход, о котором почти никто не говорит.

Я запустил GoToBook — сервис онлайн-записи для специалистов-одиночек. Бровист, массажист, nail-мастер, тренер, таролог — любой, кто принимает клиентов и устал координировать это через WhatsApp.

Механика простая: специалист регистрируется, настраивает расписание и услуги, получает ссылку вида gotobook.ru/username. Ставит её в bio в соцсетях — и клиенты записываются сами, без регистрации, без приложения, без лишних шагов.

Продукт работает на проде. Пользователи есть. Записи идут.

И всё это — один человек.

Не потому что я какой-то особенный разработчик. А потому что я по-другому использую AI.

Большинство людей используют Claude или GPT как умный поиск: спросил — получил ответ — скопировал. Это даёт скорость на старте и хаос через месяц.

Я сделал иначе. Я построил систему, в которой AI — это не инструмент, а член команды. Со своим онбордингом, памятью и правилами работы.

Сейчас есть целый тренд: люди подключают Claude к Obsidian, скидывают туда заметки и книги, и просят AI синтезировать знания. CLAUDE.md в этом контексте — это "вот мои мысли, помоги разобраться".

Это полезно. Но это не то, что я сделал.

Пока все используют CLAUDE.md как личный дневник для AI — я использую его как архитектурный документ живого продукта. Это не второй мозг. Это нервная система сервиса. Операционная система разработки, которая не зависит от того, помню ли я что делал три месяца назад.

В корне моего проекта лежит файл CLAUDE.md. Это не README и не документация для людей. Это инструкция для агента — то, что он читает в начале каждой сессии работы.

Внутри:

Граф доменов. Весь продукт разбит на домены — Auth, Профиль, Услуги, Расписание, Слоты, Записи, Уведомления, Публичная страница. Каждый домен — это карточка: какие файлы трогать, от чего зависит, кто зависит от него. Агент не читает весь код подряд. Он открывает карточку нужного домена и работает точечно.

Готчи — живая база знаний. Каждый раз когда в процессе работы обнаруживается нетривиальный баг или архитектурное решение — оно фиксируется. Сейчас в файле больше 120 готч. Это институциональная память, которой нет ни у одной команды без CTO с 5-летним стажем в проекте.

Пара примеров из реального файла:

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

Карта влияния. Таблица: "изменил X — обязательно проверь Y". Например, если я трогаю booking.service.ts — агент автоматически знает, что нужно проверить slots.service.ts, notifications.service.ts и соответствующие тесты. Не потому что он умный. А потому что это написано явно.

Протокол начала и конца сессии. Каждая сессия начинается с одной команды bash scripts/project-state.sh — она показывает последние коммиты, изменённые файлы, статус серверов. Каждая заканчивается командой ЗАВЕРШАЕМ_СЕССИЮ — агент автоматически обновляет документацию, фиксирует что сделано, коммитит и пушит.

Я на 202-й сессии работы над проектом. Продукт за это время вырос от MVP до полноценного SaaS с авторизацией через VK ID и Magic Link, Telegram-ботом для напоминаний, блогом с SEO, демо-режимом, серийными записями, admin-панелью.

И я по-прежнему один.

При этом:

— Новая фича не ломает старую. Потому что граф доменов показывает зависимости.

— Я не держу контекст в голове. Потому что он в файле.

— Агент не делает "drive-by рефакторинг" — не трогает то, что не просили. Это тоже написано явно в правилах.

— Рискованные задачи (авторизация, миграции БД) выполняются в изолированном worktree — отдельная копия репозитория, main не затрагивается до ревью.

Это не магия. Это система.

Я не утверждаю что этот подход идеален или что он подойдёт всем.

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

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

Потому что GoToBook — живой продукт, и мне важно чтобы специалисты о нём знали.

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

gotobook.ru

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

P.S. Файл CLAUDE.md у меня открытый по духу — не секретный. Если будет интерес, могу опубликовать шаблон отдельно.