Как мы подготовили сайт к открытию четвёртой точки за 2 месяца — хотя он не справлялся и с тремя.

1. Вводная задача от заказчика, проблематика, цели

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

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

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

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

Старый сайт на PHP/Laravel держал логику «разные рестораны — разное меню». На точке «Острова» доступны бургеры и роллы, на «Амурской» — только бургеры. Вроде не ракетостроение. Но архитектура была спроектирована без запаса на рост: на двух точках оно ещё дышало, на третьей начались глюки. Фильтры работали с ошибками, категории перемешивались, клиент заходил и не понимал, что реально можно заказать в конкретном ресторане.

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

Это когда сайт из инструмента продаж превращается в бутылочное горлышко. Бизнес хочет расти, а IT-фундамент его тормозит.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Почему мы не пошли по пути «подлатать»

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

Мы предложили честное решение: пересобрать архитектуру с нуля под N точек. Не косметика, а фундамент.

Что мы сделали по факту

Стек: Python/Django на бэкенде, адаптивный фронт на Next.js, интеграции с ЮKassa и Яндекс.Картами.

А дальше — три ключевых решения.

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

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

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

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

3. Результаты сотрудничества

Два месяца от старта до релиза. Сроки были сжатые, но команда справилась.

Архитектура теперь рассчитана не на 3 точки, а на 3 → N. Четвёртая, пятая, десятая — без доработок кода, только заполнение полей в админке.

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

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

И ключевое: владелец перестал воспринимать сайт как ограничитель роста. Теперь это платформа, которая растёт вместе с бизнесом.