ТЗ на мобильное приложение: что написать заказчику без опыта — структура, пример и чек-лист

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

Общие правила ТЗ — что пишет заказчик, а что можно оставить студии, — разобраны в статье «Как составить ТЗ на сайт или веб-сервис без опыта». Здесь — только то, что добавляет мобильное приложение.

Чем ТЗ на приложение отличается от ТЗ на сайт?

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

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

Каркас ТЗ на приложение удобно держать из десяти пунктов:

1. Цель и показатель: зачем приложение и как поймёте, что оно работает.
2. Роли: клиент, сотрудник, администратор — кто что делает.
3. Платформы и устройства.
4. Экраны и сценарии.
5. Вход, аккаунт и его удаление.
6. Push-уведомления.
7. Оплата.
8. Работа без интернета.
9. Сервер, админка и интеграции.
10. Публикация, материалы и то, что не входит в работу.

Раздел	В ТЗ на сайт	В ТЗ на приложение	Почему это меняет смету
Платформы	Браузеры, адаптив	iOS, Android, PWA, нижние версии ОС, планшеты	Каждая платформа — свои сборки, тесты и публикация
Публикация	Домен и хостинг	Аккаунты разработчика, карточки в магазинах, проверка магазином	Срок проверки назначает магазин, аккаунты оформляются на вас
Вход и аккаунт	Часто не нужен	Способ входа, удаление аккаунта в приложении	Правила магазинов и 199-ФЗ сужают выбор способов входа
Уведомления	Письма	Push: события, тексты, кто отправляет	Нужны сервер и настройки сервисов доставки
Оплата	Эквайринг на странице	Покупки в магазине или эквайринг — по типу товара	Магазин диктует способ оплаты цифрового контента
Без интернета	Не описывают	Что работает офлайн и как данные догоняют сервер	Локальное хранение и синхронизация — отдельная работа
Обновления	Выкладка в любой момент	Новая версия проходит проверку, старые остаются у людей	Сервер должен работать и со старыми версиями

Какие платформы и версии iOS/Android указать?

Напишите, нужны ли iOS и Android обе сразу или одна, телефоны или ещё планшеты, и с какой минимальной версии ОС приложение должно работать. Если не знаете версий — напишите, кто ваша аудитория и откуда она приходит: границу предложит исполнитель, а вы её утвердите.

Что важно записать в этом разделе:

• iOS, Android или PWA. PWA — сайт, который ставится на экран телефона как приложение, без проверки магазинов и части функций устройства. Если нужен только быстрый запуск, сравните варианты заранее: разбор в статье «Натив, Flutter или React Native».
• Минимальная версия ОС. Чем она ниже, тем больше устройств в тестах и тем меньше новых возможностей системы можно использовать. Опирайтесь на статистику своего сайта по версиям ОС, а не на «чтобы работало у всех».
• Планшеты и ориентация экрана. Если планшеты не нужны — так и напишите; иначе исполнитель вправе считать, что вёрстка под них нужна.
• Магазины. App Store, Google Play, RuStore. В тарифе «Мобильное приложение» названа публикация в App Store и Google Play; если нужен RuStore, впишите его отдельной строкой — тогда его учтут в смете.
• Чьи аккаунты. Аккаунты разработчика оформляются на вас и оплачиваются отдельно — это записано в тарифе. Запишите в ТЗ, кто и к какой дате их заводит: без них публиковать нечего.

Базовый тариф студии — приложение для iOS и Android из одного кода (React Native или Flutter) или PWA, до 6–8 экранов, от 200 000 ₽ и от 2 недель. Натив на Swift — так сделаны наши игры «Час пик» и «Орбита» — считаем после брифа.

Как описать экраны и сценарии пользователя?

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

Хороший сценарий в ТЗ выглядит так: «Клиент открывает расписание, выбирает занятие, нажимает «Записаться». Если мест нет — предлагаем лист ожидания. Если абонемент закончился — ведём на покупку. После записи приходит подтверждение и запись видна в разделе „Мои записи“». В одном абзаце — основной путь и два отказа.

Что не забыть в этом разделе:

• Первый запуск. Нужен ли онбординг, что видит человек до входа, можно ли смотреть каталог без регистрации.
• Пустые состояния. Что на экране, когда записей ещё нет, корзина пуста, поиск ничего не нашёл.
• Ошибки. Нет сети, платёж не прошёл, сервер не ответил — что видит пользователь и что может сделать.
• Разрешения. Камера, геолокация, уведомления, контакты: для чего каждое и что будет, если человек откажет.
• Роли. Если в приложении работают и клиенты, и сотрудники, опишите сценарии отдельно для каждой роли.

Если экранов больше восьми, сгруппируйте их по разделам и отметьте, что обязательно в первой версии, а что можно отложить. Это прямо влияет на цену: базовый объём тарифа — до 6–8 экранов.

Что написать про вход, push, оплату и офлайн?

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

Вход и аккаунт. Укажите способ входа и нужно ли восстановление доступа. С 7 июля 2026 года действует 199-ФЗ: владельца штрафуют, если вход устроен не одним из способов ч. 10 ст. 8 закона 149-ФЗ, — например, через Google или Apple; подробно — в статье о входе без Google и Apple. Правило Apple 4.8 при этом требует: если основной аккаунт создаётся через сторонний сервис входа, нужно предложить равноценный вариант — сервис, который собирает только имя и почту, позволяет скрыть почту и не отслеживает действия для рекламы без согласия. Исключение — когда приложение использует только собственную систему входа компании (App Review Guidelines, октябрь 2026 года). Значит, кнопка «Войти через Яндекс ID» или VK ID в iOS-версии — тоже вопрос к правилу 4.8, а вход по номеру телефона с кодом из SMS через ваш собственный сервер закрывает оба требования проще всего. Решение о способе входа под ваш случай стоит подтвердить у юриста.

Второе, что часто забывают: удаление аккаунта. Apple требует, чтобы приложение, где можно создать аккаунт, позволяло и удалить его в самом приложении (правило 5.1.1(v)). Google Play требует того же и дополнительно — ссылку на веб-страницу, где удаление можно запросить без установки приложения (справка Google Play). Впишите в ТЗ и экран удаления, и эту страницу.

Push-уведомления. Перечислите события: «запись подтверждена», «заказ передан курьеру», «новое сообщение». Для каждого — кому приходит, кто его отправляет (сервер автоматически или администратор вручную) и что открывается по нажатию. Рассылки по сегментам — отдельная строка. Как устроена доставка и почему человек может не получить push, — в статье о push-уведомлениях.

Оплата. Главное — что именно вы продаёте. Если открываете функции или контент внутри приложения — подписку, премиум-доступ, внутреннюю валюту — Apple требует встроенных покупок (правило 3.1.1). Если продаёте товары или услуги, которые потребляются вне приложения — доставку, запись к мастеру, абонемент в зал, — встроенные покупки использовать нельзя, нужен другой способ, например эквайринг (правило 3.1.3(e)). Напишите в ТЗ, что продаётся, и кто ваш банк-эквайер, если он уже есть.

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

Админка, сервер и интеграции

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

Что записать:

• Источник данных. Ваш готовый API или новый сервер. В тарифе студии — подключение к вашему API или простой сервер на нашей стороне.
• Админка. Кто и что меняет: каталог, цены, расписание, тексты push, статусы заказов. Какие отчёты нужны. Отдельной строкой админка в составе тарифа не названа, поэтому её объём уточняем на брифе — от него заметно зависит итог.
• Интеграции. Назовите системы: CRM, 1С, склад, служба доставки, SMS-сервис. Формат обмена уточняется при проектировании, вам достаточно названия системы и того, какие данные идут туда и обратно.
• Персональные данные. Какие данные клиентов собираете и где их хранить. Если собираете данные граждан России, по ч. 5 ст. 18 закона 152-ФЗ базы с ними должны находиться в России — это требование к размещению сервера и сторонних сервисов, которое стоит назвать заранее.
• Совместимость версий. Старая версия приложения остаётся у части людей неделями. Запишите, что делать, когда сервер изменился: обязательное обновление или поддержка старых версий.

Пример из наших работ — приложение знакомств Twin: один код на React, сборки для iOS и Android через Capacitor, сервер на Node.js, чат в реальном времени через WebSocket, push и коды подтверждения на почту. Каждый из этих пунктов в ТЗ — отдельная строка: чаты, например, в базовый тариф не входят и оцениваются отдельно.

Пример ТЗ на одну страницу

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

Обратите внимание: строка «Не входит» защищает от споров обе стороны; абонемент — услуга, потребляемая в зале, поэтому эквайринг, а не встроенные покупки; офлайн описан одной фразой, но однозначно. По такому ТЗ шесть экранов укладываются в базовый объём тарифа, а админка, CRM и лист ожидания уточняются на брифе.

Раздел ТЗ	Что написал заказчик
Цель	Клиенты записываются на занятия и покупают абонементы без звонка администратору
Кто пользуется	Клиенты студии; администратор работает в веб-админке, тренеры видят своё расписание
Платформы	iOS и Android, телефоны; планшеты не нужны; RuStore — во второй версии
Экраны	Вход, расписание, карточка занятия, мои записи, абонементы, профиль с удалением аккаунта
Сценарии	Записаться на занятие, отменить запись не позже чем за 3 часа, купить абонемент, встать в лист ожидания
Вход	По номеру телефона и коду из SMS
Push	Напоминание за 2 часа до занятия, освободилось место из листа ожидания, отмена занятия студией
Оплата	Абонементы — через эквайринг банка студии, чек по 54-ФЗ
Офлайн	Без сети показываются мои записи; запись и оплата — только онлайн
Сервер и админка	Расписание, залы, тренеры, цены абонементов меняет администратор; отчёт по записям за день
Интеграции	Записи и оплаты — в CRM студии; вход и данные клиентов — на сервере в России
Материалы	Логотип и цвета есть; тексты и фото залов — готовим сами до прототипа
Не входит	Чат с тренером, видеозанятия, программа лояльности — следующие версии

Чек-лист перед отправкой

Пройдитесь по списку: если на пункт нет ответа, допишите «не знаю, предложите вариант» — исполнитель закроет вопрос на брифе.

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

Какие ошибки в ТЗ на приложение встречаются чаще всего?

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

• «Сделать как у крупного сервиса». Назовите две-три функции образца, которые нужны вам, — их и оценят.
• Всё в первую версию. Чат, карты, видеозвонки, лояльность и рекомендации сразу — это другой бюджет и другой срок. Первая версия проверяет главный сценарий.
• Забытые требования магазинов. Удаление аккаунта, демо-доступ для проверки — Apple просит приложить данные демо-аккаунта, если в приложении есть вход (правило 2.1), — и способ оплаты цифрового контента.
• Нет владельца аккаунтов. Аккаунты разработчика, сервисы push, платежи должны быть оформлены на вас, а не на исполнителя. По тарифу вы получаете исходный код в своём репозитории и доступы ко всем сервисам.
• Нет критерия готовности. Если в ТЗ не сказано, на каких устройствах и в каких сценариях проверяют работу, приёмка превращается в спор о вкусе.

Когда подробное ТЗ не нужно?

Когда приложение небольшое и вы готовы работать через бриф: исполнитель задаёт вопросы, сам оформляет ТЗ и приносит его на согласование. Для тарифа «Мобильное приложение» первый этап так и называется — «Бриф и ТЗ: экраны, роли, интеграции, платформы».

Писать многостраничный документ до разговора с исполнителем имеет смысл, если вы проводите конкурс между несколькими подрядчиками и хотите сравнить предложения по одному описанию. В остальных случаях полезнее одна страница по примеру выше: цель, роли, экраны, сценарии и решения по входу, push, оплате и офлайну. Детали допишем вместе.

Дальше по тарифу: до 2 раундов правок на прототипе и до 2 раундов на готовой сборке, 14 дней бесплатной поддержки после публикации, гарантия по договору — 30 календарных дней с даты акта, отдельно от поддержки. Цену и срок фиксируем в договоре до старта; если ТЗ шире базового объёма, называем их после брифа. Подробнее о составе тарифа — на странице разработки мобильных приложений.

Короткие ответы на частые вопросы

Можно ли заказать приложение без ТЗ?

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

Сколько страниц должно быть в ТЗ на мобильное приложение?

Объём не главное. Для приложения до 6–8 экранов хватает одной-трёх страниц, если в них есть экраны, сценарии, вход, push, оплата, офлайн и то, что не входит в работу. Длинное ТЗ без сценариев проверять труднее, чем короткое с ними.

Нужно ли рисовать макеты экранов к ТЗ?

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

Как выбрать минимальную версию iOS и Android?

По вашей аудитории: посмотрите статистику сайта или текущего приложения по версиям ОС и решите, какую долю пользователей вы готовы не поддерживать. Чем ниже минимальная версия, тем больше тестов и ограничений; конкретную границу фиксируем в ТЗ на брифе.

Что делать, если ТЗ нужно поменять в ходе работы?

Изменения оформляются отдельным документом по соглашению сторон: новая функция — новая строка работ, со своей ценой и сроком. Правки внутри согласованного ТЗ делаются в рамках раундов правок тарифа.

Подойдёт ли ТЗ от другой студии?

Да, как основа. Мы проверим его на полноту по тем же разделам, что в этой статье, и отметим, чего не хватает: чаще всего — удаления аккаунта, офлайн-режима и того, кто ведёт аккаунты в магазинах.

Услуги и кейсы по теме: мобильные приложения · кейс Twin · цены и сроки