Соло-марафон: SaaS с AI за 37 дней

«37 дней, 373 коммита, один разработчик — и живой B2B SaaS в продакшне. AI не пишет продукты. AI пишет код для тех, кто умеет проектировать продукты»

Соло-марафон: SaaS с AI за 37 дней

37 дней непрерывной работы. 373 коммита. Один разработчик. На выходе — полноценный B2B SaaS для бизнеса сферы услуг: Clients.Express. Букинг, биллинг, кошелёк клиента, автономный AI-агент в Telegram, гео-трекинг сессий. Всё с нуля, без готовых шаблонов, без команды.

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

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

Почему с нуля, а не на готовом

Первый вопрос, который мне задали коллеги: «А почему не взять какой-нибудь готовый букинг-сервис и не допилить его под свои задачи?» Ответ в двух словах: потому что я знал, что будет дальше.

Готовые решения закрывают первые 60% задач. Те 60%, которые ты видишь на лендинге. А остальные 40% — это биллинг с подпиской, мультитенантность, AI-агент, который реально разговаривает с пользователем в Telegram, гранулярная безопасность сессий. На этих 40% любое готовое решение превращается в патч поверх патча, где ты больше борешься с чужой архитектурой, чем пишешь фичи.

На старте я всё же попробовал пойти простым путём. Первые дни я писал на Laravel + Filament — типичный выбор, когда нужно быстро собрать админку для CRUD. На демо это выглядит как магия: одна команда — и вот тебе готовая панель. Но буквально через несколько дней я упёрся в стену. Каждый раз, когда нужна была фича, которую Filament не умеет из коробки — нестандартный поток действий и нестандартные элементы интерфейса, специфическая логика биллинга — я тратил больше времени на то, чтобы «уговорить» Filament сделать по-моему, чем потратил бы на собственную реализацию с нуля.

В какой-то момент я понял простую вещь: Filament — отличный инструмент для чужих стандартных задач, а не для моих нестандартных. Снёс его и начал разрабатывать собственную админку на чистом PHP 8.4 — это развязало мне руки идти дальше без всяких сторонних препятствий.

Но этот ресёрч вокруг Laravel дал мне побочный бонус, которому я реально рад: я наткнулся на Herd и почти сразу взял Pro-подписку, когда понял, насколько это мощный и профессиональный инструмент. До этого я годами сидел на MAMP Pro — и думал, что мне больше ничего не нужно. Оказалось, нужно. Все мои WordPress-проекты на Herd работают ощутимо быстрее, конфигурация — в разы проще, переключение версий PHP — буквально в один клик. MAMP Pro — это классика, но это уже легаси, как ни крути. Herd — новаторство, которое сделало мой локальный дев-стек комфортным до уровня «не замечаю, что оно есть».

Поэтому стек в финале чистый: PHP 8.4 без всяких фреймворков — только десяток точечно подобранных библиотек из Composer под конкретные задачи (PSR-совместимые компоненты, которые делают одно дело и делают его хорошо). Кастомная архитектура, собственная админка, своя модель данных, свои abstractions под подписки и букинг. Никакого унаследованного технического долга от кода, который писал не я.

Claude Code и Codex как AI-ассистенты для программирования

Тут ломаю одно распространённое заблуждение. Я не вайбкодил этот продукт. Я не сидел и не говорил модели «сделай мне SaaS для барбершопов». Так не бывает — точнее, бывает, но заканчивается грустно через две недели, когда ты не можешь объяснить, почему твоя же база данных выглядит так, как выглядит.

Я использовал Claude Code и Codex как AI-ассистентов для программирования в режиме human-in-the-loop — инструмент, который пишет код в десятки раз быстрее человека, не устаёт и не отвлекается, но каждый его шаг проходит через мою валидацию. Потому что у него есть одна принципиальная беда — он никогда не видел вашего продакшна и не несёт за него ответственности. Архитектуру держишь ты. Границы модулей очерчиваешь ты. Контракты между слоями определяешь ты. А он — пишет имплементацию, которую ты ревьюишь на лету.

Если конкретно — два агента, которые тянули этот марафон со мной: OpenAI Codex на модели GPT 5.4–5.5 и Claude Code на Opus 4.6–4.7 с 1M контекста. Это не случайный зоопарк, это осознанный выбор. Codex — быстрый, лаконичный, отлично держит короткие итерации по файлам и пишет чистый PHP-код без лишних абстракций. Claude Code на Opus с миллионным контекстом — это другая весовая категория: он держит в голове весь проект сразу, видит связи между модулями, понимает, как изменение в биллинге заденет букинг через три файла.

Распределение ролей выходит естественным само собой. Codex — для точечных задач: «перепиши этот контроллер», «добавь метод сюда», «сгенерируй миграцию». Claude Code — для архитектурных: ревью модуля целиком, рефакторинг с пониманием контекста, проектирование новых слоёв. Один агент — быстрый исполнитель точечных задач, другой — старший инженер, который видит картину целиком. Когда они работают в тандеме под руководством архитектора, который держит продукт в голове — скорость становится неприлично высокой.

В таком режиме один Senior делает работу команды. Не потому что AI это магия. А потому что человек-архитектор больше не тратит половину дня на boilerplate, миграции, CRUD-контроллеры, валидацию форм и прочую рутину, которую раньше нужно было писать руками.

373 коммита за 37 дней — это в среднем 10 в день. В какие-то дни было 25, в какие-то — 2 (когда я долбил один баг или переписывал архитектуру модуля). Это не «AI делает за меня». Это я делаю вдвое быстрее, чем смог бы сам.

Киллер-фича #1: автономный AI-агент в Telegram

Самая сложная и самая интересная часть продукта — Telegram-агент, который реально понимает, чего хочет пользователь, и делает это сам. Не «нажми /start, потом /book, потом выбери дату из списка». А просто: «запиши меня к Оле на завтра после обеда на стрижку».

Архитектурно это JSON tool loop: модель получает описание доступных инструментов (book_appointment, check_availability, top_up_wallet, get_profile и т.д.), возвращает JSON с tool call, бэкенд выполняет, передаёт результат обратно в контекст, модель принимает следующее решение. Классическая агентная петля, но с несколькими узловыми вещами:

• Изоляция контекста — у каждого пользователя свой контекстный скоуп. Агент одного клиента физически не может увидеть данные другого, даже если галлюцинирует запрос. Проверка на уровне tool-handler, не на уровне промпта.
• Защита от галлюцинаций в БД — агент не пишет в базу самостоятельно. Ни одна mutation-операция не выполняется без инлайн-подтверждения пользователя в Telegram. Запись на 14:30 в среду? Кнопка «Подтвердить». Пополнение кошелька? Кнопка «Подтвердить». Если модель решила галлюцинировать и записать тебя на дату, которую ты не просил — ты просто не нажимаешь кнопку. Транзакции не произошло.
• Системный промпт как контракт — агенту разрешено говорить только о том, что касается продукта. Попытки раскрутить его на что-то стороннее (от погоды до инструкций по джейлбрейку) разбиваются о жёсткий tool-only режим.

Инлайн-подтверждение — это не UX-мелочь. Это фундаментальный слой безопасности. AI-агенты в 2026 — это круто, но позволять модели без ограничений писать в продакшн-БД клиентского биллинга — это сценарий, после которого пишут посты в LinkedIn о потерянных данных.

Киллер-фича #2: биллинг с «graceful degradation»

Здесь есть архитектурный нюанс, на котором стоит остановиться. В Clients.Express тариф привязан не к профилю пользователя, а к компании. Это принципиально меняет логику ограничений при просроченном платеже.

Если у пользователя закончилась подписка по конкретной компании — блокируется только бизнес-функция этой компании (новый букинг). Сам аккаунт пользователя продолжает жить полноценно: профиль доступен, реферальная программа работает, можно пользоваться кошельком, можно даже создать новую компанию и работать в ней. Пользователь не вылетает в никуда — он просто видит мягкое сообщение в нужном месте: «чтобы принимать новые записи в этой компании — продли подписку».

Почему это важно? Потому что сценарий «владелец барбершопа, к которому только что зашёл клиент, видит сломанный интерфейс» — это потеря клиента и доверия к сервису. А когда система спокойно говорит: «оплати тариф для этой компании — и поехали дальше», а остальные функции профиля продолжают работать — это совсем другое ощущение от продукта.

Технически это слой middleware, который знает, какие роуты критичные (write-операции букинга), а какие — read-only или сервисные (профиль, кошелёк, документы). Заблокировано выборочно, не «выключатель рубильником».

Киллер-фича #3: безопасность на уровне взрослого продукта

Безопасность — то, что в большинстве соло-проектов выглядит как «ну я же поставил HTTPS и bcrypt на пароли». В Clients.Express иначе:

• Fail2Ban — на уровне сервера, с кастомными фильтрами под логи приложения. Брутфорс по логину, агрессивные запросы к API, попытки взломать Telegram-вебхук — всё ловится и банит IP автоматически и безапелляционно 😉
• Гео-трекинг сессий — у каждой сессии есть привязка к стране и IP-провайдеру. Если ты зашёл из Киева, а через 10 минут та же сессия активна из Бангкока — что-то не так.
• Авто-разлогин подозрительных сессий с email-уведомлением — если система детектит аномалию (резкая смена гео, новая страна, необычный user-agent), сессия завершается, пользователь получает email с деталями: когда, откуда, с какого устройства. Один клик — и ты в курсе того, что происходит.
• Менеджер активных сессий — пользователь в любой момент видит полный список своих активных сессий (устройство, браузер, гео, время последней активности) и может принудительно завершить любую из них. Потерял телефон? Оставил авторизацию на чужом ноутбуке? Один клик — и сессия завершена.
• Защита сессионного менеджера по модели Apple/Telegram — только что созданная или «молодая» сессия не имеет права завершать другие, «старые» сессии. Логика проста: если кто-то только что пролез в твой аккаунт, он не сможет сразу разлогинить тебя с твоего основного устройства и захватить доступ.

2FA: TOTP + Passkeys

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

В Clients.Express пользователь может включить одновременно три типа 2FA:

• SMS-коды на номер телефона — классический бейзлайн, который я имплементировал и в предыдущих проектах. Не самый безопасный вариант (SIM-swap никто не отменял), но необходимый минимум для тех пользователей, у кого ещё нет Authenticator-приложения или устройства с биометрией.
• TOTP-коды через Google Authenticator (а также любое совместимое приложение — 1Password, Authy, Bitwarden) — классический RFC 6238, с QR-кодом для привязки и backup-кодами для восстановления доступа.
• Passkeys через WebAuthn / FIDO2 — подтверждение входа через Touch ID, Face ID, Windows Hello, аппаратные ключи (YubiKey и подобные). Никаких SMS и паролей — биометрия или физический ключ, как это делают Apple, Google и другие взрослые платформы.

Честно скажу — реализацией Passkeys я доволен отдельно. Это не та технология, которую ты просто включаешь через готовый пакет. WebAuthn требует понимания challenge-response потока, валидации attestation, правильной работы с public key credentials, обработки edge cases на разных платформах. Теперь это у меня работает — и будет работать во всех моих следующих продуктах и проектах моих клиентов.

Всё это вместе — не «защита на всякий случай», а нормальный санитарный минимум для SaaS, который касается денег пользователей. Да, безусловно, AI помог написать это быстрее. Но решать, как именно всё это должно работать — это уже моя инженерная ответственность, не агентская.

Платежи: как LiqPay сказал «нет», а Monobank сказал «Мяу!»

Отдельная глава этого марафона — эквайринг. Сначала я по инерции пошёл туда, куда идут все — и куда привык ходить сам: LiqPay от ПриватБанка. Я годами подключаю его клиентским интернет-магазинам, у меня с ним налаженная рабочая рутина, я даже сам использую его для собственного портала для своих клиентов. Поэтому казалось, что для своего SaaS это тоже будет самый быстрый вариант. Подал заявку на мерчанта, заполнил анкету, подождал и…. и получил отказ.

Партнёр по бизнесу и клиент объяснил мне лаконично: «Это государственная штука, им всё новое не интересно». Грубо? Да. Но по факту совпадает с моим опытом — мой SaaS не вписался в их сценарии, потому что не магазин, не доставка, не такси. Живая инновация — вне скоупа.

Попробовал Monobank — и замурчал. Всё произошло так, как должно было быть в нормальном мире: мне перезвонили, задали адекватные вопросы, ответили на мои, помогли открыть ФОП-счёт и прямо в процессе без проблем выдали мерчанта. Без анкет на 50 пунктов, без двухнедельных ожиданий, без «ваша заявка на рассмотрении». Просто люди, которые делают свою работу профессионально.

Теперь Clients.Express принимает платежи онлайн через Monopay — и это не просто техническая деталь, это тоже часть истории о том, почему 37 дней стало возможным. Потому что когда инфраструктура вокруг тебя работает адекватно — ты не тратишь недели на борьбу с ней. Отдельное спасибо котикам из Monobank — за профессионализм, который в нашей банковской реальности хочется отмечать отдельно. 🐱

SMS-уведомления: отдельная благодарность АльфаSMS

Ещё один момент, о котором не могу не сказать, потому что тема узкая, но показательная. Любой сервис с букингом нуждается в SMS-уведомлениях клиентам — напоминания о записи, подтверждения, отмены. Для этого нужно альфа-имя (sender ID), и обычно его регистрация — это отдельная история с ожиданиями, документами и возвратами анкет.

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

Я обратился в АльфаSMS — и они просто сделали мою работу легче. Вместо того чтобы гонять меня по двухнедельным регистрациям под каждый возможный тип бизнеса, они выдали мне целую пачку готовых общих альфа-имён под разные ниши моего SaaS и моментально активировали их в моём кабинете. Не за две недели. Не за день. Моментально. Никаких «возвращайтесь завтра», никаких «это альфа-имя занято». Просто — бах, активировано, пользуйся.

Конкретно сейчас клиенты Clients.Express могут рассылать SMS под такими альфа-именами:

• Info Vizit — универсальное для любой записи на визит
• Barbershop — для барбершопов
• Beautysalon — салоны красоты
• SAUNA, BaniSauny — сауны и бани
• SPA — спа-комплексы
• STO, Auto — автосервисы и СТО
• Hostel, Hotel — отели и хостелы
• Sport, Fitness — спортзалы и фитнес-клубы
• Massage — массажные кабинеты
• Clinic — клиники и медицинские центры
• Studio — творческие студии и коворкинги
• Online Urok — онлайн-обучение и репетиторы
• Manicure — нейл-мастера и маникюрные салоны

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

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

Краш-тест реальностью: когда архитектура встречает барбершоп

37 дней я строил систему. Всё работало. Тесты проходили. Демо-аккаунты радовали глаз. А потом я приехал к первому живому клиенту — барберу — на презентацию и настройку, деплоить продукт в боевой режим.

Первое, что сломалось — мой план. В моей голове букинг работал по чёткой сетке: 30-минутные слоты, 60-минутные слоты, длительность услуги, всё красиво. В реальном барбершопе барбер говорит: «слушай, я смогу втиснуть этого клиента между 14:15 и 14:40, у меня там окно после окрашивания». Между 14:15 и 14:40. Не на 14:00 и не на 14:30 — между!

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

Я профессионально доработал этот модуль — добавил возможность для барберов и админов вручную редактировать время каждой записи с градацией в 5 минут. Логика построена так, что ручное смещение влияет только на то, как онлайн-запись занимает место в календаре, но никак не затрагивает просчёт цены услуги. То есть мастер свободно «тянет» границы записи по календарю, чтобы втиснуть клиента в реальный рабочий ритм, а стоимость услуги остаётся той, что указана в прайсе. И отдельно хочу поблагодарить своих клиентов, которые делятся со мной такими кейсами и отзывами — именно благодаря этому мы вместе строим действительно лучший продукт под реальные задачи, а не под представление разработчика о них.

Второе, что сломалось — мобильный onboarding. У меня была красивая схема: новый клиент сканирует QR-код в Telegram, перебрасывается в бот, там автоматическая привязка к профилю. Я тестировал это на ноутбуке. На двух мониторах. QR на одном экране — Telegram-десктоп на другом. Всё шикарно.

В живом барбершопе барбер даёт клиенту телефон и говорит: «отсканируй вот это». Клиент открывает камеру. На экране телефона. Тот самый QR-код, который нужно сканировать камерой этого же телефона. Парадокс. Сканировать невозможно.

Снова переделка: deep link вместо QR, fallback на скриншот экрана с QR-кодом и отправку этого скриншота напрямую Telegram-боту, отдельный мобильный поток онбординга, который не требует сканирования вообще.

Вывод из реальности: AI не сидит в кресле клиента

Я могу попросить Codex написать мне модуль букинга. Он напишет — быстро, чисто, с тестами. Но ни Codex, ни Claude Code, ни одна другая модель не сидит в барбершопе и не знает, что барбер думает о времени иначе, чем программист.

То же самое с QR-кодом. Чисто инженерно, привязка через QR — элегантное решение. Я его тестировал. AI помог его запилить. Но только реальный клиент в реальном салоне с одним телефоном в руках показал, что вся эта элегантность — нерелевантна. Потому что UX нужно тестировать на людях, а не на мониторе разработчика.

Это и есть граница AI-разработки в 2026. Скорость — космическая. Качество кода — приличное. Архитектурное предвидение — ноль. Если ты не умеешь проектировать под реальных людей, AI просто сгенерирует тебе быстро неправильный продукт. Быстро неправильный — это не лучше, чем медленно неправильный. Это хуже: ты ещё и времени больше потратил, потому что теперь исправлять нужно не сотню строк, а тысячу.

Что означают 37 дней и 373 коммита в 2026

Самая честная формулировка, которую я могу дать: то, что раньше делала команда из 4-5 человек за 4-6 месяцев, сейчас делает один Senior-архитектор с AI-инструментами за месяц. Это не маркетинг и не хайп (ну может чуть-чуть хайпа 😊). Это факт, который подтверждается кодом, коммитами и живым клиентом, который уже пользуется системой.

Но есть цена. И эта цена не «купи подписку на Claude Code». Цена — это 17 лет опыта, которые держат архитектуру, безопасность, базы данных, сети, UX-паттерны, продакшн-операции, мониторинг и сотню других вещей в голове параллельно. AI ускоряет того, кто уже знает, что делает. Тех, кто не знает, AI просто делает быстрее неправыми.

Я вижу два сценария, которые сейчас разворачиваются параллельно:

• Senior-архитекторы становятся продуктивнее в 5-10 раз — и это новая норма для соло-разработки сложных продуктов. Один опытный инженер теперь реально может запустить SaaS, который раньше требовал стартапа с посевным раундом.
• Начинающие тонут быстрее — потому что генерируют код, который не понимают, на скорости, с которой не успевают его ревьюить. В продакшн летят мины, которые взорвутся в любой момент.

Итог: суперсила с условиями

На выходе — живой SaaS в продакшне с реальными платежами, AI-агентом, гранулярной безопасностью и «graceful degradation». И первый живой клиент — барбер, который своей реальностью заставил меня переписать два модуля за две ночи. Это не сказка про «AI сделал всё сам». Это история о том, как инструменты сжали месяцы в недели — для тех, кто умеет ими пользоваться.

Если хочешь посмотреть, что вышло — вот продукт: Clients.Express. Если хочешь такой же темп для своего бизнеса — знаешь, где меня найти: vitaliikaplia.com.

Как я уже говорил, AI — это сумасшедшая клавиатура. Барбершоп — реальность. А между ними сидит архитектор. Без архитектора и точечных знаний «как правильно» сумасшедшая клавиатура напечатает тебе очень много сумасшедшего ИИ-слопа, с которым справиться будет почти нереально — да и есть ли смысл?