Ошибки заказчика при разработке мобильного приложения и как их избежать
Семь ошибок, которые увеличивают бюджет на 30–80%, и как их избежать: симптом, цена в рублях и днях, конкретное действие на каждом шаге.
Объём задач на стороне заказчика зависит от подхода: при разработке с нуля проектируются все пользовательские сценарии и бизнес-логика. При сборке на готовой модульной платформе для e-commerce базовый функционал уже отработан, и заказчик фокусируется на бизнес-задачах. Рассмотрим семь наиболее частых ошибок при заказе разработки и разберём, какие конкретные действия закрывают каждую из них.
Цена ошибки в цифрах
В большинстве проектов разработки приложения для интернет-магазина 5–7 ошибок из списка ниже встречаются одновременно. Совокупное влияние — двукратное увеличение бюджета и удлинение сроков на 3–6 месяцев. Сводная таблица показывает среднюю «стоимость» каждой ошибки на проекте бюджетом 3–8 млн ₽.
| Тип ошибки | Цена в бюджете | Цена в сроке |
|---|---|---|
| Старт без аналитики и брифа | +30–50% к смете | +2–3 месяца на переделки |
| Выбор подрядчика только по цене | +100% (часто перезапуск) | +4–6 месяцев |
| Нет описания бизнес-логики элементов | +15–30% на доработки | +2–4 недели срыва релиза |
| Принятая «вилка» без декомпозиции | +40–80% от нижней границы | +1–2 месяца |
| Нет product owner на стороне | +10–20% на правки | +3–4 недели на каждый этап |
| Экономия на QA | +15–25% на хотфиксы | 20–30% оттока в первые 2 недели |
| Нет плана поддержки | 15–25% от разработки в год | Простои при изменении ОС |
Ошибка 1. Заказывать «по картинкам» без аналитики
Как это выглядит
Заказчик показывает подрядчику приложение конкурента или дизайн-макет и говорит: «нам надо такое же, посчитайте». Брифа нет, бизнес-целей нет, оценка делается «по картинкам».
К чему это приводит
В среднем 30–50% бюджета уходит на переделку функционала после релиза: то, что выглядело очевидным на картинке, не работает в живом сценарии покупки. Сроки растут на 2–3 месяца — потому что часть фич переписывают с нуля. Это одна из самых частых причин, по которой приложение требует доработки сразу после релиза.
Как избежать
Заложите 7–15 рабочих дней на этап аналитики и разработки технического задания до подписания договора на разработку. Этот этап оплачивается отдельно (200–400 тыс. ₽ для приложения интернет-магазина) и должен дать на выходе три артефакта: ТЗ с описанием функционала, JTBD-сценарии пользователей, функциональный каркас экранов. После этого подрядчик считает уже не вилку «от 1 до 5 млн», а смету с разбивкой по этапам.
Срок и стоимость этапа аналитики зависят от подхода к разработке. Когда приложение собирается с нуля, аналитика занимает 7–15 рабочих дней и оплачивается отдельно — потому что пользовательские сценарии, состав функционала и архитектура экранов прорабатываются под конкретный проект. При сборке на готовой модульной платформе для e-commerce этот этап короче: пользовательские сценарии, базовый функционал каталога, корзины, оплаты и личного кабинета уже отработаны на десятках других магазинов и зафиксированы в составе модулей. Аналитика в этом случае фокусируется на бизнес-целях, бренде и нетиповом функционале — и часто входит в стоимость интеграции платформы под бренд, а не считается отдельным платным этапом.
Ошибка 2. Выбирать подрядчика только по цене
Как это выглядит
Заказчик собирает 5–10 коммерческих предложений, сортирует по стоимости и выбирает того, у кого она ниже. Кейсы, портфолио, состав команды — второстепенные критерии.
К чему это приводит
Низкая цена сама по себе не плохая, но если она единственный критерий — проект часто заканчивается одним из трёх сценариев: студия делает не тот тип продукта (лендинги вместо сложных приложений интернет-магазина), команда не справляется с интеграциями (1С, маркетплейсы, платёжные системы), или после релиза подрядчик уходит, и заказчик остаётся с продуктом без поддержки. В 4 случаях из 10 проект приходится перезапускать у другого подрядчика — это 4–6 месяцев потерянного времени и итоговая стоимость как у двух проектов.
Как избежать
Выберите 3–5 подрядчиков и сравните их по четырём критериям одновременно, не только по цене:
- Профильные кейсы. Минимум 3 завершённых проекта того же типа — приложения интернет-магазина, выложенные в App Store, Google Play или RuStore. Не лендинги, не B2B-кабинеты, не корпоративные приложения. Если в портфолио только лендинги и сайты — команда не имеет опыта с полноценными e-commerce-сценариями, и ваш проект будет первым в этом классе задач.
- Реальные приложения в сторах. Скачайте 2–3 приложения из портфолио подрядчика и пройдите путь покупки от каталога до оплаты. Это даёт ощущение того, что вы получите на выходе: скорость экранов, удобство корзины, работу платёжной формы, push-уведомления, частоту обновлений. Кейс-страницы и видео-демо обычно не показывают этих деталей.
- Отзывы клиентов с проверкой. Самое надёжное — написать напрямую клиенту из портфолио и спросить про сроки, качество коммуникации, поддержку после релиза. Один разговор с заказчиком, который уже прошёл проект с этим подрядчиком, даёт больше, чем 10 кейс-страниц.
- Стоимость поддержки после релиза. Уточните условия поддержки до подписания договора: сколько стоит обновление под новые версии операционных систем, починка багов, интеграция с новыми сервисами. Если поддержка считается отдельным проектом по T&M-модели — закладывайте 15–25% от стоимости разработки в год. Если поддержка входит в лицензионную модель (для модульных платформ) — это другой расчёт, который снимает блок задач по обновлениям. Этот критерий часто пропускают на старте, а за 2 года поддержка составляет 30–50% TCO продукта (подробнее об этом — в Ошибке 7 ниже).
Ошибка 3. Не описывать бизнес-логику работы элементов
Как это выглядит
В ТЗ или брифе описан состав экранов и функций — каталог, карточка товара, корзина, личный кабинет. Но не зафиксировано, как каждый элемент работает: что делает кнопка, куда ведёт переход, что отображается в нештатных сценариях. На уровне макетов это не видно — дизайнер рисует состояние экрана, не поведение. В итоге заказчик, дизайнер и разработчик додумывают логику по-своему.
К чему это приводит
Расхождения в понимании логики вскрываются на этапе разработки или, что хуже, после релиза. Кнопка ведёт не на тот экран, фильтр работает не по той логике, корзина не очищается после оплаты, push-уведомление приходит не в том сценарии. Каждая такая правка — это 2–5 часов работы разработчика плюс регрессионное тестирование. Совокупно — +15–30% к смете на доработки и срыв сроков релиза на 2–4 недели.
Как избежать
До старта дизайна и разработки опишите бизнес-логику каждого экрана и сценария отдельным документом. Минимальный состав:
- Поведение каждого активного элемента. Что делает каждая кнопка, куда ведёт переход, какое состояние экрана появляется в результате.
- Нештатные сценарии. Что отображается, если корзина пуста, товара нет в наличии, оборвалась сеть, не прошла оплата, истёк токен авторизации.
- Бизнес-правила. Как считаются акции, скидки, программа лояльности, кэшбэк — в какой последовательности применяются, что приоритетнее.
- Триггеры коммуникаций. Какое событие запускает push-уведомление или email — заказ создан, оплата прошла, посылка отправлена, забронированный товар освободился.
Один из практичных форматов — пользовательский сценарий с описанием каждого перехода и условий, на котором этот переход срабатывает. Без этого слоя дизайн и разработка идут «по интуиции», и каждый член команды восстанавливает логику по-своему.
Ошибка 4. Соглашаться на оценку без декомпозиции
Как это выглядит
Подрядчик присылает оценку формата «приложение для интернет-магазина — от 2 до 5 млн ₽, срок 4–7 месяцев». Без разбивки по этапам, ролям и часам. Заказчик подписывает договор по этой вилке.
К чему это приводит
Финальная сумма почти всегда оказывается ближе к верхней границе вилки или выше: +40–80% от заявленной нижней границы. Договор по широкой вилке не защищает заказчика — каждый перерасход списывается на «уточнение требований» в процессе. Ориентир по реальным цифрам и составу стоимости проще держать через разбор стоимости разработки приложения или открытые тарифные пакеты с фиксированным составом работ.
Как избежать
До договора попросите смету с разбивкой по семи стандартным этапам: аналитика, дизайн, UX-прототип, фронтенд, бэкенд, QA, релиз и стабилизация. По каждому этапу — часы по ролям (UX, UI, Flutter, Backend, QA, PM) и сумма. Это даёт точку контроля: на каждом этапе вы знаете, что должно быть сделано, в какой срок и за сколько часов. Если подрядчик отказывается давать декомпозицию — это сигнал.
Ошибка 5. Полностью передавать управление подрядчику
Как это выглядит
Заказчик говорит: «вы лучше знаете, делайте как считаете нужным». На стороне заказчика нет product owner с правом принятия решений за 24 часа — все вопросы уходят к директору или собственнику, который отвечает через неделю или две.
К чему это приводит
Каждый этап удлиняется на 3–4 недели из-за ожидания согласований. Подрядчик принимает продуктовые решения сам — а его задача делать «как заказали», а не угадать бизнес-стратегию. В итоге продукт уезжает от бизнес-задач, и после релиза начинаются переделки: +10–20% к финальной смете и месяцы потерянного времени.
Как избежать
Назначьте на стороне заказчика product owner с полномочиями принимать продуктовые решения за 24 часа. Это либо штатный руководитель направления e-commerce, либо нанятый внешний product manager на время проекта (8–15 часов в неделю). Зафиксируйте в договоре SLA на согласования с обеих сторон: подрядчик отвечает на вопросы за 1 рабочий день, заказчик согласует артефакты этапа за 3 рабочих дня.
Ошибка 6. Экономить на тестировании
Как это выглядит
Заказчик предлагает «протестировать на пользователях после релиза» или отдаёт QA «своему разработчику» (обычно — фронтенд-программисту по совместительству). Бюджет на тестирование составляет 5–10% от разработки вместо стандартных 15–20%.
К чему это приводит
В первые две недели после релиза до 20–30% пользователей удаляют приложение из-за критических багов: не работает оплата на iOS, отваливается push-нотификация, ломается синхронизация с 1С. Восстановить аудиторию после плохого старта сложнее и дороже, чем сделать нормальное тестирование: хотфиксы стоят 15–25% от разработки в первые месяцы.
Как избежать
Заложите 15–20% бюджета и сроков на QA. Минимальный состав работ: функциональное тестирование по чек-листу, регрессионное тестирование при каждом изменении, тестирование на 6 устройствах (iOS актуальный + iOS-2, Android актуальный + Android-2, плюс одно слабое устройство), тестирование платёжных сценариев на реальных картах. Закрытое бета-тестирование на 50–100 пользователях до публичного релиза — обязательно для приложений интернет-магазина.
Ошибка 7. Не закладывать бюджет на поддержку
Как это выглядит
В бюджете проекта учтены только разработка и релиз. После запуска заказчик ожидает, что приложение «будет работать само». Контракта на поддержку нет, бюджета на обновления — тоже.
К чему это приводит
Через 4–6 месяцев Apple и Google выпускают обновления операционных систем — приложение перестаёт работать на новых версиях. Через 8–12 месяцев меняются API маркетплейсов, платёжных систем, 1С — интеграции отваливаются. Без бюджета на поддержку приложение деградирует за год: 15–25% от стоимости разработки — это та сумма, которую правильно заложить на поддержку в год.
Как избежать
На этапе планирования заложите в годовой бюджет 15–25% от стоимости разработки на техническую поддержку и обновления. Разделите ответственность: апдейты самой платформы и обновления безопасности включены в лицензионные платежи, а апдейты сторонних сервисов (платёжных интеграций, 1С, маркетплейсов) — считаются по T&M-модели отдельно. Это нормальная модель — попытка «зашить всё в одну сумму» обычно означает, что часть обновлений не делается.
Чек-лист: как избежать всех семи ошибок
Короткий список вопросов, который можно пройти до подписания договора с подрядчиком. Если на любой ответ «нет» — это сигнал вернуться на шаг назад.
- ТЗ с функциональным каркасом готово и подписано до старта разработки?
- Подрядчик прислал смету с разбивкой по этапам и фиксированной стоимостью?
- Сравнили минимум 3 подрядчиков по двум осям: стоимость + сроки?
- На стороне заказчика назначен product owner с правом решений за 24 часа?
- Бюджет на QA — не меньше 15% от разработки?
- В договоре зафиксировано тестирование на разных устройствах и закрытое бета-тестирование до публичного релиза?
- В годовом бюджете учтены затраты на поддержку?
- Указаны SLA на согласования с обеих сторон в рабочих днях?
С чего начать подготовку заказа
Если вы готовите заказ на разработку приложения для интернет-магазина прямо сейчас — три действия в порядке приоритета:
- Соберите бриф по чек-листу выше — это самостоятельная работа на 5–10 рабочих дней, которая снимает большинство рисков из этой статьи. Если нужна структура — посмотрите наш разбор этапов разработки мобильного приложения.
- Сравните ориентир бюджета с реальностью — посчитайте стоимость и сроки на калькуляторе до разговора с подрядчиками или прочитайте сколько стоит разработка в 2026.
- Запросите аудит готового брифа или ТЗ — независимая проверка показывает, где документ не закрывает риски, до того как вы отправите его подрядчикам.
Полезные смежные материалы:
- Fixed Price vs Time & Materials: что выбрать в 2026 — модели ценообразования.
- Flutter или нативная разработка: сравнение сроков и бюджета — для выбора технологического стека.
- Языки программирования для мобильных приложений в 2026 — для понимания, что предлагает подрядчик.
- Аналитика мобильного приложения: метрики и инструменты — для шага «бизнес-цели».
- Жизненный цикл разработки продукта: от идеи до запуска — общая карта проекта.
Цифры по retention и оттоку на старте можно сверить с открытыми отчётами: Data Insight (исследования российского e-commerce рынка), Statista (международная статистика по mobile retention), Mediascope (российская аудитория мобильных приложений), Реестр отечественного ПО Минцифры (статус подрядчика как разработчика российского ПО), TAdviser (рейтинги российских ИТ-компаний и их кейсы).
Часто задаваемые вопросы
Можно ли заказать разработку без брифа и сэкономить на этапе аналитики?
Технически — да, по картинкам или ТЗ от подрядчика. Но в 7 из 10 проектов это приводит к переделке функционала после релиза: в среднем 30–50% бюджета уходит на исправление того, что не учли на старте. Бриф — это не дополнительный этап, это первый этап, который определяет всё остальное.
Если подрядчик называет диапазон «от 1 до 5 млн ₽», это нормально?
Нормально на этапе первого разговора. Не нормально — подписывать договор по этой вилке. До договора подрядчик должен дать смету с разбивкой по этапам, ролям и часам. Без разбивки финальная стоимость почти всегда оказывается ближе к верхней границе, а часто выше неё.
Сколько стоит поддержка приложения после релиза?
Ориентир для приложения интернет-магазина — 15–25% от стоимости разработки в год. Это покрывает обновления операционных систем, починку багов, изменения в законодательстве, мелкие доработки. Сюда не входят апдейты сторонних сервисов (платёжные системы, маркетплейсы, 1С) — они считаются по T&M отдельно.
Должен ли заказчик назначать product owner со своей стороны?
Да — это обязательно. Product owner со стороны заказчика принимает решения за 24 часа, держит бизнес-цели и согласует приёмки этапов. Без него подрядчик принимает продуктовые решения сам — и продукт уезжает от бизнес-задач.
