Заказчик: «РЕСТФОТОАНАЛИТИКА» (London Restaurant Group). 25 лет на рынке, десятки точек корпоративного питания по стране.

Задача

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

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

Задача выглядела просто. Мы думали: загрузим таблицу в ИИ, спросим — получим ответ. Ошиблись.

Первая попытка и провал

Мы взяли ГигаЧат, облегчённую версию. Старшая не давала преимуществ — не стали переплачивать. Но модель не умела работать с таблицами напрямую. Данные приходилось скармливать огромным текстом.

Хуже другое: нейросеть путала столбцы, придумывала цифры и блюда, которых нет в меню. На вопрос «что убрать» отвечала уверенно и гладко — но полностью мимо реальных данных.

Одна ошибка, умноженная на десятки точек сети, превращалась в прямые убытки. Мы пытались уйти от человеческого фактора, а получили его с новой стороны — теперь уже от нейросети.

Тогда руководитель команды сказал: «Нейросеть — не калькулятор. Цифры должен считать код, а модель — только превращать результат в текст». Это стало поворотным моментом.

Решение: архитектура, в которой ИИ не врёт

Главный принцип: нейросеть не видит сырые данные. Мы дали ей набор кнопок — серверных функций. «Посчитать остатки», «найти топ списаний», «сравнить выдачу и потребление».

Модель решает, какую кнопку нажать, а код на сервере всё считает и возвращает точные цифры. ИИ только упаковывает их в понятный ответ. По сути, мы превратили нейросеть в интерфейс — как голосовой помощник, который понимает речь и нажимает кнопки вместо вас.

Четыре шага к рабочему решению

Шаг 1. Изоляция данных. Таблица живёт на сервере заказчика. Все расчёты делает код. Нейросеть не читает таблицу и не держит её в памяти. Никаких гигантских текстов. Данные не покидают контур компании.

Шаг 2. Нейросеть как менеджер. Пользователь спрашивает: «Что убрать из меню за неделю?» Модель понимает, что нужны данные по списаниям, и вызывает нужную функцию с параметрами. Код всё считает и возвращает точные цифры. Модель получает результат и пишет ответ: «За неделю чаще всего списывали суп харчо и рыбные котлеты. Рекомендую убрать». Цифры посчитал код. ИИ выступил только как интерфейс.

Шаг 3. Двойная система инструкций. Мы прописали два слоя правил. Системная инструкция объясняет роль: «Ты аналитик, работаешь строго с цифрами, не додумываешь». Инструкция-напоминание уходит с каждым запросом: «Отвечай кратко, только по данным». Кстати, сами инструкции мы писали с помощью другой нейросети — получилось точнее и понятнее, чем у человека. Теперь используем этот приём в других проектах.

Шаг 4. Финальное решение за человеком. Стопроцентной точности не даёт никто. Поэтому в интерфейсе можно поправить ответ модели: название блюда, цифру, формулировку. Машина убирает рутину, но ответственность остаётся на операторе.

Результат

Прототип сделали за 3 недели силами двух разработчиков. Заказчик загружает отчёт, задаёт вопрос и получает рекомендацию за минуты. Раньше на это уходили часы ручного труда.

Стоимость запроса к ИИ сократили в 3–20 раз. До внедрения мы скармливали модели 30–100 тысяч токенов за раз. После — типовой запрос занимает 1,5–3 тысячи токенов.

Модель больше не устаёт, не фантазирует и не ошибается в цифрах.

Куда это можно масштабировать

Технологический кубик универсален. Достаточно настроить инструменты под другую сферу. Задача «есть таблицы от разных источников, нужно задавать вопросы на обычном языке и получать точные ответы» встречается везде:

• Розница — ежедневные отчёты по продажам и остаткам
• Логистика — данные по маршрутам, загрузке и топливу
• Финансы — выписки и платежи
• Производство — учёт сырья и готовой продукции

Главные выводы

Пять уроков, которые мы вынесли из этого проекта:

1. Не верьте заявленным пределам памяти нейросети. Производитель обещает 150 страниц текста — сбои могут начаться на первой трети. Проверяйте на своих данных.
2. Не переплачивайте за старшие версии. На табличных задачах разницы между Lite, Pro и Max может не быть. Тестируйте.
3. Нейросеть пишет инструкции для нейросети лучше человека. Структурнее, точнее, без двусмысленностей.
4. Инструменты вызова — это must-have. Мы нащупали этот подход в проекте и теперь тиражируем на другие отрасли.
5. Нейросеть — отличный интерфейс, но считать должен код.

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

Оставить заявку или задать вопрос → https://itfox-web.ru/ru/cases/chto-delat-esli-neiroset-vret-v-tsifrakh-my-perestali-davat-ei-syrye-d?utm_source=teletype&utm_medium=social&utm_campaign=rest_ai_case

Введение: новая реальность событийного рынка

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

Сегодня это не работает. Объём рынка офлайн-развлечений в 2025 году — 306 млрд рублей. Конкуренция выросла, и каждая ошибка в планировании бьёт по бюджету. На первый план выходят данные.

О чём речь? Это не только проданные билеты. Это:

• кто, когда и откуда покупает;
• какие каналы реально приводят зрителей;
• скорость продаж по разным площадкам;
• конверсия от просмотра до оплаты;
• жанровые предпочтения аудитории по городам;
• влияние сезона, дня недели и погоды на спрос.

Без этих знаний вы гадаете. С ними — принимаете решения, подкреплённые цифрами.

В статье:

• какие данные существуют и как их получать;
• что уже подтверждено статистикой;
• как использовать цифры для прогнозов;
• что ждёт тех, кто данные игнорирует.

Материал основан на исследовании концертной индустрии 2025–2026 от АЙТИФОКС. Полный текст — скоро в https://t.me/CEOItFox.

1. Какие данные бывают и где их искать

1.1. Публичные данные

Открытые источники: билетные платформы, отраслевые отчёты, поисковая статистика, соцсети, стриминги, СМИ.
Плюс: доступны всем. Минус: дают срез рынка в целом, но не ответ на вопрос «сработает ли моё конкретное событие».

1.2. Данные билетных систем

Самый ценный пласт: темп продаж по дням, цены по секторам, возвраты, география, доля новых и повторных покупателей, каналы привлечения.
Проблема: многие платформы не делятся этой информацией в полном объёме. Организатор видит кассу, но не портрет зрителя.
Выход: договариваться о расширенной аналитике или строить собственную систему сбора.

1.3. Собственные данные

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

2. Что статистика уже доказала

• Рынок растёт за счёт цены, а не аудитории. Ориентир — не «рост рынка», а реальное количество зрителей, которое вы способны привлечь.
• 74% билетов продаётся онлайн, но данные остаются у платформ. Удобство продаж оборачивается потерей контроля над аудиторией.
• Три крупнейших билетных оператора занимают уже 48% рынка. Работа через одного партнёра — зависимость. Диверсификация — свобода и больше данных.
• Концерты и фестивали ведут себя по-разному. В 2026 году концерты держат оборот за счёт цены, но теряют в штуках. Фестивали падают и по обороту, и по билетам. Считать фестиваль как «большой концерт» — ошибка.
• Средний чек — 2 639 рублей, но это «среднее по больнице». Разброс колоссальный. Считать нужно свой показатель под свой формат.

3. Как применять данные на практике

Прогноз продаж по дням. Исторические данные позволяют предсказать, когда будет пик, когда спад, и заметить риск недозагрузки за 2–3 недели.

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

Ценообразование по спросу. Ранние покупатели — ниже цена. Поздние — выше. Никаких панических скидок, только управляемая ценовая политика.

Оценка каналов продвижения. Понятно, сколько денег принёс каждый канал и сколько стоил один привлечённый зритель. Бюджет перераспределяется в пользу работающих инструментов.

4. ИТ-инструменты для работы с данными

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

АЙТИФОКС разрабатывает такие решения для организаторов, площадок и билетных сервисов.

5. Что будет с теми, кто работает без данных

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

Главное: он каждый раз начинает с чистого листа. Нет данных — нет базы для будущих решений.

Заключение

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

Данные дают:

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

Ключевой тезис: кто владеет данными о зрителе — управляет будущей маржой рынка.

АЙТИФОКС создаёт ИТ-продукты, которые превращают событийный бизнес из интуитивного — в управляемый и прогнозируемый.

Исследование целиком — в https://t.me/CEOItFox.

Концертная индустрия России в 2025 году показала рост до 306 млрд рублей — на 28% больше, чем годом ранее. Но есть нюанс: количество проданных билетов увеличилось всего на 2%, а относительно 2019 года продажи в штуках упали на 13%.

Рынок растёт за счёт цены, а не за счёт зрителя. Это ставит перед организаторами, площадками и билетными сервисами жёсткий вопрос: как сохранить прибыль, если зритель не становится активнее, а расходы растут?

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

В этой статье разберём:

• как цифровизация меняет событийную индустрию
• какие ИТ-продукты уже стали стандартом
• где технологии помогают сокращать потери
• что будет через 2–3 года

Материал основан на исследовании концертной индустрии 2025–2026, подготовленном АЙТИФОКС. Текст исследования будет опубликован в телеграм-канале https://t.me/CEOItFox, следите за новостями.

1. Почему цифровизация событий — это необходимость

1.1. Данные стали главным активом

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

Проблема в том, что большинство организаторов не владеют своей аудиторией. Зритель приходит через билетную платформу, покупает билет, посещает событие и уходит. Организатор не знает, кто это был, откуда он пришёл, купил ли дополнительные услуги, придёт ли снова.

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

«Кто владеет данными о зрителе после события, тот владеет будущей прибылью рынка» — из исследования АЙТИФОКС.

Цифровизация начинается с простого шага: перестать отдавать аудиторию билетной платформе. Начать собирать базу зрителей, сегментировать её, работать с ней и использовать для прогнозов и повторных продаж.

1.2. Рынок становится неоднородным

В 2025 году индустрия выглядела как единый растущий рынок. В 2026 году картина изменилась. По данным «Коммерсанта», в январе–мае 2026 года один из крупных билетных операторов показал сокращение продаж на 6% при сохранении оборота. Другие операторы, напротив, сообщали о росте.

Это означает, что отрасль больше не растёт «все вместе». Разница между компаниями — в способности управлять бизнесом на основе данных.

Организации, которые используют ИТ-продукты для прогнозирования, анализа и автоматизации, оказываются в группе растущих. Те, кто полагается на интуицию и таблицы, — теряют позиции.

1.3. Ожидания зрителей меняются

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

В событийной индустрии этого пока мало, но спрос уже есть. Зритель хочет получать релевантные предложения в удобное время, а не десятки одинаковых рассылок о неинтересных событиях.

Цифровизация даёт возможность сделать коммуникацию с каждым зрителем персональной. Без ИТ-продуктов это невозможно — не будет ни данных, ни инструментов для сегментации и автоматических сценариев.

2. Карта потерь: как технологии помогают перестать терять деньги

В исследовании АЙТИФОКС выделены ключевые зоны потерь. Цифровизация помогает сократить каждую из них.

2.1. Пустые места Потеря: каждое непроданное место — это потерянная выручка от билета, дополнительных услуг и повторной покупки.
Как технологии помогают:

• системы прогнозирования спроса на основе исторических данных
• гибкое ценообразование, меняющее цену в зависимости от спроса и времени до события
• автоматические уведомления о риске неполной заполняемости за 2–3 недели

2.2. Поздние продажи Потеря: продажи за 3–5 дней до события требуют срочных расходов на продвижение и скидки, снижающих маржинальность.
Как технологии помогают:

• прогнозы скорости продаж по дням
• автоматические кампании для привлечения внимания аудитории
• предварительные продажи для постоянных зрителей через работу с базой

2.3. Возвраты Потеря: возвраты создают кассовые разрывы, дополнительные расходы и репутационные риски.
Как технологии помогают:

• автоматизация обработки возвратов с прозрачными правилами
• прогнозирование процента возвратов для формирования резерва
• интеграция с билетными системами для быстрых возвратов и обменов

2.4. Отсутствие базы зрителей Потеря: организатор каждый раз «покупает» аудиторию заново у билетных платформ и рекламных каналов.
Как технологии помогают:

• сбор данных о зрителе через единую систему
• сегментация аудитории по интересам, истории покупок и поведению
• автоматические коммуникации с персональными предложениями
• анализ повторных покупок и пожизненной ценности зрителя (LTV)

2.5. Потерянная выручка от дополнительных услуг Потеря: на многих событиях выручка от питания, напитков и мерча остаётся неучтённой и неуправляемой.
Как технологии помогают:

• системы безналичной оплаты с аналитикой чеков
• предварительные заказы через приложение
• объединение дополнительных продаж с билетной системой в единый отчёт

3. Какие ИТ-продукты для событий уже стали стандартом

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

3.2. Системы анализа продаж и прогнозирования Организатор должен видеть динамику продаж не постфактум, а в реальном времени.
Что должна делать система: показывать скорость продаж, прогнозировать заполняемость, определять эффективные каналы продвижения, рассчитывать стоимость привлечения зрителя (CAC) и окупаемость.
Кому нужно: организаторам, билетным сервисам, площадкам, маркетологам.

3.3. Системы управления турами Тур — это совокупность городов, каждый из которых нужно оценивать отдельно.
Что должна делать система: оценивать потенциальный спрос в каждом городе, прогнозировать продажи, считать логистические расходы и их влияние на прибыль, показывать рентабельность по городам.
Кому нужно: артистам, управляющим артистов, организаторам туров.

3.4. Системы управления доходами от дополнительных продаж Выручка от питания, напитков и мерча может достигать 30% от общей выручки события.
Что должна делать система: отслеживать продажи в реальном времени, показывать средний чек по зонам, сравнивать дополнительную выручку с билетной, прогнозировать доход на основе количества зрителей.
Кому нужно: площадкам, организаторам фестивалей, операторам питания.

3.5. Интеграция с билетными системами Билетная система — это источник данных о зрителе, каналах продвижения и спросе.
Что должна делать интеграция: передавать данные о покупателе в базу организатора, показывать каналы привлечения, предоставлять отчётность по возвратам и комиссиям, давать доступ к аналитике, а не только к кассовым данным.
Кому нужно: всем участникам рынка, которые хотят управлять данными самостоятельно.

4. Искусственный интеллект в событийной индустрии: что уже работает

4.1. Прогнозирование спроса Нейросети анализируют исторические данные, сезонность, конкурентное окружение и другие факторы, чтобы предсказать динамику продаж. Это позволяет вовремя заметить риск неполной заполняемости и скорректировать продвижение.

4.2. Гибкое ценообразование Цена билета может динамически меняться в зависимости от спроса, времени до события и других параметров. Системы гибкого ценообразования помогают извлечь максимум выручки с каждого места.

4.3. Автоматическое создание контента Нейросети генерируют описания событий для витрин, соцсетей и рассылок. Пример: МТС Live внедрил нейросеть для создания описаний мероприятий — по данным CNews, подготовка занимает около 5 минут вместо 15–30 у копирайтера.

4.4. Персональные рекомендации На основе истории покупок система рекомендует зрителю похожие события, повышая повторные продажи без дополнительных затрат на продвижение.

4.5. Защита от подделок и серых продаж Нейросети анализируют покупки на предмет подозрительной активности, выявляют серые перепродажи и поддельные билеты, защищая выручку и репутацию организатора.

5. С чего начать цифровизацию: пошаговый план

Цифровизация — это не разовая покупка программы, а последовательный процесс.

Шаг 1. Начать собирать данные о зрителе

• настроить сбор контактов при продаже билетов
• фиксировать явку
• учитывать дополнительные покупки

Шаг 2. Перестать отдавать данные билетным платформам

• настроить обмен с билетной системой так, чтобы данные оставались у организатора
• использовать промокоды и UTM-метки для атрибуции каналов

Шаг 3. Настроить отчётность о доходах и расходах до запуска события

• строить прогноз продаж по дням
• рассчитывать минимальную заполняемость для окупаемости
• закладывать резерв на возвраты и непредвиденные расходы

Шаг 4. Начать использовать прогнозы и аналитику

• отслеживать скорость продаж в реальном времени
• сравнивать прогноз с фактом
• корректировать продвижение при риске неполной заполняемости

Шаг 5. Настроить повторные продажи

• сегментировать базу зрителей
• запустить автоматические сценарии коммуникаций
• измерять долю повторных покупок

6. Что будет через 2–3 года: три сценария

В исследовании АЙТИФОКС выделены три сценария развития событийной индустрии до 2028 года.

Базовый сценарий Рынок умеренно растёт в деньгах, но прибыль под давлением. В выигрыше — крупные организаторы, сильные площадки и билетные платформы, владеющие данными и технологиями. Компании без автоматизации постепенно сдают позиции.

Оптимистичный сценарий Рост поддерживают крупные концерты, фестивали, туризм и премиальный сегмент. Технологии становятся отраслевым стандартом. Победители — те, кто управляет полной ценностью зрителя.

Стрессовый сценарий Аудитория экономит, продажи смещаются к дате события, расходы растут. Выживают игроки с низкой точкой окупаемости и собственной базой зрителей. Слабые события отменяются.

Прогноз: независимо от сценария, технологически оснащённые компании будут в выигрыше. Организации без данных, прогнозов и автоматизации продолжат терять прибыль и долю рынка.

Заключение

Цифровизация событийной индустрии — это инструмент управления прибылью.

Рынок концертов вырос на 28%, но это рост за счёт цены, а не аудитории. Продажи в штуках не вернулись к допандемийному уровню. Конкуренция усиливается, зритель становится избирательнее, маржинальность сжимается.

В этих условиях ИТ-продукты становятся главным инструментом управления:

• база зрителей позволяет не покупать аудиторию заново
• анализ продаж показывает точки потерь
• прогнозы помогают выявить риски за 2–3 недели до события
• автоматизация повышает повторные продажи и снижает издержки

АЙТИФОКС разрабатывает ИТ-продукты для событийной индустрии, которые помогают организаторам, площадкам и билетным сервисам управлять данными, прогнозировать продажи и считать реальную прибыльность каждого события.

Мы не просто создаём программы. Мы помогаем увидеть, где теряются деньги, и закрыть эти потери.

Материал подготовлен на основе исследования концертной индустрии 2025–2026, проведённого АЙТИФОКС. В исследовании: карта потерь, шаблоны доходов и расходов для концерта, фестиваля и тура, чек-лист подготовки к запуску события, оценка зрелости организатора. Текст исследования будет опубликован в телеграм-канале https://t.me/CEOItFox, следите за новостями.

С 1 марта 2026 года в России вступили в силу новые правила об ограничении иностранных слов. Штрафы — штука неприятная. Но ещё неприятнее — перспектива вручную вычитывать 103 страницы. На сотой странице глаз замыливается, внимание рассеивается — и ошибка гарантированно уходит в продакшен.

Мы решили не нанимать подрядчиков, а сделать свой инструмент. Задача: быстро, без внешних специалистов и платных лицензий, собрать систему, которая сама обходит сайт, выискивает запрещённые слова, проверяет орфографию и грамматику, и присылает готовый отчёт. Не разовую акцию, а живой конвейер.

С чего всё началось: мёртвая зона на живом сайте

Изначально всё выглядело проще. Мы пришли к тестировщикам с запросом: проверьте сайт на заимствования в связи с новым законом. Только иностранные слова, ничего больше. Разово.

Тестировщики выгрузили текст, прогнали через сервисы — готово. Но почти сразу мы вернулись с новыми вводными: проверять ещё орфографию, грамматику, пробелы, интервалы, знаки препинания. И главное — не разово, а постоянно. Чтобы система работала сама по расписанию.

Тестировщик сел за ресёрч, выбрал связку Python + бесплатный LanguageTool, написал сценарий. Запустили — и упёрлись в стену.

Сценарий нашёл только 30 страниц из 103.

Мы полезли разбираться. Оказалось, часть страниц открывалась только по клику в браузере, а не по прямой ссылке. Пока пользователь не кликнет на кнопку — страницы не существует. Для обычного посетителя это нормально: пришёл, кликнул, увидел. Но для робота — поискового или нашего собственного — это мёртвая зона. Робот не умеет кликать, он переходит по ссылкам. А раз ссылки нет — нет и страницы.

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

Как устроен конвейер ИИ-проверки

Этап 1. Обход и сбор данных. Сценарий берёт карту сайта и методично обходит каждый адрес. Вытягивает весь текст: заголовки, подзаголовки, основной текст, подписи. На выходе — массив данных, привязанный к адресам страниц. Человек может забыть страницу или пропустить абзац — сценарий нет.

Этап 2. Смысловой анализ. Собранный текст отправляется в LanguageTool. Это не просто спеллчекер — нейросетевой агент и лингвистическая база анализируют построение предложений, понимают контекст и могут сказать: «Вот эту фразу стоит переформулировать». Сервис работает на русском, английском и десятках других языков.

Не всё пошло гладко с первого раза. LanguageTool ругался на заголовки без точек в конце — а у нас это стандарт вёрстки. Добавили правило-исключение. Первая версия отчёта была неудобной — слова выдавались списком без привязки к страницам. Доработали: сделали страницу с аналитикой, где видно, какое слово на какой странице, сколько всего уникальных заимствований, какие ошибки повторяются. Добавили белый список разрешённых слов — если завтра появится новый список, мы просто добавим его, и система перестанет на них ругаться.

Этап 3. Человеческая проверка. Мы не обещаем 100% точности — это технологически невозможно. Система иногда ошибается: может пропустить ошибку, может отметить правильное слово как неправильное. Поэтому в конвейере есть страховочный пояс — человек. Он открывает готовый отчёт и просматривает находки. Разница с ручной вычиткой колоссальная: раньше нужно было открыть каждую из 103 страниц и прочитать целиком. Теперь — просмотреть список конкретных находок и точечно принять решение.

Этап 4. Регулярность и отчётность. Сейчас мы закладываем встройку в серверную часть. Раз в месяц фоновая задача будет автоматически обходить сайт и присылать отчёт ответственному сотруднику. Никаких напоминаний, ручного запуска, забытых проверок.

Создание кода с помощью ИИ: быстро, но с особенностями

Весь сценарий написан с использованием генерации кода через ИИ. Тестировщик описывал логику — нейросеть генерировала код. За счёт этого прототип собрали за день. Автоматизация разработки позволила не отвлекать серверную команду на раннем этапе.

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

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

Что получилось

103 страницы за 10 минут. Наши авторы внутренне готовились к неделям ручной вычитки, а получили готовый отчёт. Точность и полнота проверки оказались значительно выше ожиданий.

Попутно починили видимость сайта для поисковиков. Материалы, которые годами не индексировались, снова доступны.

Отдельно про бюджет: весь проект сделан на бесплатных инструментах. LanguageTool — бесплатный, Python — открытый язык, генерация кода через нейросеть — тоже без дополнительных затрат. При нашем объёме страниц бесплатной версии хватает. Мы принципиально хотели проверить: можно ли решить задачу без платных лицензий и внешних подрядчиков. Оказалось — можно. Весь проект реализован силами одного тестировщика за день.

Перспективы

Механика не привязана к заимствованиям или конкретному рынку. Та же связка «обход сайта + лингвистический анализ + отчёт» работает для наблюдения за терминологией бренда, требованиями поисковиков, обновлением контента после смены названия компании. LanguageTool поддерживает десятки языков — инструмент можно приспособить под законы любой страны.

Нужна ИИ-проверка сайта, чтобы не платить штрафы и не вычитывать страницы вручную?

Мы соберём инструмент за 1 день — от гипотезы до работающего отчёта. Вот как мы работаем, когда задача оказывается сложнее, чем казалось:

● Не обещаем 100% точности — встраиваем проверку человеком и белые списки.

● Слышим боль бизнеса: штрафы, невидимые материалы, тонны рутины.

● Уменьшение человеческого фактора — наша цель, а не просто слова.

● Используем генерацию кода с помощью ИИ для быстрой разработки прототипа.

● Попутно проверяем техническое здоровье сайта — такого подарка от ручной проверки не дождёшься.

Пишите — обсудим вашу задачу 🤍

Ещё года три-четыре назад словосочетание «искусственный интеллект для интернет-магазина» звучало как что-то из арсенала гигантов вроде Amazon или Wildberries. Дорогие технологии, сложное внедрение, туманные перспективы — казалось, что всё это не для среднего бизнеса. Компании экспериментировали, запускали пилоты, но до реальной отдачи дело доходило редко.

Ситуация перевернулась.

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

Где ИИ на самом деле спасает бюджет

Обычно когда говорят про нейросети в торговле, вспоминают про чат-ботов, подборки «с этим также покупают» или генерацию картинок. Но самый мощный финансовый эффект спрятан глубже — внутри товарного каталога.

Это та самая точка, где бизнес незаметно для себя сливает деньги пачками.

Маркетинг считает стоимость лида, логистика отлаживает цепочки поставок, а в это время в карточках товаров зреет хаос:

● половина характеристик не заполнена;

● параметры перепутаны местами;

● фотографии отсутствуют;

● фильтры на сайте выдают ерунду;

● часть ассортимента просто выпадает из поиска.

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

Почему ручное наполнение — это убыток

Многие до сих пор воспринимают карточку товара как второстепенную задачу: «потом доделаем», «скопируем у поставщика», «менеджер на коленке дополнит».

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

Итог: компания теряет деньги ещё до того, как покупатель увидел ценник.

Привычная схема работы с каталогом выглядит так:

● люди вручную ищут информацию;

● подрядчики пишут тексты;

● редакторы проверяют ошибки;

● загрузка идёт с опозданием;

● косяки всплывают уже после публикации.

Цена одной карточки при таком подходе легко доходит до 500–2000 рублей. Умножьте на 100–200 тысяч товаров — и получите бюджет, сопоставимый с годовым фондом оплаты труда целого отдела.

Как ИИ переворачивает экономику каталога

Важно не путать: ИИ для интернет-магазина — это не просто модный генератор текстов.

Современное решение — это конвейер.

Сначала парсеры собирают информацию из открытых источников: порталы производителей, базы поставщиков, витрины маркетплейсов, нишевые справочники. Затем большая языковая модель берёт на себя анализ: сверяет данные, чистит противоречия, приводит характеристики к единому формату и пишет уникальное описание под стилистику бренда. После этого система сама отправляет готовую карточку на сайт или в учётную программу.

В этом и есть разница между «поиграться с нейросетью» и настоящим внедрением ИИ в бизнес-процессы.

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

Два провала автоматизации: на чём спотыкаются проекты

Самое интересное, что косяки обычно связаны не с технологиями, а с тем, как бизнес ставит задачу.

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

Вторая беда — имитация автоматизации.

Если менеджер всё равно жмёт кнопку «сгенерировать», копирует результат в карточку и проверяет каждый пункт — вы не роботизировали процесс, а просто подкинули сотрудникам ещё одну софтину. Настоящая автоматизация выглядит иначе: товар возник → данные подтянулись → карточка создалась → опубликовалась. Без человека в цепочке.

Кейс «УютСтрой»: путь от 2000 до 1 рубля

Показательный пример — крымская сеть гипермаркетов «УютСтрой».

Четыре торговых объекта общей площадью больше 82 000 квадратных метров и онлайн-витрина на 180 000 позиций. До автоматизации компания тратила колоссальные ресурсы на контент: подрядчики, штатные авторы, ручная вычитка характеристик. Цена одной карточки достигала 2000 рублей.

После запуска ИИ-системы всё поменялось.

Что сделали:

● настроили автоматический сбор данных из открытых источников;

● подключили нейросеть для генерации уникальных описаний;

● внедрили нормализацию характеристик;

● карточки начали публиковаться сами;

● связали всё с 1С через микросервисы.

Результат:

● стоимость карточки упала примерно до 1 рубля;

● срок публикации сократился с нескольких дней до минут;

● ошибки в фильтрах почти исчезли;

● рост каталога больше не требует расширять штат контент-менеджеров.

Ключевой итог: бизнес перестал наращивать ручной труд пропорционально ассортименту.

С чего стартовать

Внедрение ИИ — это не покупка волшебной кнопки. Это прежде всего пересборка процессов.

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

Поэтому любой проект стартует с аудита текущих процессов. Только после этого можно подбирать формат автоматизации.

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

Главная цель — не «ИИ ради галочки», а устранение ручного труда, ускорение публикации и здоровая экономика интернет-магазина.

В АЙТИФОКС мы делаем сложные штуки: финтех, ИИ, высоконагруженные системы. Шесть лет на рынке, больше шестидесяти человек в штате, проекты, которыми гордимся.

Но есть проекты, о которых молчишь не потому, что нечем гордиться — наоборот. Потому что NDA, жёсткий контракт, стратегический заказчик.

Этот кейс два года лежал под замком. Теперь можно рассказать. И это, пожалуй, самая суровая история из тех, что с нами случались.

С чем мы зашли

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

Формально нас позвали «на поддержку и развитие». Звучало как плановая работа: поддержка, доработки, развитие.

А по факту — реанимация.

До нас над реестром работали две команды подряд. Обе не справились. И вот нам передают проект с формулировкой «посмотрите, что можно сделать». А через полтора месяца — ключевое отраслевое мероприятие. Продукт обязан работать и презентовать новую аналитику.

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

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

В каком состоянии мы получили проект

Первые две недели ушли просто на ресёрч. Картина вскрылась жёсткая.

Все роуты были построены по единому «сверхжадному» шаблону на самописном фреймворке. Чтобы показать карточку компании, запрос тянул вообще всё: команду, аккаунты, историю сделок, контракты. Гигантский объём нерелевантных данных. Плюс Elasticsearch был настроен неоптимально и добавлял к загрузке ещё 5+ секунд. Ключевые страницы грузились по 20–60 секунд. Не миллисекунд — секунд.

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

Инфраструктуры как класса не существовало. Тестового контура нет. Деплой ручной. Sentry не подключён. Логи не собираются. Линтеры и чекеры кода не используются.

Ключевой сотрудник предыдущей команды то «болел», то «ничего не знал». Нам не передали ни знаний об архитектуре, ни логики принятых решений. Единственное, что мы получили — медленный, нестабильный код и критику заказчика в адрес предыдущих разработчиков.

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

Как мы дважды могли провалиться, но не провалились

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

Второй риск — более коварный. Начать латать старый код. Симптомы были как на ладони: медленные запросы, падающие интеграции. Исправить «по верхам» и сдать как «поддержку»? Но мы понимали: проблема не в багах, а в архитектуре. Латание означало бы отсрочку на пару месяцев, после которой всё посыпалось бы снова.

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

Что сделали

Разбили работу на три этапа.

Этап 1. Тактическая стабилизация и проектно-образовательный интенсив.

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

Этап 2. Пересборка архитектуры (около года)

Править старые запросы было бессмысленно — логика связей слишком глубоко зашита в самописном фреймворке. Мы переписали все критические роуты в новую версию API (v2) с нуля, используя паттерн «сервис-репозиторий». Каждый роут теперь запрашивал только те данные, которые реально нужны фронту. Результат: загрузка сократилась с 20–60 секунд до 200–500 миллисекунд. В 50 и более раз.

Отказались от Elasticsearch для пользовательского поиска. Внедрили полнотекстовый поиск на базе самого PostgreSQL — убрали 5-секундную задержку и упростили архитектуру. Elasticsearch оставили только в админке, где его использование оправдано.

Для нормализации хаоса с внешними сервисами внедрили собственную шину данных на Kafka. Любое взаимодействие — отправка данных, запрос статусов, получение описаний — теперь проходит через контролируемый контур. Шина записывает все сообщения в БД, фиксирует статусы и ошибки. Впервые интеграции стали прозрачными.

Полностью переписали обмен с ключевыми внешними системами: SOAP и REST API, CRM, внешние шины проектов. Настроили полные циклы обмена, валидацию по справочникам, обработку коллизий — например, когда сервер возвращает 500 ошибку, но данные при этом записывает.

Подняли тестовый контур и связали его с тестовыми средами внешних систем. Внедрили Sentry и логирование. Настроили автоматический деплой и alembic для миграций БД.

Отдельная история — отчётность. После многократных доработок мы изучили все нормативные требования заказчика и создали собственные шаблоны, которые утвердили раз и навсегда. Проблема формальных правок исчезла.

Этап 3. От стабильности к интеллектуальному поиску

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

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

Мы написали скрапер, который обошёл сайты компаний и собрал актуальные данные по 98 000 профилей. Выстроили многоуровневую очистку: TF-IDF для удаления дублей, фильтрация технического мусора, унификация структуры. Очищенные данные перевели в векторное представление через YandexGPT PRO и сохранили в ChromaDB. Внедрили поиск на базе RAG — модель ищет ответ не в своей «памяти», а в актуальных данных платформы.

Результат: доля отказов снизилась на 24%, конверсия выросла на 18%. Поиск начал реально понимать пользователя.

Что получилось

Два года назад нам передали проект, который не грузился, не интегрировался и не имел документации. Сегодня:

✅ Загрузка страниц — 200–500 миллисекунд вместо 20–60 секунд. В 50 и более раз быстрее.

✅ Интеграции работают и логируются через шину данных. Ошибки не теряются, статусы отслеживаются.

✅ Отчётность сдаётся по утверждённым шаблонам без доработок.

✅ ИИ-поиск понимает инвестиционные запросы: доля отказов −24%, конверсия +18%.

✅ Заказчик, дважды обжигавшийся на других командах, работает с нами до сих пор.

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

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

Что мы вынесли из этой истории

Главное — не относитесь к legacy как к приговору. Две команды до вас провалились? Архитектура заложена с ошибками? Документации нет, а дедлайн вчера? Это не повод опускать руки. Это повод включить голову и действовать системно: сначала стабилизировать, потом пересобрать фундамент, потом развивать.

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

Иногда надо просто взять и сделать. Выделить команду, защитить её от дёрганий, поставить жёсткий срок — и довести до ума. Даже если проект выглядит безнадёжным.

📎 Ссылка на полный разбор кейса — https://itfox-web.ru/ru/cases/dva-goda-i-60-sekund-zagruzki-stali-200-ms-poteria-dannykh-prozrachnoi?utm_source=teletype&utm_medium=blog&utm_campaign=content_2026&utm_content=article

Там честно про архитектуру, Kafka, интеграции и ИИ-поиск.

👇 Приходилось вам принимать проекты после других команд? Как справлялись?

Мы в АЙТИФОКС часто слышим фразу «обновите сайт». Но за ней редко стоит просто косметика. Этот кейс — история о том, как запрос на обновление обернулся пересборкой архитектуры, и почему это спасло бизнес от коллапса при масштабировании.

Три ресторана, и сайт дал трещину

Фри Тайм — сеть из трёх ресторанов в Благовещенске. Бургеры, роллы и локальный хит — корейский суп Куксу. Аудитория от 18 до 45 лет, высокая лояльность в городе. Бизнес стабильно рос и планировал открывать новые точки. Но сайт, построенный когда-то на PHP/Laravel, к такому росту оказался не готов.

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

Люди бросали корзины и звонили диспетчерам. Нагрузка на персонал росла, средний чек стоял на месте. А главное — открытие четвёртой точки на такой архитектуре означало бы полный коллапс.

Не косметика, а пересборка фундамента

Мы могли бы подлатать старый код. Подкрутить фильтры, поправить вёрстку, сдать проект и забыть. Но проблема была не в багах. Она была в архитектуре, которая проектировалась без запаса на рост. Исправление симптомов обошлось бы дороже и не решило бы задачу масштабирования.

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

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

Но и это не всё. Мы встроили механики, которые напрямую влияют на выручку:

- Кастомизация блюд: добавить ингредиент за доплату.

- Перекрёстные продажи в корзине: к бургерам — соусы, к суши — закуски.

Всё это настраивается там же, в админке. Без программиста. Плюс гибкие зоны доставки полигонами на Яндекс.Картах вместо фиксированного радиуса — стоимость зависит от удалённости, условия бесплатной доставки управляются в пару кликов.

Два месяца и новый стек под капотом

Технически мы пересобрали всё на Python/Django для бэкенда и Next.js для адаптивного фронтенда. Интегрировали ЮKassa для приёма оплат и Яндекс.Карты для зон доставки. Срок разработки — 2 месяца.

Главная сложность была в правильном разделении данных между независимыми точками. Спроектировать модель так, чтобы добавление N-го ресторана не требовало изменений в коде — только заполнение полей в админке. Мы это сделали.

Что в итоге изменилось для бизнеса

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

И самое важное — архитектура готова к любому количеству точек. 3 → N ресторанов без доработок кода. Четвёртая точка теперь — вопрос «куда ставить стулья», а не «выдержит ли сайт».

Подробнее о кейсе читайте тут: https://itfox-web.ru/ru/cases/2-mesiatsa-raboty-i-sait-perestal-byt-butylochnym-gorlyshkom-a-stal-ko?utm_source=teletype&utm_medium=blog&utm_campaign=freetime_case_2026&utm_content=article

Главный вывод для тех, кто узнал себя

Запрос «обновить сайт» часто маскирует более глубокую проблему — архитектура не готова к росту бизнеса. Иногда косметика не поможет. Нужно пересобирать фундамент. И делать это не на бегу между клиентскими задачами, а системно — с правильным проектированием и запасом прочности на будущее.

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

Пока ты делаешь крутые проекты для клиентов, собственная витрина тихо устаревает. Сначала это незаметно. Потом становится неловко. А потом ты понимаешь, что сайт уже откровенно врёт о том, кто ты есть на самом деле.

У нас в АЙТИФОКС эта история тянулась годами. И сегодня я расскажу её без прикрас.

Обещаю, будет знакомо

Мы занимаемся сложной разработкой. Финтех, ИИ, высоконагруженные системы, реверс-инжиниринг железа без документации. Шесть лет на рынке, больше шестидесяти человек в штате, проекты по всему миру.

А сайт… Сайт начинался когда-то как простой лендинг на скорую руку. Ну знаете, как это бывает: «давай быстро сделаем одностраничник, а потом нормальный сайт». Потом мы добавляли туда страницы под новые услуги. Потом прикручивали раздел с кейсами. Потом пытались рассказать про нашу ИИ-экспертизу.

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

Но самое неприятное было в другом. Клиент заходил на сайт и видел не зрелую ИТ-компанию с системными процессами, а «очередную студию». В B2B это смертельно. Первое касание либо продаёт, либо хоронит сделку. Наш сайт, откровенно говоря, скорее хоронил.

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

Две попытки, два провала

Мы не сидели сложа руки всё это время. Дважды брались за обновление и оба раза наступали на одни и те же грабли.

Первая попытка была классической. Нашли внешнее агентство, вместе выбрали CMS, согласовали структуру. Думали, сейчас всё сделают быстро и красиво, мы только контент подвезём. Через два месяца стало очевидно: результат будет далёк от ожиданий. Код чужой, логика чужая, любая нестандартная хотелка ломает вёрстку или требует танцев с бубном. Мы поняли, что теряем контроль над собственным сайтом. Скупой платит дважды — пришлось остановиться, признать ошибку и начать с нуля.

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

На практике это был ад. Как только прилетал срочный проект от клиента, людей дёргали. Контекст терялся. Через пару недель приходилось заново вникать, читать документацию, вспоминать договорённости. Проект превратился в бесконечный марафон с препятствиями, где финиш всё время отодвигался. Месяцы шли, результата не было.

Вывод простой и неудобный: внутренний проект в сервисной компании всегда проигрывает оплачиваемому. Всегда. Пока вы не признаете это и не защитите его организационно.

Что мы изменили в третьей попытке

В какой-то момент мы просто перестали относиться к сайту как к «внутренней задачке на подхвате». Сказали себе: это такой же продукт, как для самого важного клиента. Со своей командой, бюджетом и жёстким дедлайном.

Собрали отдельную команду. Бэкенд на Python, фронт на React, сильный дизайнер, который отвечал за визуальную систему целиком, а не за отдельные экраны. Тестировщик и отдельный PM, который держал сроки и отбивался от попыток дёрнуть людей на другие проекты.

Каждое утро начиналось с короткого созвона. Что сделали вчера, что мешает сегодня, куда движемся завтра. Никаких потерянных недель и забытых договорённостей.

От готовых CMS отказались наотрез. Сделали кастомную разработку с нуля. Да, это дольше и дороже на старте. Но это даёт полный контроль над кодом и логикой. А главное — мы сразу закладывали архитектуру под масштабирование. Новые кейсы, направления, разделы должны добавляться без боли и пересборки всего продукта.

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

Ещё мы отказались от модного дизайна а-ля «онлайн-журнал» с огромными заголовками и бесконечными лентами. Серьёзно, такие сайты сейчас у каждой второй студии. Они выглядят дорого, но все на одно лицо. Мы сделали чисто, структурно, с акцентами на сути. Пусть запоминается содержание, а не очередной тренд, который устареет через полгода.

Что в итоге

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

И вот что изменилось после запуска.

Сайт наконец-то отражает реальный уровень компании. Клиент заходит и видит не «очередную студию», а зрелую команду, которая делает сложные вещи. Это чувствуется в подаче, в структуре, в деталях.

Входящие лиды качественно изменились. Раньше мы получали много запросов уровня «сделайте лендинг» или «сколько стоит приложение». Теперь приходят с запросами на кастомную разработку, автоматизацию, ИИ-интеграции. Сайт сам отсеивает нецелевых и работает как первый этап квалификации. Это экономит время и нашим менеджерам, и клиентам.

Новые кейсы добавляются за минуты. Никаких «найди разработчика» и «подожди недельку». Контент-менеджер справляется сам. Архитектура спокойно выдерживает рост.

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

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

Главный вывод для тех, кто узнал себя

Не относитесь к своему сайту как к чему-то второстепенному. Пока он стоит в очереди «на потом», он так и будет работать против вас. Чем дольше тянете, тем дороже и больнее в итоге.

Внутренний проект без чёткого фокуса обречён. Он всегда будет проигрывать клиентским задачам, если не защитить его организационно. Выделите людей, бюджет, поставьте жёсткий срок и доведите до ума.

Иногда надо просто взять и сделать.

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

Сначала система помогает бизнесу расти, потом стабилизируется, а затем начинает тормозить развитие. Не потому что она плохая, а потому что её архитектура создавалась под другие задачи.

Мы столкнулись с этим в проекте с билетным ядром.

Компания много лет работала на стабильной системе на Java. Через неё проходило всё: события, залы, места, бронирования, статусы — фактически вся логика продаж. Система была надёжной и проверенной временем, и именно поэтому её нельзя было трогать.

Снаружи при этом всё выглядело нормально. Продажи шли, продукты работали, команда развивала новые сервисы. Но внутри постепенно становилось заметно, что развитие начинает упираться в ограничения.

Появлялись мобильные приложения, веб-интерфейсы, интеграции с партнёрами. И каждый раз команда сталкивалась с одной и той же проблемой: ядро умело работать только с Java.

Это означало, что любой новый продукт либо нужно писать на Java, либо искать обходные пути. Разработка дорожала, сроки росли, а часть идей становилась невыгодной ещё до старта.

Когда продуктов становится много, такие ограничения начинают напрямую влиять на бизнес. Скорость запуска падает, а стоимость разработки растёт быстрее, чем ожидается.

Именно в этот момент стало понятно, что проблема не в отдельных сервисах.

Где на самом деле была проблема

На первый взгляд кажется, что дело в технологии. В Java, в старом коде, в легаси.

Но довольно быстро стало понятно: дело не в этом.

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

То есть ограничение было архитектурным.

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

Нужно было решение, которое позволит развивать продукты, не трогая основу.

Когда решение — не переписывать

Мы отказались от идеи переписывания почти сразу.

Вместо этого решили изменить не систему, а способ взаимодействия с ней.

Так появился Proxy API — отдельный слой, который стал точкой входа в билетное ядро. Внутри он работает на Java и учитывает все ограничения legacy-системы, а наружу отдаёт уже современный gRPC API.

По сути, мы разделили старый и новый мир.

Ядро осталось как есть. Всё развитие вынесли наружу.

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

Когда начинаются реальные сложности

На практике всё оказалось сложнее, чем выглядело на старте.

У системы почти не было документации. Чтобы понять, как она работает, пришлось разбирать код и реальные сценарии. Мы по сути заново собирали архитектуру, чтобы не нарушить существующую логику.

Параллельно выяснилось, что объёмы данных значительно выше, чем ожидалось.

В отдельных сценариях один запрос мог обрабатывать сотни тысяч сущностей и доходить до 200–300 МБ. И это была нормальная рабочая нагрузка.

Если просто прокинуть такие данные через новый слой, система начнёт тормозить и создавать дополнительную нагрузку на ядро.

Поэтому Proxy API изначально проектировали как highload-решение. Данные обрабатывались поэтапно, лишние операции убирались, а промежуточные результаты выносились во внешнее быстрое хранилище.

Это позволило не превратить прокси в узкое место и сохранить стабильность всей системы.

Когда система перестаёт быть ограничением

После внедрения Proxy API ситуация изменилась довольно быстро.

Команда перестала зависеть от Java как единственного варианта. Под новые задачи можно было выбирать подходящий стек, а не подстраиваться под ограничения ядра.

Запуск продуктов ускорился, интеграции с внешними сервисами стали безопасными и управляемыми, а развитие перестало упираться в архитектуру, созданную много лет назад.

При этом сама core-система осталась неизменной и продолжила работать так же стабильно, как и раньше.

Результат

Мы не переписывали систему и не ломали существующую архитектуру. Вместо этого добавили слой, который снял главное ограничение — закрытость ядра.

В результате бизнес получил возможность развивать продукты быстрее и дешевле, без риска для стабильности core-системы.

Иногда, чтобы ускорить развитие, не нужно менять основу. Достаточно правильно выстроить то, что находится вокруг неё.

📌 Полный кейс с архитектурой и деталями решения: https://itfox-web.ru/ru/cases/razrabotali-proxy-api-dlia-biletnogo-iadra-sniali-zavisimost-ot-java-i?utm_source=teletype&utm_medium=article&utm_campaign=case_proxy_api

Команда может быть полностью укомплектована, проектов много, разработчики постоянно заняты — но прибыль при этом растёт гораздо медленнее, чем ожидается.

Мы столкнулись с этим, когда компания выросла до нескольких десятков сотрудников и десятков параллельных проектов. Снаружи всё выглядело нормально: проекты шли, задачи закрывались, команда работала. Но внутри постепенно становилось заметно, что экономика проектов начинает вести себя непредсказуемо.

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

Соединить всё это и понять реальную рентабельность IT-проекта было сложно. Внешне проект мог выглядеть успешным, но внутри постепенно уходить в минус из-за переработок или простоев.

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

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

Начали с простой диаграммы Ганта

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

Менеджеры получили возможность видеть, кто свободен, кто перегружен и как распределены проекты между специалистами. Это сразу упростило планирование команды разработки и помогло быстрее подключать людей к задачам.

Но довольно быстро стало понятно, что одного планирования недостаточно.

Когда компания растёт, важно понимать не только то, как распределены люди по проектам, но и то, как эта загрузка влияет на деньги. План без факта не даёт полной картины. А план без финансов иногда вообще вводит бизнес в заблуждение.

Когда прототип перестаёт быть прототипом

Первая версия системы была собрана на Firebase. Это позволило быстро проверить идею и начать пользоваться инструментом без сложной инфраструктуры.

Но по мере роста компании ограничения начали становиться заметными. Данных становилось больше, появлялись новые сценарии работы, а финансовая аналитика уже не помещалась в первоначальную архитектуру.

В какой-то момент стало ясно, что система перестала быть просто удобным инструментом планирования. На неё начали опираться управленческие решения. А значит, ей нужна более серьёзная архитектура.

Мы решили не менять интерфейс и не ломать привычный процесс работы команды. Вместо этого перенесли систему на собственный сервер и начали развивать её как полноценную систему управления проектами и ресурсами.

Когда план, факт и деньги оказываются в одной системе

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

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

Постепенно инструмент перестал быть просто системой планирования. Он превратился в часть управления компанией.

Результат

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

Мы не увеличивали продажи и не сокращали команду. Изменилось другое — стало намного понятнее, как именно распределение ресурсов влияет на экономику проектов.

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

📌 Мы подробно разобрали этот кейс — от Excel-таблиц до полноценной системы управления ресурсами — в отдельном кейсе.

В нем рассказываем, как внутренняя система планирования выросла в платформу управления проектами и почему контроль загрузки сотрудников напрямую влияет на рентабельность разработки.

Читать полный кейс: https://itfox-web.ru/ru/cases/razrabotali-sistemu-upravleniia-zagruzkoi-i-finansami-obedinivshuiu-pl?utm_source=teletype&utm_medium=blog&utm_campaign=content_2026&utm_content=article