Как превратить AI-прототип в production SaaS

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

Самое сложное — не модель, а то, что production AI-продукт — это обычный софтверный продукт с вероятностным ядром. Ему нужна та же дисциплина, что любому SaaS: тестирование, мониторинг, контроль доступа, защита данных — плюс новая дисциплина, специфичная для LLM: оценка качества и контроль стоимости.

Прототип отвечает на вопрос «может ли это работать?». Production отвечает на вопрос «может ли это работать для всех, каждый день, по известной цене?».

• Оценка первой — определить метрики успеха и фиксированный тест-сет до написания новых фич. Никакого релиза без quality gate.
• Модель стоимости — считать токены на бизнес-результат. Фича, которая стоит больше создаваемой ценности, — это не фича, а убыток.
• Guardrails — валидация входов и выходов, пути отказа, лимиты и человеческий review критичных действий.
• Слой данных — PostgreSQL для состояния и логов, эмбеддинги для retrieval и пайплайны, которые держат данные свежими.
• Observability — каждый LLM-вызов логируется: модель, токены, задержка, стоимость, оценка качества. Алерты при дрейфе качества.

Порядок намеренный: оценка до масштаба, стоимость до фич, guardrails до пользователей, данные до интеллекта, observability до запуска.

Прототип может быть одним эндпоинтом. Production SaaS требует границ — даже если код остается монолитом, ответственности разделены быть обязаны:

• Слой оркестрации — LLM-вызовы, организованные в пайплайны или агентов, отдельно от HTTP-слоя.
• Асинхронная обработка — тяжелая AI-работа выполняется в фоновых джобах с очередями и ретраями: интерфейс не блокируется на 30-секундной генерации.
• Кэширование — повторные и похожие запросы кэшируются по хэшу входа и семантическому ключу, снижая и стоимость, и задержку.
• Изоляция тенантов — данные клиентов разделяются на уровне базы, а не обещаниями в коде.
• Auth и биллинг — стандартная SaaS-обвязка проектируется до первого платящего пользователя, а не после десятого.

Правило, которым мы пользуемся: если слой нельзя объяснить одним предложением и протестировать изолированно — это еще не граница, а будущий беспорядок.

• Маршрутизация моделей — OpenRouter и аналоги позволяют роутить по задачам: дешевые модели для классификации, frontier — для рассуждений, лимиты на тарифный план.
• Стриминг — потоковый вывод превращает 20-секундное ожидание в первую секунду ответа, и это меняет восприятие продукта.
• PostgreSQL — состояние, логи и векторы в одной базе; Prisma как типизированный слой данных.
• Next.js — серверные компоненты для быстрых страниц, клиентские — для интерактивных AI-опытов, одна кодовая база для веб-приложения и маркетингового сайта.
• Версионирование промптов — промпты деплоятся как код: версионируются, ревьюятся, прогоняются через оценку и откатываются.

Оба флагманских продукта прошли именно этот переход:

• LeadForge AI — начинался как прототип агента-исследователя и стал SaaS-платформой: мультиагентный пайплайн с review качества, состояние в PostgreSQL, векторный retrieval для аутрича и интерфейс, где sales-команды просматривают и одобряют каждое сгенерированное сообщение.
• SEOFlow AI — вырос из эксперимента по исследованию ключевых слов в платформу с SEO-воркфлоу, оптимизацией контента, аналитикой и автогенерацией отчетов, организованную вокруг пользовательских задач, а не одиночных промптов.
• LaunchPilot AI — прототип планирования стал продуктовой платформой с генерацией roadmap, декомпозицией задач и отслеживанием прогресса: тяжелая LLM-работа ушла в фоновые пайплайны с типизированным выводом.

В каждом случае production-продукт отличается от демо — не потому что изменился AI, а потому что пользователи, стоимость и надежность сформировали архитектуру.