Привет! Меня зовут Дмитрий. Я делал проекты в разных сферах, но все они заканчивались на стадии MVP, хоть и по разным причинам: идея стала никому не нужна, команда выгорела или не хватило скиллов довести до результата.
Поэтому новый проект я начал с намерением дойти до реального работающего продукта с клиентами.
Первое с чего я начал - поиск идеи. Тут есть разные подходы, но один из тех что точно работает: решить боль свою или кого-то из близкого окружения. И если таких людей будет много, то идея стоит усилий.
Одна подруга постоянно жаловался что делать формы - это мучение. Интерфейс неинтуитивный, каждую форму собираешь вручную, несколько страниц - отдельный квест. Я зацепился за это и стал изучать рынок.
После 2022 года из России ушли многие зарубежные сервисы. А с 2025 года компании, которые работают с персональными данными клиентов, потеряли возможность использовать даже бесплатные иностранные аналоги, потому что данные обязаны храниться на российских серверах. Российский рынок форм оказался неожиданно пустым.
Так несколько пазлов сложились вместе, поэтому я решил сделать удобный сервис для создания форм, но с уклоном в новые технологии.
Потом началось время работы над продуктом. Казалось, что один шаг отделяет MVP от продукта, который покупают, но это была иллюзия.
Технически всё понятно: бэкенд, фронтенд, архитектура. Но продукт - это не только код. Дополнительно нужно разобраться с оформлением юрлица, авторизацией, 152-ФЗ, политикой конфиденциальности, пользовательским соглашением. Раньше до этих шагов просто не доходил, а без этого продукт нельзя запустить. Хорошо что с YouTube и ChatGPT это всё делается быстрее.
После этого была готова первая версия, которая закрывала базовый сценарий - создать форму, опубликовать, собрать ответы. Но чтобы это работало по-настоящему хорошо, нужно было решить несколько инженерных задач, которых у аналогов либо нет, либо они реализованы поверхностно.
Адаптивный роутинг моделей. Первая реализация была простой: один промпт, одна модель. Быстро стало понятно что это не работает. Простая форма на три поля не требует тяжёлой модели - дорого, медленно, избыточно. А сложная многостраничная форма на лёгкой модели даёт мусор. Система оценивает сложность задачи до вызова модели: длина промпта, многостраничность, количество полей, ключевые слова. На выходе три уровня - simple, medium, complex - каждый маппится на свою модель. Стоимость генерации упала, скорость на простых задачах выросла в разы.
Fallback и отказоустойчивость. LLM-провайдеры падают - это не вопрос «если», а вопрос «когда». Поэтому в архитектуре два провайдера. Если тяжёлая модель вернула таймаут или ошибку - повтор на базовой у второго провайдера. Кредиты списываются только за успешный ответ.
Когда LLM-провайдер упал в продакшне в первый раз Двухшаговая генерация. Для сложных форм одношаговая генерация нестабильна: модель теряет контекст, путает типы полей, забывает про страницы. Решение - сначала модель генерирует план структуры, потом детализирует каждую страницу. Лишний LLM-вызов, но качество кратно выше. Триггер - тот же роутер сложности.
Генерация из файлов. Пользователь загружает PDF, DOCX, TXT или MD - получает готовую форму. Основная сложность не в извлечении текста, а в разнообразии документов: структурированный бриф из ChatGPT и скан с кривым OCR - это совсем разные задачи. Пришлось добавить предобработку и нормализацию текста перед отправкой в модель.
ИИ-агент в редакторе. Форма создана, но нужно что-то поменять. Пользователь пишет: «добавь поле телефона», «удали комментарий», «разбей на две страницы». Агент получает текущую структуру и инструкцию, возвращает изменённую версию. Ключевое решение - умное слияние: существующие поля сохраняются, если их явно не просили удалить. Новые поля размещаются автоматически - агент определяет логическое место в структуре.
Guard и безопасность промптов. Если продукт принимает произвольный текст и отправляет в LLM - prompt injection неизбежен. Фильтрация на входе, лимиты на размер, валидация типов полей на выходе, проверка структуры ответа. Если модель вернула что-то невалидное - ответ отклоняется. Не решает проблему на 100%, но закрывает основные векторы.
Первый пользователь через 5 минут после запуска RAG-чат поддержки. Внутри продукта есть чат, который отвечает по документации. Классический RAG: индексация документации, поиск релевантных фрагментов, передача в LLM с вопросом. Для продукта без команды поддержки - отличный способ закрыть вопросы пользователей.
Выводы
Даже если вы делаете простой AI B2B SaaS - один сценарий, понятная аудитория, проверенные технологии - вы неизбежно столкнётесь с трудностями, которые не видны на старте.
Главное что вынес: архитектуру и всё что не связано с кодом нужно планировать заранее. Роутинг моделей, fallback, безопасность промптов - всё это проще заложить в начале, чем прикручивать к работающему продукту. То же самое с юридикой, дизайном и инфраструктурой - они не ждут, пока вы закончите с кодом.
Код - это может быть 40% работы. Остальное - юрлицо, 152-ФЗ, дизайн, деплой, продвижение. К этому стоит быть готовым, чтобы потом не пришлось переделывать на ходу.
Буду рад обратной связи в комментариях — что бы вы улучшили, что понравилось, как вы сейчас решаете задачу сбора данных через формы? Какие инструменты используете и что в них бесит?
Дмитрий, AI/ML-инженер, основатель caltoforms.ru
