ItFox Web

Смена подрядчика: как не потерять продукт

2026-10-22T07:04:26.169Z

Или история о том, как бизнес получает работающую систему, которой не может управлять.

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

Знакомая картина? Мы собрали опыт технического директора, менеджера проектов и специалиста по тестированию АЙТИФОКС — людей, которые принимали IT-продукты у предыдущих команд и видели, где обычно рвётся.

Что разобрали в статье

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

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

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

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

Как выстроить приёмку, чтобы отчётность не съедала спринт. С примером из проекта, где на приведение документов к требованиям ГОСТ ушло около 4–5 дней, а после двух спринтов переделок стало меньше.

Отдельный интересный момент

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

Что в итоге

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

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

Полный текст — на сайте: https://itfox-web.ru/ru/blog/kak-smenit-podriadchika-po-razrabotke-i-ne-poteriat-kontrol-nad-it-pro?utm_source=teletype&utm_medium=article&utm_campaign=change_contractor_2026

Фальшивые билеты и VIP-зоны без контроля: как мы сделали СКУД для стадиона на 45 000 мест

2026-10-07T13:08:57.664Z

Или история о том, как офлайн-режим и переход на SQLite + Drift превратили контроль доступа в управляемые потоки.

Представьте: стадион в день матча. Десятки тысяч болельщиков идут к входам. Контролёры вручную проверяют билеты — кто-то пытается пройти по копии, кто-то не на свой сектор. В VIP-зоны набиваются люди, которым там быть не положено. А если человек зашёл и вышел — никто не знает, вернулся он или нет. Старая система медленная, аналитики нет.

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

Что мы сделали

За 4 месяца команда АЙТИФОКС сделала облачную СКУД. Сервер — на Python, приложение — на Flutter: одна кодовая база для телефона и браузера. Сначала MVP, потом тесты на реальной нагрузке. Когда билетов стало 45 000, на устройствах Xiaomi начали зависать клавиатуры, а сервер не справлялся с запросами. Перевели локальное хранилище на SQLite + Drift, ускорили бэкенд.

Самое сложное

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

Первое — объём данных. 45 000 билетов на клиенте, зависания интерфейса на Xiaomi. Перепробовали простые хранилища — не подошли: одни не работают в браузере, другие устарели. Поставили полноценную SQLite с Drift, добавили миграции и индексы.

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

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

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

В нагрузочных тестах система обработала 50 000 билетов и 224 852 прохода за один прогон — это больше реальной вместимости стадиона (45 000) и в 2,5 раза больше, чем даёт один матч. Подтверждённый порог — 200 RPS на тяжёлых операциях, около 40 проходов/с. Ошибок — ноль.

Было: копии билетов проходили, VIP-зоны без контроля, аналитики нет.
Стало: система проверяет билет, зону и повторный проход; контролёр видит всё на экране; работает даже без интернета; данные о потоках — в реальном времени.

Отдельный интересный момент

40 проходов/с для текущего конфига достаточно, но без запаса на пик. На стадионе с плотной пиковой нагрузкой и большим числом турникетов — как «Фишт» с его 108 турникетами на 43 000 мест — нужен другой потолок. Зафиксировали ориентир 140 проходов/с и продолжаем оптимизацию.

Что дальше

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

Полный разбор кейса — с деталями архитектуры, нагрузочными тестами и таблицей результатов — читайте на сайте: https://itfox-web.ru/ru/cases/oblachnaia-skud-dlia-stadiona-krylia-sovetov-kak-my-sdelali-sistemu-ko?utm_source=teletype&utm_medium=article&utm_campaign=skud_case

Концерты собрали 306 млрд — а зрителей больше не стало. Что не так с рынком event и при чём тут автоматизация

2026-09-25T06:46:16.685Z

Вместо вступления: три вопроса, которые нам задают каждый день

Последние месяцы я слышу одно и то же от организаторов, промоутеров и директоров площадок:

«Рынок же растёт? Почему тогда маржа падает?»
«Мы что, уже обязаны внедрять CRM и аналитику? Или можно пока по старинке?»
«Как понять, где именно мы теряем деньги — и сколько стоит это починить?»

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

Поэтому мы сели и разобрали публичные данные, отраслевые публикации и нормативку — без воды, только цифры и реальные примеры. Если вы сомневаетесь, пора ли вам считать экономику зрителя, а не только кассу концерта — этот текст для вас.

Часть 1. Что происходит на рынке на самом деле

В 2025 году рынок офлайн-развлечений достиг 306 млрд ₽ и вырос на 28% год к году. Звучит отлично. Но билетов продали 439 млн штук — всего на 2% больше, чем годом ранее, и на 13% меньше, чем в 2019-м.

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

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

Главный вывод 2025 года: рост рынка ≠ рост эффективности каждого его участника.

Часть 2. 2026-й: единого сценария больше нет

Первые данные 2026 года показывают странную картину. У Ticketland в январе–мае:

— культурный сегмент: оборот на уровне прошлого года, билетов −6%;
— концерты: оборот +2%, билетов −4%;
— фестивали: оборот −4%, билетов −9%.

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

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

Часть 3. Билет — это не вся экономика

Билет — только первая транзакция со зрителем. Дальше вокруг него выстраивается совсем другая модель:

билет → VIP → F&B → мерч → партнёрские интеграции → данные → повторная покупка.

И вопрос уже не «сколько мы собрали на кассе?», а «какова полная ценность зрителя для события и следующих продаж?»

Часть 4. 8 точек, где event-бизнес теряет маржу

Мы выделили основные зоны потерь:

— пустые места;
— поздние продажи;
— неверный выбор города;
— слабая маркетинговая аналитика;
— отсутствие CRM;
— очереди;
— возвраты;
— мошенничество и серый resale.

Показательный пример — пустое место. В отчётности это просто «стоимость непроданного билета». В реальности:

потеря = билет + F&B + мерч + вероятность повторной покупки × маржа + ценность данных.

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

Часть 5. Миф: «нам рано думать об автоматизации»

Многие считают: автоматизация — это для гигантов. На самом деле всё наоборот.

Базовый цифровой контур организатора выглядит так:

P&L события → CRM → UTM-разметка → post-event отчёт → BI продаж.

Это не «нейросети ради нейросетей». Это способ увидеть, где именно вы теряете деньги. Дальше — сегментация, автоматические коммуникации, NPS. И только потом — прогноз спроса, динамическое ценообразование и антифрод.

Правильный вопрос к любому AI-проекту: не «какую нейросеть внедрить?», а «какую потерю в рублях мы хотим сократить и каким KPI докажем эффект?»

Часть 6. Что будет до 2028 года

Мы смотрим на прогноз как на сценарий, а не как на обещание линейного роста. Пять тенденций:

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

Итог: главный принцип

High-load, CRM, аналитика, автоматизация — всё это нужно не тогда, когда вы достигли магического числа. А тогда, когда текущая система перестаёт давать бизнесу расти.

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

И первый вопрос должен звучать не «пора ли нам внедрять AI?», а «где именно сейчас ограничение и какое решение поможет его убрать?»

Мы собрали всё это в одном исследовании — с методологией, расчётными моделями и дорожной картой цифровизации на 12 месяцев.

Читать исследование: https://itfox-web.ru/ru/blog/kontsertnaia-industriia-rossii-v-2025-2026-godakh?utm_source=teletype&utm_medium=article&utm_campaign=event_research

High‑load не для гигантов: когда пора задуматься и сколько это стоит — честный разбор на кейсах

2026-09-11T07:04:01.530Z

Мы не Яндекс, но сайт всё равно тормозит. Что делать?

Вместо вступления: три вопроса, которые нам задают каждый день

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

«Нам точно нужна высоконагруженная архитектура? Мы же не маркетплейс с миллионами посетителей…» «А сколько это будет стоить? Хотя бы примерно, чтобы понять, потянем ли мы» «И как понять, что мы уже “high‑load”, а не просто “чуть‑чуть тормозим”?»

Долгое время я отвечал каждому индивидуально, пока не понял: проблема не в уникальности запросов, а в том, что рынок перенасыщен мифами о high‑load. Одни думают, что это удел гигантов, другие — что достаточно нанять пару разработчиков и всё само заработает.

Поэтому я сел и написал этот текст — без воды, только факты, цифры и реальные примеры из нашей практики в АЙТИФОКС. Если вы сомневаетесь, нужна ли вам сложная архитектура, — эта статья для вас.

Часть 1. Что такое high‑load на самом деле (спойлер: это не про RPS)

Сразу расставим точки над i: универсального значения RPS (запросов в секунду), после которого система автоматически становится высоконагруженной, не существует.

В одном проекте проблемы начинаются при 500 RPS из‑за тяжёлых операций с базой данных, а в другом — при 10 000 RPS всё летает. Поэтому мы в АЙТИФОКС смотрим на совокупность параметров:

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

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

Часть 2. 5 явных признаков, что ваша архитектура уже «на пределе»

Если вы узнаёте хотя бы один пункт из этого списка — пора действовать.

1. Самые важные операции начинают тормозить

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

Пример из практики: Инвестиционная платформа, где страницы грузились по 20–60 секунд. После переработки критичных запросов к БД и API время сократилось до 200–500 мс — ускорение в 50+ раз.

2. Пиковая нагрузка регулярно превращается в ЧП

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

3. Одна тяжёлая операция влияет на всю систему

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

Решения:

разделить операции;
поставить тяжёлые задачи в очередь;
использовать кэширование;
вынести ресурсоёмкие задачи в отдельные сервисы.

4. Объём данных становится проблемой сам по себе

RPS — не единственный показатель. В нашем проекте Proxy API один запрос содержал 200–300 МБ данных и сотни тысяч сущностей. Обрабатывать это через legacy‑ядро было рискованно, поэтому мы сделали отдельный high‑load слой на gRPC.

5. Рост бизнеса требует всё больше ручного вмешательства

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

Часть 3. Мифы о high‑load: почему микросервисы — не панацея

Многие думают: «У нас проблемы с нагрузкой — надо переходить на микросервисы». Это заблуждение.

Микросервисы — это всего лишь инструмент, и он подходит не всем. Они полезны, когда:

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

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

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

Реальный пример: интернет‑магазин «УютСтрой» с каталогом на 180 000 товаров и синхронизацией с 1С. Мы не переписывали монолит, а вынесли обмен с 1С в отдельный сервис с очередью RabbitMQ. Время обновления каталога сократилось с суток до 15 минут — ускорение в 96 раз.

Часть 4. Сколько это стоит? Реальные ориентиры

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

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

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

Часть 5. Как работает разработка high‑load системы

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

Этап 1. Анализ нагрузки

Измеряем:

самые тяжёлые операции;
точки задержек;
объём данных;
обычную и пиковую нагрузку;
узкие места;
влияние внешних сервисов;
требования к доступности.

Без этого невозможно выбрать правильную архитектуру.

Этап 2. Проектирование

На основе данных решаем:

нужны ли микросервисы или достаточно оптимизации;
где применить очереди (RabbitMQ, Kafka);
что кэшировать (Redis);
как масштабировать БД (репликация, шардирование);
как изолировать компоненты для отказоустойчивости.

Этап 3. Разработка критических компонентов

В первую очередь делаем то, что влияет на скорость и надёжность: API, очереди, кэш, новый слой работы с БД.

Этап 4. Нагрузочное тестирование

Проверяем:

RPS;
время ответа (p50, p95, p99);
процент ошибок;
загрузку CPU и памяти;
поведение при резких пиках;
восстановление после сбоев.

Целевые показатели — свои для каждого проекта.

Этап 5. Мониторинг после запуска

Постоянно следим за временем ответа, ошибками, нагрузкой, состоянием БД, очередями и доступностью. High‑load — это не архитектура «спроектировал и забыл». Нагрузка и продукт меняются, поэтому система требует постоянного внимания.

Часть 6. Как выбрать подрядчика (чтобы не выбросить деньги на ветер)

Не верьте компаниям, которые обещают «выдержать миллионы пользователей». Это просто маркетинг. Вот на что реально обратить внимание:

1. Просите конкретные кейсы

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

2. Спрашивайте про опыт с legacy

Часто high‑load делается не с нуля, а на базе работающего бизнеса. Подрядчик должен уметь масштабировать без остановки системы.

3. Пусть объяснят архитектурное решение

Если единственный аргумент — «так современнее» — это красный флаг. Решение должно быть обосновано характером нагрузки.

4. Уточните про нагрузочное тестирование и мониторинг

Производительность должна измеряться, а не оцениваться на глаз.

5. Обратите внимание: работа начинается с анализа

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

Итог: главный принцип

High‑load архитектура нужна не тогда, когда вы достигли какого‑то магического числа RPS. Она нужна, когда текущая система перестаёт справляться: тормозит, работает нестабильно или не даёт бизнесу расти.

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

И помните: первый вопрос должен звучать не «а не пора ли перейти на микросервисы?», а «где именно сейчас ограничение и какое решение поможет его убрать?».

Наши реальные кейсы — цифры и факты

Вам осталось только решить, готовы ли вы к росту

Если вы узнали свои симптомы в этой статье, но всё ещё сомневаетесь — начните с аудита. Это самый безболезненный способ понять, где реальные ограничения.

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

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

Очереди по 30 минут: как мы научили курорт предупреждать гостей

2026-09-04T11:11:38.560Z

Или история о том, как 30 сценариев и одна Django-админка перераспределили потоки лыжников.

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

Заказчик хотел автоматизировать оповещения: чтобы гости сами получали сообщения в Telegram/SMS: «На этом подъёмнике сейчас большая очередь, советуем переместиться на соседний». На основе прогнозов загрузки система должна была предупреждать заранее, перераспределяя потоки без расширения инфраструктуры.

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

Что мы сделали

Команда из двух человек разработала Django-админку с гибкими сценариями оповещений. В ней можно создавать и настраивать сценарии без изменения кода — достаточно пары кликов.

Система интегрирована с внешним API прогнозов, проверяет несколько последовательных значений и отправляет сообщение только при подтверждении триггера. Это защита от спама и ложных срабатываний.

Параллельно мы провели бизнес-анализ двухлетних данных по загрузке канаток и на их основе подготовили 30 сценариев для разных пиковых ситуаций.

Самое сложное началось, когда мы подключились к внешним прогнозам

Данные «скакали»: канатка то на 200 человек, то на 500, то на 1000 в течение нескольких минут. Если бы мы реагировали на каждое изменение — гости получили бы шквал противоречивых сообщений, а персонал — груду ложных срабатываний.

Пришлось придумать защиту: система проверяет несколько прогнозов подряд и отправляет оповещение только когда значения подтверждаются.

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

Всё это собирали по кусочкам: предлагали гипотезы, обсуждали с заказчиком, проверяли на тестовых данных. Провели 4–5 волн настроек — часть параметров добавляли, часть убирали. Это была не доработка «по наитию», а практическая проверка гипотез вместе с заказчиком.

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

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

Система запущена, прошла интеграционные тесты, 30 сценариев приняты заказчиком и подтверждены его аналитикой.

Было: В пиковые часы популярные канатки перегружены, очереди до 30 минут, персонал не успевает регулировать потоки.

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

Отдельный интересный момент

Внешний API иногда работал некорректно. Мы постоянно мониторили, фиксировали проблемы и оперативно передавали заказчику. Они правили свою часть, мы параллельно дорабатывали логику. Так, итерациями, за месяц превратили «сырую» идею в готовую систему с 30 сценариями.

Что дальше

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

Полный разбор кейса — с деталями логики, настройкой порогов и результатами — читайте на сайте: https://itfox-web.ru/ru/cases/razrabotali-adminku-s-gibkimi-stsenariiami-dlia-gornolyzhnogo-kurorta-?utm_source=teletype&utm_medium=article&utm_campaign=alert_case

Как мы добавили продажу услуг в интернет-магазин: опыт «УютСтроя»

2026-08-20T14:18:35.066Z

Задача, которая оказалась сложнее, чем казалась

Крупная крымская сеть гипермаркетов «УютСтрой» (180 000 товаров, 4 магазина, более 800 заказов в день) обратилась к нам с запросом: добавить на сайт продажу услуг — монтаж, установку, покраску, порезку материалов.

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

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

Рассказываем, как мы выпутывались.

Что не так с конкурентами

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

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

Услуга — не товар

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

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

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

Как мы разместили услуги в карточке товара

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

Но заказчик предупредил: к одному товару может быть привязано до 30 услуг. Галерея не резиновая.

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

Страница услуги: зачем изобретать велосипед

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

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

Одна корзина для всего

Мы твёрдо решили: одна корзина для товаров и услуг. Услуги — в приоритетном блоке сверху. Если услуга куплена вместе с товаром (например, дверь и её монтаж), они группируются. Можно прямо в корзине изменить количество или удалить услугу.

Звучит просто, но потребовало пересмотра всей модели корзины. Раньше там были только товары с количеством. Теперь появился новый тип позиций — без склада, но с признаками: тип оказания, привязка к товару, субподрядчик. Пришлось переписать методы добавления, удаления, расчёта суммы и отображения.

Оформление заказа: сценарии, о которых мы не знали

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

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

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

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

Когда два функционала не поделили карточку

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

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

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

Новый закон и субподрядчики

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

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

Как мы работали без идеального ТЗ

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

Вот что помогало не сорвать сроки:

Старт с ядра. Выделили самые важные сценарии — те, без которых функционал не имеет смысла. Всё остальное — второстепенно.
Договорённости о приоритетах. Открыто сказали заказчику: «Вот что мы успеем сделать точно, а вот что будем дорабатывать по ходу».
Прозрачность процесса. Показывали промежуточные результаты каждую неделю. Заказчик видел прогресс и мог скорректировать требования.
Фиксация решений. Даже без формального ТЗ вели лог всех договорённостей — в чате, в таск-трекере.
Готовность к переделкам. Понимали, что не все решения будут идеальными с первого раза, и закладывали время на доработки.

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

Что мы поняли

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

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

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

Разработка мобильного приложения на Flutter: один код для трёх продуктов

2026-08-07T12:42:04.888Z

Клиент — B2B-платформа корпоративных скидок для сотрудников крупных компаний. Задача — мобильное приложение для iOS и Android. Всё выглядело стандартно, но в ходе работ выяснились три нюанса, которые потребовали гибких решений.

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

Второй. Бэкенд задерживался. Если бы мы стали ждать, фронт-команда простаивала бы неделями, а сроки и бюджет поползли бы вверх.

Третий. В приложении нужен был чат поддержки. Внешний сервис LifeText использовался на стороне клиента, но SDK для Flutter у него отсутствовал.

Что сделали:

— Выбрали Flutter как основу — пишем код один раз, получаем iOS и Android.
— Настроили Flavors: из одного кода собираются три приложения — со своими иконками, цветами и адресами серверов.
— Использовали мок-данные на время разработки бэкенда. Когда API доделали, переключились за один день.
— Чат интегрировали через WebSocket напрямую, без готового SDK.

Итоги:

— три приложения одновременно вышли в Google Play и App Store;
— аудитория — более 100 000 активных пользователей;
— краш-рейтинг < 1%, нареканий по скорости не было;
— экономия на поддержке — до 70% благодаря общей кодовой базе;
— проект занял 6 месяцев.

Подробности, архитектурные схемы и скриншоты — в полной версии кейса по ссылке https://itfox-web.ru/ru/cases/mobilnoe-prilozhenie-dlia-100-000-polzovatelei-razrabotka-na-flatter-k?utm_source=teletype&utm_medium=blog&utm_campaign=keystriprilozheniya

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

2026-08-04T11:56:25.039Z

Искусственный интеллект перестал быть хайпом и стал рабочим инструментом. По данным McKinsey, в 2024 году 65% компаний мира уже интегрировали ИИ в процессы — это в два раза больше, чем в 2023-м. Рынок разделился на два лагеря, и у каждого своя правда.

Лагерь 1: «ИИ — угроза человечности» Многие топ-менеджеры и собственники бизнеса сознательно блокируют нейросети. Их мотив понятен: сохранить уникальную экспертизу, авторский стиль и живое общение с клиентом. Доходит до крайностей: некоторые компании вводят негласный запрет на ChatGPT, а за его использование следуют взыскания.

Но вот парадокс: согласно Slack Workforce Index (2024), 48% офисных сотрудников скрывают факт использования ИИ. Они боятся показаться некомпетентными, хотя на самом деле просто делегируют рутину. Запрещая ИИ под флагом «человечности», мы крадем у экспертов время на стратегию, креатив и переговоры, заставляя их механически переносить данные из таблицы в таблицу.

Цифры PwC неумолимы: к 2030 году вклад ИИ в мировой ВВП составит $15,7 трлн. Компании, внедрившие AI осмысленно, уже фиксируют рост выручки (59% опрошенных McKinsey) и снижение издержек (42%).

Лагерь 2: «ИИ везде и вместо всех» Противоположная крайность — тотальная автоматизация. Показателен кейс шведского финтеха Klarna. В 2024 году они заменили нейросетью 700 операторов колл-центра. Расчет был на эффективность. Реальность оказалась жестче: к маю 2025-го боты начали галлюцинировать на сложных запросах, сервис провалился. Собрать команду живых специалистов обратно оказалось почти невозможно, пришлось ставить на телефоны даже программистов.

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

Золотая середина: Человек + Машина Мы в АЙТИФОКС придерживаемся гибридного подхода. Исследование Гарварда и BCG подтверждает его правоту: консультанты, использующие GPT-4, выполняют на 12,2% больше задач, на 25,1% быстрее и с качеством на 40% выше. Секрет прост: рутину забирает алгоритм, смыслы остаются за человеком.

Наши правила, выведенные практикой:

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

Что мы уже сделали для бизнеса:

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

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

ИИ для бизнеса без риска: как получить результат за три недели, а не за полгода

2026-08-03T13:48:19.522Z

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

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

Где ИИ уже приносит результат

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

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

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

Три правила быстрой и безопасной разработки Мы в АЙТИФОКС строим проекты на трёх принципах.

Правило 1. Нейросеть не считает. Все расчёты выполняет серверный код. Нейросеть получает готовый проверенный результат и превращает его в человеческий ответ. Это подход «нейросеть как интерфейс, а не калькулятор». Галлюцинациям в цифрах неоткуда взяться. Разработка становится инженерной задачей: нужен сильный backend-разработчик, а не дата-сайентист. Бизнес получает предсказуемый инструмент без эффекта «чёрного ящика».

Правило 2. Скорость без потери качества. Подготовительная рутина — написание инструкций, генерация тестовых данных, проверка краевых случаев — делегирована второй нейросети. Она делает это быстрее и чище человека. Результат:

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

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

Оплата за результат, а не за процесс и коммуникацию.
Сроки сокращаются кратно: три недели до прототипа вместо полугода.
Высокая гибкость на старте.

Кейс «РЕСТФОТОАНАЛИТИКА» Применили все три правила для сети корпоративного питания. Задача: руководитель задаёт вопросы о списаниях, маржинальности, аномалиях и получает точные ответы.
Результат:

Работающий прототип — за три недели.
Стоимость запроса к ИИ снижена в 20 раз.
Ноль ошибок в цифрах (модель не считает).
Руководитель перешёл от анализа постфактум к управлению по факту — видит аномалию сегодня и сегодня же реагирует.

Универсальность подхода Принцип «код считает — нейросеть объясняет» работает в рознице, логистике, финансах, производстве. Мы называем это «технологическим кубиком»: меняется отрасль, логика остаётся. Начать можно не с масштабного «внедрения ИИ», а с одного конкретного процесса, где боль измерима. И получить результат за недели.
Обсудить ваш процесс → https://itfox-web.ru/ru/cases#consultation

Галлюцинации нейросетей в цифрах — не баг, а архитектурная ошибка. Как мы её исправили

2026-08-03T13:16:56.756Z

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

LLM — не калькулятор и не база данных. Она не выполняет арифметические операции над ячейками, а предсказывает наиболее вероятную последовательность токенов. Когда вы отправляете таблицу на десятки тысяч строк, середина документа «проваливается» — внимание модели распределено неравномерно. Модель не может сказать «я не знаю» и заполняет пробелы правдоподобной, но фиктивной информацией. Производители заявляют контекстное окно в 200 тысяч токенов, но деградация начинается уже на первой трети. Ответ остаётся таким же уверенным, и без построчной сверки отличить правду от вымысла невозможно. А если сверять каждую цифру вручную, то зачем ИИ?

Почему инжиниринг промптов не спасает

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

Архитектурное решение: модель не видит сырые данные

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

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

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

Кейс: Рестофотоаналитика

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

Ошибки в цифрах исключены полностью.
Стоимость запроса снижена в 3–20 раз (с 30–100 тыс. токенов до 1,5–3 тыс.).
Прототип создан за три недели силами двух разработчиков.
Анализ ускорился на 95%: минуты вместо часов.

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

Выводы для бизнеса

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

Принцип универсален для розницы, логистики, финансов, производства — везде, где решения принимаются на основе табличных данных. Если ваши нейросети всё ещё врут в отчётах — проблема в архитектуре, а не в ИИ.
Обсудить применение подхода к вашим задачам → https://itfox-web.ru/ru/cases#consultation