Разработка ИИ-решений под вашу задачу.

Готовый продукт покрывает процесс, который у сотен компаний устроен примерно одинаково: контроль качества разговоров, ответы клиентам в мессенджерах, обзвон базы, тренировка менеджеров. Там уже придуманы и сценарии, и метрики, и способ подключения — платить за повторную придумку незачем. Кастомная разработка начинается там, где процесс устроен по-вашему и типового решения под него просто нет. Наш угол — процессы с цифрой в деньгах: продажи, заявки, контроль качества. Техническую разработку без такой цифры — чат-бот для сотрудников, поиск по внутренним документам — ведёт студия 404gen.

Четыре признака, что нужна разработка

• Процесс не совпадает с рыночным. Не «продажи вообще», а ваша схема согласований, ваш расчёт цены, ваши правила допуска клиента к сделке — то, что нельзя описать настройками чужого продукта.
• Нужна связка с системой, у которой нет готового коннектора. Самописная ERP, 1С с нетиповыми доработками, отраслевой софт, внутренний сервис без публичного API.
• Данные не должны выходить из вашего контура. Развёртывание на вашем железе, приватные модели, отдельный сегмент сети — требование, при котором облачная подписка отпадает сама.
• Решение становится частью вашего продукта. Модуль внутри вашего сервиса или личного кабинета, а не внешний инструмент, которым пользуются ваши сотрудники. Если нужен сам экран для клиента — мини-приложение в MAX или Telegram либо своё приложение, — это услуга разработка приложений для бизнеса; здесь мы делаем ИИ-логику и бэкенд под ним.

Когда мы отговариваем от разработки

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

Считать нужно не стоимость разработки, а разницу. Подписка почти всегда дешевле первого года собственной разработки. Разработка выигрывает тогда, когда у неё есть то, чего в подписке нет в принципе: ваш процесс целиком, ваш контур данных или ваш же продукт на выходе. Если единственный довод — «хотим своё», это обычно дорогой довод.

Есть и третий вариант, про который забывают: задача названа, продукт под неё существует, но его надо довести до работы в вашем потоке и связать с вашими системами. Это не разработка и не подписка, а внедрение одного процесса. Когда процессов несколько и они связаны между собой, разговор переходит на уровень ИИ-трансформации — программы с приёмкой по этапам.

• Объём сценариев. Один сценарий и двенадцать сценариев — это не разница в цене на проценты, а разные проекты. Большая часть работы уходит не в счастливый путь, а в ветки, где клиент повёл себя иначе.
• Интеграции. Система с документированным API подключается за дни; самописная база без документации — это сначала разбор чужого кода, и предсказать его объём по описанию нельзя, только по доступу.
• Состояние данных. Если записи, переписки и выгрузки уже есть — работаем на них. Если данных нет или они не размечены, в смету входит их сбор и подготовка, и это отдельный этап со своим сроком.
• Требования к контуру. Облачные модели дешевле и быстрее. Развёртывание на вашем железе, приватная модель и закрытый сегмент сети — дороже и дольше, и об этом лучше знать в начале.
• Порог качества. «Ошибается редко» и «ошибается не чаще, чем в одном случае из ста, а в спорных молчит» — это разные объёмы работы. Порог формулируется цифрой до старта, иначе спорить о результате нечем.
• Сопровождение. Что происходит после запуска: кто следит за качеством ответов, кто обновляет правила, что считается сбоем и за сколько он чинится.

Вилка в пять раз — это не оценка, а отказ оценивать. Поэтому порядок такой: бриф, затем фиксированная сумма за конкретный объём работ. Если по ходу объём меняется — изменение оформляется отдельным этапом со своей суммой, а не растворяется в «доработках».

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

Отдельный вопрос — что считается доведённым до работы в проде. Критерии там одинаковые для любого AI-проекта, своего или коробочного, и разобраны на странице внедрения одного процесса: реальный поток вместо демо-данных, результат в ваших системах, владелец с вашей стороны, цифра до и после и заранее описанный сценарий на случай сбоя.

• Исходный код. В вашем репозитории, с историей коммитов. Права на разработанное под проект решение переходят вам по договору.
• Доступы и ключи. Серверы, хранилища, ключи к моделям и внешним сервисам оформляются на вашу компанию. Не на нашу учётную запись, из которой вас потом нельзя отцепить.
• Документация. Как развёрнуто, как поднять с нуля, где лежат правила и промпты, как их менять, что мониторить и что делать при сбое.
• Возможность уйти. Решение, которое нельзя передать другой команде, — это не решение, а привязка. Передача — обычный этап, а не услуга по отдельному прайсу.

Исключение одно и оно проговаривается заранее. Наши собственные продукты — Эхолитикс, Везория, Дирижёр, Фонекс, Коуч и Кира — остаются нашими продуктами: если часть задачи закрывается ими, вы получаете доступ и интеграцию, а не исходники платформы. Всё, что написано специально под ваш проект, передаётся вам.

• Модель ошибается — всегда. Вопрос не в том, случится ли ошибка, а в том, что происходит после неё. Поэтому в проекте заранее размечаются точки, где решение обязано позвать человека, и темы, которые оно не трогает вовсе.
• Данных может не хватить. Это выясняется на брифе, и тогда первый этап — не разработка, а сбор: включить запись, выгрузить историю, собрать хотя бы месяц. Начинать стройку раньше — тратить ваши деньги на догадки.
• Прототип — это прототип. Рабочий прототип за 2–6 недель показывает, что механика работает. Между ним и продакшном лежат нагрузка, отказоустойчивость, права доступа и мониторинг — и это отдельный объём работ, а не «ещё пара дней».
• Интеграция может упереться не в нас. Доступ к чужой системе, согласование службы безопасности, лимиты чужого API — типичная причина сдвига срока. Такие зависимости выписываются в план явно, с именем ответственного с вашей стороны.
• Часть задач мы не берём. Там, где решение касается здоровья, права или денег клиента напрямую, генерация без проверки человеком недопустима — такие сценарии мы либо проектируем с обязательной проверкой, либо отказываемся. И не берёмся за проект «сделайте как у них», пока не названа задача, ради которой это нужно.