ООО "Фри тайм"
1 500 000
HoReCa и еда
Россия
Март 2026
Фри Тайм — сеть из трёх ресторанов в Благовещенске. Бургеры, роллы, локальный хит — корейский суп Куксу. Аудитория от 18 до 45, высокая лояльность в городе, планы открывать новые точки.
Формальный запрос — «обновите сайт». Звучало как косметика: дизайн освежить, кнопки перекрасить, может, пару фич докинуть.
Но когда мы начали разбираться, вскрылась история, которую в B2C часто не замечают, пока она не начинает бить по выручке.
Старый сайт на PHP/Laravel держал логику «разные рестораны — разное меню». На точке «Острова» доступны бургеры и роллы, на «Амурской» — только бургеры. Вроде не ракетостроение. Но архитектура была спроектирована без запаса на рост: на двух точках оно ещё дышало, на третьей начались глюки. Фильтры работали с ошибками, категории перемешивались, клиент заходил и не понимал, что реально можно заказать в конкретном ресторане.
Дальше сценарий был предсказуемым и дорогим для бизнеса. Клиент не разбирался, психовал и звонил диспетчеру. Телефон разрывался, персонал отвлекался от своих задач, онлайн-заказы терялись. А планы на четвёртую точку упирались в архитектуру, которая начала бы сыпаться окончательно.
Это когда сайт из инструмента продаж превращается в бутылочное горлышко. Бизнес хочет расти, а IT-фундамент его тормозит.
Можно было поправить фильтры, подкрутить категории и сдать проект как «обновление». Но мы в АЙТИФОКС так не работаем. Проблема сидела не в багах, а в том, как организованы данные. Латание симптомов означало бы, что через три месяца клиент вернётся с той же болью, только масштабированную на четыре точки. И платить пришлось бы дважды.
Мы предложили честное решение: пересобрать архитектуру с нуля под N точек. Не косметика, а фундамент.
Стек: Python/Django на бэкенде, адаптивный фронт на Next.js, интеграции с ЮKassa и Яндекс.Картами.
А дальше — три ключевых решения.
Первое — разделение данных по точкам. Каждое блюдо и категория теперь жёстко привязаны к конкретному ресторану. Переключаешь точку на сайте — видишь только то, что там реально готовят. Никакой путаницы, никаких фильтров, которые врут.
Второе — админка, из которой владелец сам добавляет новые рестораны. Заполнил карточку: адрес, время работы, точка на карте — ресторан появился на сайте. Без разработчика, без заявок в техподдержку, без ожидания в две недели. Это и есть готовность к масштабированию на практике, а не в презентации.
Третье — механики для роста среднего чека, вшитые прямо в процесс заказа. Кастомизация блюд: хочешь добавить ингредиент за доплату — пожалуйста. Перекрёстные продажи в корзине: к бургерам предлагаются соусы, к суши — закуски. Всё настраивается в админ-панели, не требует вмешательства программиста при изменении маркетинговой стратегии.
Отдельно — зоны доставки полигонами на Яндекс.Картах. Стоимость зависит от удалённости, условия бесплатной доставки управляются там же, а не зашиты жёстко в коде. Для сети, которая думает о масштабировании, это критично: в новом районе условия доставки могут быть другими.
Два месяца от старта до релиза. Сроки были сжатые, но команда справилась.
Архитектура теперь рассчитана не на 3 точки, а на 3 → N. Четвёртая, пятая, десятая — без доработок кода, только заполнение полей в админке.
Онлайн-заказы автоматизированы. Клиенты оформляют на сайте, а не звонят диспетчерам. Нагрузка на персонал упала, заказы перестали теряться.
Средний чек пошёл вверх за счёт вшитых механик кастомизации и перекрёстных продаж — без дополнительных затрат на маркетинг.
И ключевое: владелец перестал воспринимать сайт как ограничитель роста. Теперь это платформа, которая растёт вместе с бизнесом.
Что этот кейс говорит о нас как о команде
Запрос «обновите сайт» в девяти случаях из десяти маскирует более глубокую системную проблему. Бизнес не обязан это диагностировать — это наша работа.
АЙТИФОКС умеет смотреть не на симптомы, а на корень. Мы не латаем чужой код, если понимаем, что архитектура не выдержит роста. Мы проектируем систему, которая будет работать, когда бизнес вырастет в два, три, пять раз.
![]()
Елена Назарова
Нам не нужно было изобретать сложные алгоритмы. Нужно было правильно организовать данные, чтобы три ресторана с разным меню не превращались в хаос при открытии четвёртой точки. Мы это сделали