AI B2B SaaS с нуля: что стоит между MVP и продуктом

Поэтому новый проект я начал с намерением дойти до реального работающего продукта с клиентами.

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

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

После 2022 года из России ушли многие зарубежные сервисы. А с 2025 года компании, которые работают с персональными данными клиентов, потеряли возможность использовать даже бесплатные иностранные аналоги, потому что данные обязаны храниться на российских серверах. Российский рынок форм оказался неожиданно пустым.

Так несколько пазлов сложились вместе, поэтому я решил сделать удобный сервис для создания форм, но с уклоном в новые технологии.

Потом началось время работы над продуктом. Казалось, что один шаг отделяет MVP от продукта, который покупают, но это была иллюзия.

Технически всё понятно: бэкенд, фронтенд, архитектура. Но продукт — это не только код. Дополнительно нужно разобраться с оформлением юрлица, авторизацией, 152-ФЗ, политикой конфиденциальности, пользовательским соглашением. Раньше до этих шагов просто не доходил, а без этого продукт нельзя запустить. Хорошо что с YouTube и ChatGPT это всё делается быстрее.

• Адаптивный роутинг моделей. Первая реализация была простой: один промпт, одна модель. Быстро стало понятно что это не работает. Простая форма на три поля не требует тяжёлой модели — дорого, медленно, избыточно. А сложная многостраничная форма на лёгкой модели даёт мусор. Система оценивает сложность задачи до вызова модели: длина промпта, многостраничность, количество полей, ключевые слова. На выходе три уровня — simple, medium, complex — каждый маппится на свою модель. Стоимость генерации упала, скорость на простых задачах выросла в разы.

• Fallback и отказоустойчивость. LLM-провайдеры падают — это не вопрос «если», а вопрос «когда». Поэтому в архитектуре два провайдера. Если тяжёлая модель вернула таймаут или ошибку — повтор на базовой у второго провайдера. Кредиты списываются только за успешный ответ.

  

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

• Генерация из файлов. Пользователь загружает PDF, DOCX, TXT или MD — получает готовую форму. Основная сложность не в извлечении текста, а в разнообразии документов: структурированный бриф из ChatGPT и скан с кривым OCR — это совсем разные задачи. Пришлось добавить предобработку и нормализацию текста перед отправкой в модель.

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

  Guard и безопасность промптов. Если продукт принимает произвольный текст и отправляет в LLM — prompt injection неизбежен. Фильтрация на входе, лимиты на размер, валидация типов полей на выходе, проверка структуры ответа. Если модель вернула что-то невалидное — ответ отклоняется. Не решает проблему на 100%, но закрывает основные векторы.

  

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

Выводы

Даже если вы делаете простой AI B2B SaaS — один сценарий, понятная аудитория, проверенные технологии — вы неизбежно столкнётесь с трудностями, которые не видны на старте.

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

Код — это может быть 40% работы. Остальное — юрлицо, 152-ФЗ, дизайн, деплой, продвижение. К этому стоит быть готовым, чтобы потом не пришлось переделывать на ходу.

Буду рад обратной связи в комментариях — как вы решаете похожие задачи, с чем сталкивались при запуске и что бы сделали иначе.

Дмитрий, AI/ML-инженер, основатель caltoforms.ru