Запустили за 5 дней: как AI-агенты собрали полноценный SaaS-продукт

От первого лица — Алексей, основатель MinglesAI

24 февраля 2026 года в 10:27 утра я написал три строки в Telegram-групповой чат:

@DevClawBot new project https://github.com/MinglesAI/dev_claw_demo main

Через пять дней ai-readiness.mingles.ai уже работал в продакшне — полноценный SaaS с 18-точечным движком анализа AI-готовности, MCP-сервером, микроплатежами x402, административной панелью, Google Analytics, полноценным REST API и публичной документацией. Я не написал ни строчки кода.

Это история о том, как мы до этого дошли: что пошло не так, что агенты сделали правильно и где мне пришлось вмешаться самому.

Предпосылки: что мы хотели построить

Идея пришла от AI-исследовательского агента, которого я запускал параллельно. Из списка 10 микро-SaaS концепций, которые он сгенерировал, одна выделялась особо: AI-readiness checker — инструмент, анализирующий, насколько сайт адаптирован для обнаружения AI-поисковиками: Perplexity, ChatGPT, Gemini.

Момент казался подходящим. Все SEO-компании пивотировались в «GEO» (Generative Engine Optimization). Сами проверки были хорошо определены: структурированные данные Schema.org, llms.txt, разрешения robots.txt для AI-краулеров, Open Graph теги, глубина контента, канонические URL. Именно то, что разработчик может проаудировать за полдня — но никто ещё не превратил это в продукт.

Стек, который мы использовали:

• DevClaw — слой AI-оркестрации, работающий как плагин OpenClaw и диспетчеризующий агентов Claude через GitHub Issues

• Telegram — мой командный интерфейс ко всей системе

• GitHub — каждое изменение проходит через PR; ничто не мерджится без ревью

• Claude Opus 4.6 / Sonnet 4.6 / Qwen3-235B — модели, выполняющие реальную работу

• FastAPI + React + PostgreSQL + Docker — продуктовый стек

Моя роль: продакт-менеджер. Я описываю, что хочу, ревьюю PR, когда агенты не могут автоматически смерджить, и принимаю архитектурные решения, когда агенты упираются в стену.

Антон, мой сооснователь, тоже был в чате — задавал острые вопросы и проверял предположения агентов.

День 1–2: Фундамент (24–25 февраля)

В 10:47 первого дня я вставил бриф исследовательского агента и попросил DevClaw спланировать MVP. Через несколько минут:

Антон сразу это поймал:

Оркестратор скорректировался:

Я выбрал Вариант C. К 10:51 — через 24 минуты после регистрации проекта — два агента уже работали параллельно:

• Roberta (medior) → Фундамент и настройка проекта (FastAPI, React, PostgreSQL, Docker)

• Justine (senior) → Backend-движок анализа URL и AI-readiness scoring

К 10:55 — первый «вот это да» момент:

Фундамент был готов: Traefik + HTTPS, Docker Compose, FastAPI с health-эндпоинтом живым на /api/health. Через двенадцать минут после старта.

Остаток первого дня — каскад параллельных агентов, выполнявших задачи, которые мне даже не нужно было детально описывать: Stripe-биллинг, JWT-авторизация, страница UI для выставления счетов, фиксы SPA-маршрутизации, улучшения движка скоринга. К полуночи 20 задач были в Done.

Что агенты делали неправильно в первый день: несколько воркеров открыли дублирующиеся PR для одного и того же issue, несколько запутались с ветками и сообщили «blocked» когда реально были готовы. Оркестратор это разобрал — но было шумно.

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

День 2.5: Пивот

25 февраля в 22:47 я написал сообщение, изменившее направление всего проекта:

Это была полная миграция: новый репо, новый домен, новая кодовая база фронтенда (я сам собрал UI в Lovable и хотел объединить его с бэкендом, написанным агентами).

Оркестратор справился чисто:

1. Закрыл все открытые задачи в старом репо

2. Зарегистрировал новый репо в DevClaw

3. Обновил ссылки на домен везде

4. Остановил активных воркеров, чтобы не тратить вычисления впустую

Затем я сам сделал миграцию в Cursor — перенёс бэкенд, добавил Google Auth, починил Stripe, починил CI — и открыл PR. Оркестратор отревьюил, подтвердил, что Docker Compose работает, и смерджил.

Один человеческий PR, смерджен оркестратором. Чистая передача.

День 3: Проблема монетизации — x402

26 февраля в 14:54 я описал следующую большую идею:

x402 — новый платёжный протокол, где сервер отвечает HTTP 402 («Payment Required») с заголовком оплаты. Клиентский кошелёк подписывает USDC-микротранзакцию и повторяет запрос. Никакой регистрации, никакого аккаунта — просто заплати и получи результат.

Агент-архитектор исследовал кодовую базу и создал приоритизированный беклог:

1. #7 — Публичный REST API + API-ключи (предварительное условие для всего)

2. #8 — LLM Analysis Pipeline

3. #9 — MCP Tool Server

4. #10 — x402 Micropayments

5. #11 — Landing Page + Docs

Каждый — менее чем за час. К 18:26 сеньор-разработчик реализовал x402 end-to-end: платёжный шлюз на стороне сервера, ответ PaymentRequired с USDC на Base Sepolia, интеграция с фасилитатором через x402.org.

Потом мы попробовали это реально использовать.

# Тестируем x402 — попытка 1 curl -X POST https://ai-readiness.mingles.ai/api/v1/reports/{id}/enhance # → 500 Internal Server Error

Три бага, найденных последовательно:

1. Редирект URL фасилитатора — x402.org редиректил на www.x402.org, а бэкенд не следовал за 308-редиректами. Исправление: одна строка.

2. Неправильное название поля — бэкенд отправлял "payment" в пейлоаде, но фасилитатор ожидал "paymentPayload". Обнаружено оркестратором, который вручную делал curl к эндпоинту в полночь.

3. Синхронная блокировка — вызов сеттлмента был асинхронным по названию, но блокирующим на практике, добавляя до 30 секунд задержки. Исправление: asyncio.create_task().

У JS-клиентского SDK тоже были свои особенности. Агент написал ручную реализацию подписи EIP-3009 через viem вместо SDK, что сработало лучше.

К концу третьего дня серверная сторона x402 работала корректно — бесплатный пользователь обращался к enhance-эндпоинту, получал 402 с корректными метаданными платежа, и шлюз держал. Полный клиент-серверный флоу был валидирован тестовым скриптом.

Вот как выглядит этот 402-ответ на практике:

{ "x402Version": 1, "accepts": [{ "scheme": "exact", "network": "eip155:84532", "maxAmountRequired": "50000", "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e", "payTo": "0x0Ae....9C", "description": "AI analysis enhancement - $0.01" }] }

Заплати, повтори запрос, получи расширенный отчёт. Аккаунт не нужен.

День 4: Полировка, дистрибуция и самоанализ

Четвёртый день был посвящён завершению продукта и его выводу к людям.

Административная панель — пользователи, управление API-ключами, аналитика использования. Построена сеньор-агентом, отревьюена другим, смерджена за один раз. +1 265 строк, ноль конфликтов.

Google Analytics 4 — я отправил фрагмент кода отслеживания GA4, агент обернул его в GDPR-совместимый компонент согласия на куки, добавил типизированное отслеживание событий для analyze, enhance, login и действий с API-ключами. Смерджено.

MCP-регистры — оркестратор открыл PR в:

• punkpeye/awesome-mcp-servers (81k ⭐ — основной список)

• официальная секция экосистемы coinbase/x402

• Создал server.json и smithery.yaml для автоматического обнаружения

Момент 86/100. 27 февраля в 21:44 мы прогнали собственный сайт через наш собственный анализатор:

Агенты построили инструмент, затем использовали его для аудита самих себя, затем исправили проблемы. Сайт набрал 100/100 по техническим проверкам (Schema.org, llms.txt, robots.txt, sitemap, canonical, OG-теги) и 74.5/100 по глубине контента.

День 5: Запуск

28 февраля. К этому моменту продукт имел:

• 20 PR смерджено за 48 часов

• +6 294 / -494 строк кода

• 34 коммита в двух репозиториях

• 0 строк, написанных мной

Оставшиеся задачи были ориентированы на дистрибуцию: отправка в x402-маркетплейсы, Smithery, mcp.so, шаблоны URL для шаринга отчётов, система поддержки.

Одну вещь мне пришлось исправить вручную: merge conflict в PR шаринга ссылок, который висел нерешённым 10+ часов. Агенты правильно помечали его как «DIRTY» в каждом обновлении статуса heartbeat, но не могли разрешить его без человеческого вмешательства. Я починил в Cursor, запушил, агент-ревьюер смерджил.

Система поддержки — форма обратной связи, ticket API и базовая маршрутизация поддержки — была последним отправленным элементом:

# Что агент построил за одну сессию: POST /api/v1/support/tickets # submit ticket GET /api/v1/admin/tickets # admin list view PATCH /api/v1/admin/tickets/{id} # update status GET /api/v1/support/tickets/{id}/status # public status check

Плюс миграция PostgreSQL, UI-панель администратора и заглушки email-уведомлений.

Что агенты сделали правильно

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

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

Самокоррекция. Когда ревьюер оформил баг-репорты (#46, #47 по edge-кейсам x402), следующий воркер подхватил их и исправил. Пайплайн поймал то, что обычно проскакивает в продакшн.

Формирование follow-up задач. Агенты самостоятельно создали 20+ подзадач в процессе реализации — вещи, которые они заметили, но были вне скопа. Каждая из них попала в Planning для человеческого ревью.

Что всё ещё требует людей

Архитектурные решения. Первоначальный пивот с dev_claw_demo на ai-site-scorer был моим. Агенты могут блестяще выполнять план, но не ставят под сомнение, правильный ли этот план.

Отладка x402. Три из пяти x402-багов потребовали, чтобы я вручную делал curl к эндпоинту и читал сырые ответы. Агенты могли реализовать исправление, как только я описал точное поведение, но диагностика — особенно через границу API фасилитатора — требовала человека, способного читать логи и рассуждать о протоколе.

Merge conflicts. Любой конфликт, требующий понимания намерений через две ветки, был блокером. Агенты правильно сообщали «DIRTY, требует ручного исправления», но не пытались его разрешить. Справедливо.

Вопрос «что мы строим». Антон спросил в середине проекта: «Это вообще бизнес? Люди ожидают, что такие инструменты будут бесплатными. Те, кто готов платить, уже пользуются Semrush.»

Честный ответ: неясно. Угол x402 интересен — pay-per-use анализатор, работающий без регистрации, вызываемый напрямую AI-агентами. Но мы ещё ничего не продали. Оркестратор сказал это хорошо:

Реальные затраты

Стоимость токенов — главная переменная. Сеньорные (Opus) воркеры дорогие. Мы переключили несколько ролей на Sonnet и Qwen3-235B в середине проекта, чтобы сократить расход — это сработало нормально для junior/medior задач.

Что дальше

x402-флоу работает end-to-end в тестнете. Следующий рубеж — майннет: первый платящий пользователь, реальный USDC.

Блог, который вы сейчас читаете, тоже написан AI-агентом (этим самым). Мета? Определённо. Но петля замыкается красиво: AI-агенты построили продукт, попали в MCP-регистры, и теперь AI-агенты пишут о том, как AI-агенты построили продукт. PR в punkpeye/awesome-mcp-servers ожидает ревью.

Если хотите протестировать анализатор: ai-readiness.mingles.ai — доступен бесплатный уровень, или подключите API-ключ.

Если хотите подключить к вашей IDE или CI-пайплайну:

{ "mcpServers": { "ai-site-scorer": { "url": "https://ai-readiness.mingles.ai/api/mcp/", "headers": { "Authorization": "Bearer YOUR_API_KEY" } } } }

Или пропустите API-ключ полностью и пусть x402 обрабатывает оплату за каждый вызов.

Ключевые цифры

• ~5 дней от первого коммита до продакшна

• 34 коммита смерджено

• 20 PR за 48 часов (пиковая скорость)

• +6 294 / -494 строки кода

• 0 строк, написанных человеком

• Используемые модели: Claude Opus 4.6, Claude Sonnet 4.6, Qwen3-235B

• Самооценка: 86.3/100 по нашему собственному анализатору

Алексей — основатель MinglesAI. DevClaw — слой AI-оркестрации кода, построенный на OpenClaw.