Соло-марафон: 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 хвилин та сама сесія активна з Бангкоку — щось не так.
• Авто-розлогін підозрілих сесій з імейл-нотифікацією — якщо система детектить аномалію (різка зміна гео, нова країна, незвичний user-agent), сесія завершується, користувач отримує імейл із деталями: коли, звідки, з якого пристрою. Один клік — і ти в курсі того, що відбувається.
• Менеджер активних сесій — користувач у будь-який момент бачить повний список своїх активних сесій (пристрій, браузер, гео, час останньої активності) і може примусово завершити будь-яку з них. Загубив телефон? Залишив авторизацію на чужому ноутбуці? Один клік — і сесія завершена.
• Захист сесійного менеджера за моделлю 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 — це скажена клавіатура. Барбершоп — реальність. А між ними сидить архітектор. Без архітектора і точкових знань “як правильно” скажена клавіатура надрукує тобі дуже багато скаженого ші-слопу, з яким ти впоратися буде майже нереально — та і чи є сенс?