Вы решили, что нужно приложение. Обращаетесь в агентство, они спрашивают: «Расскажите о проекте». Вы пишете что-то вроде: «Хотим приложение с заказом и лояльностью, как у конкурентов». Через неделю приходят три предложения — от $12 000 до $85 000.
Такой разброс не значит, что агентства не понимают, сколько стоит разработка. Это значит, что ни у кого не было достаточно информации для точной оценки. Хороший бриф сужает этот разброс до 20–30%. Основываясь на сотнях заявок, которые мы получили за десять лет, разница между полезным брифом и бесполезным почти всегда упирается в шесть вещей — и почти никогда не упирается в детали дизайна или количество экранов.
Почему хороший бриф экономит деньги ещё до старта
Большинство бюджетных сюрпризов в проектах ресторанных приложений возникают не из-за расширения scope в процессе разработки. Они возникают из-за информации, которой не было изначально — и которая всплывает на третьей неделе, когда изменения обходятся в пять-десять раз дороже, чем на старте.
Три паттерна, которые мы видим постоянно:
Забыли про POS-систему. Клиент прислал детальный двухстраничный бриф — вайрфреймы, цветовая палитра, список фич. Ни слова о POS-системе. Когда спросили — оказалось, что в четырёх локациях стоит r_keeper. У r_keeper сложный API со специфическими ограничениями, и интеграция с ним требует отдельного модуля. Одно упущение добавило примерно шесть недель к исходной оценке. Бриф выглядел подробным — он просто пропустил единственный вопрос, который больше всего влиял на архитектуру.
Как мы объединили 18 независимых iiko в единую систему управления франшизой
Читать статью«Один ресторан», который оказался сетью. В брифе написано: «заведение в Москве». На discovery-звонке выясняется: франчайзинговая модель, 8 точек, планы расшириться до 20 в течение 18 месяцев. Приложение для одной точки и платформа для растущей сети — это архитектурно разные продукты. Мультилокационная аналитика, разные меню по точкам, разграничение прав доступа — ничего этого не было в scope, пока не пришлось переделывать.
Предположение о платежах. Клиент хотел оплату картой и Apple Pay — стандартно. Чего не было в брифе: работа в трёх странах СНГ с разными локальными эквайрингами, два из которых не поддерживают единый процессинг. Каждая локальная интеграция — отдельная техническая задача. «Просто добавить оплату картой» и «настроить платёжную инфраструктуру для нескольких рынков» — принципиально разные вещи.
Шаблон брифа для ресторанного приложения — 6 разделов
Это не технический документ. Думайте о нём как о письменной версии разговора, который хорошее агентство всё равно провело бы с вами — только сделанного заранее, чтобы оценка отражала реальный проект.
Не нужно заполнять каждое поле идеально. Нужно дать агентству достаточно контекста, чтобы задавать умные уточняющие вопросы, а не общие.
Раздел 1: Бизнес-контекст
| Поле / Вопрос | Зачем агентству это знать |
| Тип бизнеса | Ресторан, сеть, dark kitchen, франшиза — разная архитектура и логика |
| Количество точек | Одна точка vs. сеть — разные требования к аналитике и управлению |
| Основная проблема | Что не работает сейчас? Это определяет приоритеты функционала |
| Аудитория приложения | Гости? Персонал? Курьеры? Каждая группа — отдельный продукт |
| Конкуренты / референсы | Покажите 2–3 приложения, которые нравятся — с объяснением, что именно в них нравится |
Если раздел отсутствует: Агентство не понимает, проектировать под одну точку или под масштабируемую платформу. Разница в стоимости — до 3x.
Как масштабировать франшизу, чтобы не потерять управление: технологический взгляд изнутри
Читать статьюРаздел 2: Основной функционал
| Поле / Вопрос | Зачем агентству это знать |
| Основной сценарий использования | Заказ, бронирование, лояльность, управление кухней — что главное? |
| Нужен ли онлайн-заказ? | Самовывоз, доставка, в зале — у каждого своя логика и интеграции |
| Программа лояльности | Баллы, уровни, punch card? Каждый вариант добавляет разную сложность и стоимость |
| Push-уведомления | Маркетинговые, транзакционные, оперативные — разные системы |
| Нужно ли приложение для персонала? | KDS, приложение для управляющего, курьерское приложение — отдельные продукты, не фичи |
Если раздел отсутствует: Агентство оценивает всё буквально или упускает зависимости. Часто клиент хотел решить одну задачу, а получил смету на полноценную платформу.
Программы лояльности в мобильных приложениях
Читать статьюРаздел 3: Интеграции
| Поле / Вопрос | Зачем агентству это знать |
| Текущая POS-система | Критично: определяет 30–40% архитектуры и стоимости интеграции |
| Агрегаторы доставки | Яндекс Еда, Delivery Club, Wolt — каждый требует отдельной интеграции |
| Платёжная система | CloudPayments, ЮКасса, Apple Pay / Google Pay — разные технические требования |
| CRM / аналитика | Есть ли действующие системы, с которыми нужна синхронизация? |
| Система бронирования | Есть ли действующая? Нужна интеграция или замена? |
Если раздел отсутствует: Здесь возникает большинство бюджетных сюрпризов. Один только POS может сдвинуть оценку на 30–50%, если выяснится в середине разработки.
Как мы автоматизировали онлайн-бронирование столов с интеграцией в iiko
Читать статьюРаздел 4: Масштаб и технические ограничения
| Поле / Вопрос | Зачем агентству это знать |
| Платформа | iOS, Android или обе? Киоск? Веб? |
| Ожидаемая нагрузка | Заказов в день, пиковая нагрузка — влияет на архитектуру |
| Нужен ли офлайн-режим? | Критично для кухонных приложений с нестабильным интернетом |
| Локализация | Один рынок или несколько языков и регионов? |
| Существующий код | Есть ли MVP или легаси-система, которую нужно учитывать? |
Если раздел отсутствует: Агентство проектирует под среднестатистические допущения. Если кухонное приложение должно работать без интернета — это другой продукт.
Онлайн-заказы без сбоев: как ресторанам и ритейлу обеспечить стабильность и рост
Читать статьюРаздел 5: Бюджет и сроки
| Поле / Вопрос | Зачем агентству это знать |
| Бюджетный диапазон | Вилка, а не фиксированная цифра — помогает предложить реалистичный scope |
| Желаемая дата запуска | Жёсткий дедлайн или гибко? Влияет на команду и стоимость |
| Приоритет: скорость или функционал? | Быстрый MVP или полный продукт сразу — разные стратегии |
| Планы на v2 | Что планируется в следующей версии? Влияет на архитектурные решения v1 |
Если раздел отсутствует: Агентства либо перестраховываются и дают максимальную оценку, либо предлагают минимальный scope, который разочарует. Ни то, ни другое не полезно.
Раздел 6: Процесс принятия решений
| Поле / Вопрос | Зачем агентству это знать |
| Кто принимает решение | Один человек или комитет? Влияет на сроки согласований |
| Как скоро нужно предложение | Срочно или есть время на нормальный discovery-звонок? |
| Рассматриваете других подрядчиков | Честный ответ помогает агентству расставить приоритеты |
| Есть ли внутренняя команда | Разработчики, дизайнеры, PM — влияет на формат сотрудничества |
Если раздел отсутствует: Агентство не может правильно оценить, сколько усилий вкладывать в предложение и когда ждать решения.
5 ошибок в брифе, которые раздувают бюджет до старта
Это не абстрактные предупреждения. Это паттерны, которые мы видим регулярно — в брифах и от тех, кто уже делал приложения, и от тех, кто делает первый раз.
1. Список фич вместо описания проблемы
Как выглядит: «Хотим: онлайн-заказ, программу лояльности, push-уведомления, аналитику, интеграцию с POS, приложение для персонала, курьерское приложение, киоск для гостей...» — страница списка.
Почему это проблема: Список фич без контекста задачи заставляет агентство оценивать всё буквально, часто упуская зависимости между пунктами. Как правило, у клиента была одна корневая проблема — «гости не возвращаются после первого визита» — а список фич был его гипотезой о том, как её решить. Агентство, работающее со списком, оценивает весь список. Агентство, работающее с проблемой, может предложить что-то гораздо проще.
5 способов убить фудтех-приложение ещё до того, как его полюбят пользователи
Читать статью2. Пропущен вопрос о POS-системе
Как выглядит: Детальный бриф с предпочтениями по дизайну, вишлистом функционала и даже брендбуком — и ни слова о текущей POS-системе.
Почему это проблема: Интеграция с POS — одна из самых технически сложных частей любого ресторанного приложения. iiko, r_keeper, Poster, 1С:Ресторан — у каждого разный API, разные ограничения, разные требования к лицензированию сторонних интеграций. Без понимания, какая система стоит, агентство оценивает «абстрактную POS-интеграцию». Когда реальная система выясняется в середине проекта — scope может вырасти на 30–50%.
3. «Один ресторан», который на самом деле сеть
Как выглядит: В брифе написано «ресторан». На discovery-звонке выясняется: франчайзинговая модель, двенадцать точек, ещё две открываются в следующем квартале.
Почему это проблема: Приложение для одной точки и мультилокационная платформа — архитектурно разные продукты. Сетевая версия требует централизованной аналитики с разбивкой по точкам, разных меню по локациям, разграничения доступа (управляющий точки А не должен видеть данные точки Б) и CRM, которая агрегирует данные по всей сети. Ничего этого не было в scope — потому что «ресторан» подразумевает одно место.
Доставка, которая работает: как умное приложение и грамотный бэкэнд делают дарк-китчены легко масштабируемым бизнесом
Читать статью4. Описание приложения, которое вы придумали, а не проблемы, которая есть
Как выглядит: «Хотим как у Додо Пиццы, только лучше»
Почему это проблема: Референс без объяснения — не информация. «Как у Додо» может означать их систему онлайн-заказа, трекинг доставки в реальном времени, программу лояльности, дизайн-систему или работу с промокодами. Агентство либо тратит час на уточнения, которые могли уместиться в одно предложение, либо угадывает — и угадывает неправильно.
7 уроков для тех, кто хочет создать SaaS-продукт для ресторанов: опыт Foodclick
Читать статью5. Бюджет не указан вообще
Как выглядит: «Бюджет: обсуждаемый.» Или пустое поле.
Почему это проблема: Без бюджетного ориентира агентство не понимает, что предлагать: MVP за $15k, продукт за $60k или enterprise-решение за $150k — это три принципиально разных проекта. Агентства либо перестраховываются и дают максимальную оценку, либо предлагают минимальный scope, который сразу захочется расширить.
6 способов увеличить маржу ритейла, используя данные, которые у вас уже есть
Читать статью
Что происходит после того, как вы отправили бриф
Отправить бриф — это не конец процесса, а начало разговора. Вот что должно произойти дальше и на что обратить внимание.
Хорошее агентство ответит в течение 24–48 часов с уточняющими вопросами, а не готовым предложением. Если вы получаете детально расписанную смету без единого вопроса — это сигнал: либо агентство работает по шаблону, либо делает допущения, которые вы не подтверждали.
Как это устроено у нас: мы изучаем бриф, отвечаем в течение 24 часов с вопросами, которые реально влияют на оценку, затем назначаем 30-минутный discovery-звонок. После него — диапазон стоимости и сроков с явными допущениями, а не фиксированная цифра, основанная на догадках.
Бриф — это инструмент. Хорошее агентство использует его, чтобы провести более умный первый разговор, а не чтобы избежать его.
FAQ
dev.family создаёт мобильные и веб-продукты для ресторанов, сервисов доставки еды и dark kitchen. Мы работали с проектами от приложения для одной точки до платформ для нескольких рынков.
