Приложение
Проектируем путь пользователя, дизайн и состояния экранов. Согласуем iOS, Android и функции устройства, которые нужны в первой версии.
13FOX / Для бизнеса и продуктов
Разработка мобильного приложения под ключ
Приложение, сервер, админка и интеграции одной командой.
Мы создаём приложения для клиентов и сотрудников: от первого сценария до проверенного релиза и передачи исходников. Согласуем, что пользователь делает с телефона и как ваша команда обрабатывает результат.
В «Бакаеве» мы связали мобильный магазин, админ-панель и 1С через сервер синхронизации.
01 / Состав услуги
Один проект.
Все части рабочего процесса.
Мы предлагаем такой проект, когда приложению нужны данные из ваших систем, а сотрудникам нужно управлять заказами, контентом или обращениями. Если задача уже решается готовым сервисом, сначала проверим его возможности на вашем сценарии.
Сервер
Серверная часть хранит данные, проверяет права и выполняет правила бизнеса. Описываем, как приложение и другие системы обращаются к ней.
Админка
Сотрудник видит поступившие задачи, меняет допустимые статусы и управляет содержимым. Для каждой роли определяем разрешённые действия.
Интеграции
Подключаем нужные CRM, учёт, оплату и другие сервисы. Проверяем доступные интерфейсы, владельцев данных и поведение при сбое.
Если у вас уже есть сервер или админка, проверим возможность их использовать. Состав доработок фиксируем до начала реализации.
02 / Пример нашего подхода
Заказ с телефона
доходит до сотрудника.
Для нового проекта сначала разбираем один сквозной сценарий. В примере ниже учётная система задаёт цены и доступное количество, сервер хранит заказ, а сотрудник меняет его статус в админке. Эти правила согласуем для вашего бизнеса.
- Покупатель
Выбирает и отправляет
Видит товары, собирает корзину и подтверждает заказ. До отправки понимает состав и итоговую сумму.
- Сервер
Проверяет и сохраняет
Проверяет данные и доступность по согласованному правилу. Возвращает номер принятого заказа.
- Сотрудник
Берёт заказ в работу
Открывает заказ в админке, видит состав и меняет статус. Нужные данные уходят в учёт.
- Покупатель
Получает результат
Открывает тот же заказ в приложении и видит актуальный статус обработки.
Проверяем обычный путь и потерю ответа
Мы сверяем номер, состав и статус заказа в приложении, сервере и админке. Сотрудник получает данные, достаточные для выполнения заказа; покупатель видит подтверждение.
Если ответ потерялся после сохранения заказа, повтор отправки должен обработаться по согласованному правилу. Проверяем, как система узнаёт прежнюю операцию, что видит покупатель и как сотрудник находит её в журнале. Это отдельный сценарий приёмки.
Демонстрация проверки для нового проекта. Состав обмена и правила повтора определяем по вашим системам.
03 / Выполненный проект
«Бакаев»: мобильный
магазин связан с учётом.
Мы разработали мобильный магазин и админ-панель для товаров, заказов и курьеров. Помогли перенести локальную 1С в облако и настроили двусторонний обмен. В каталоге магазина больше 10 000 товаров.
Посмотреть кейс «Бакаев» ↗
Фото товара. Сотрудник заменяет фотографию в админ-панели, сервер синхронизации передаёт изменение в 1С.
Заказ и остатки. При заказе из приложения остаток уменьшается в админ-панели и 1С. Изменения из 1С доходят обратно до приложения.
04 / Границы первой версии
В первой версии пользователь
завершает нужное действие.
Первый релиз позволяет пользователю завершить выбранное действие, а сотруднику обработать его в своей системе. Мы предлагаем включить весь этот путь и необходимые исключения в одну версию.
Например, для заказа услуг можно начать с выбора услуги, заявки, её обработки и статуса. Каталог товаров, доставка и оплата появятся в составе проекта только при необходимости для вашей модели.
Фиксируем до разработки
- Кто пользуется приложением и кто обрабатывает результат.
- Какие платформы и устройства нужно проверить.
- Какая система задаёт каждое важное поле и статус.
- Как ведёт себя процесс при отказе сети и недоступности интеграции.
Оцениваем как расширение
Дополнительные роли, новые пользовательские сценарии, работа без сети, сложная аналитика и новые системы меняют объём. Для них указываем отдельные задачи и зависимости от первой версии.
Android / Устройства и рабочий процесс
Разработка Android-приложения на заказ
Создадим приложение для клиентов или сотрудников и свяжем его с системами вашего бизнеса.
Начинаем с одного действия пользователя: оформить заказ, обработать заявку или считать код товара. Вместе с владельцем продукта и ИТ-командой определяем устройства, нужные данные и результат первого релиза. Так в оценку попадают интерфейс, серверный обмен и проверка на вашем оборудовании.
В «Бакаеве» мы связали мобильный магазин, админ-панель и 1С. Этот опыт помогает нам проектировать путь данных между приложением и бизнес-системами. Посмотреть кейс ↗
Оценить Android-приложение
До оценки
На чём будет работать приложение
Телефон покупателя, планшет сотрудника и складской терминал требуют разных проверок. Мы составляем перечень поддерживаемых моделей и версий Android, размеров экрана и подключаемых устройств. Если оборудование уже закуплено, начинаем с его точной модели и тестового экземпляра.
- Экран и ввод
- Проверяем длинные названия, системную клавиатуру, увеличенный шрифт и удобство выполнения основного действия на выбранном телефоне или планшете.
- Сканер, камера, Bluetooth
- Уточняем способ подключения и доступность документации или набора инструментов производителя. Возможность считать код подтверждаем на конкретном устройстве.
- Разрешения и связь
- Определяем, какой доступ действительно нужен. Проверяем отказ пользователя, отзыв доступа в настройках, потерю сети и повторное подключение оборудования.
Предлагаемый сценарий / Работа с CRM
От кода товара до отметки о подборе
Например, сотрудник открывает на терминале назначенную ему заявку на комплектацию. В этом примере CRM хранит её состав и статусы позиций. Источник карточек товаров определяем до разработки.
Считать код
Сотрудник сканирует товар. Приложение через сервер находит позицию заявки и показывает товар и требуемое количество с учётом прав сотрудника.
Подтвердить подбор
Сотрудник проверяет товар и подтверждает подобранное количество. Сервер проверяет права и отмечает полностью подобранную позицию в CRM статусом «Подобрана».
Увидеть статус
После ответа CRM приложение показывает подтверждённый статус позиции. Менеджер видит его в той же заявке и готовит её к следующему этапу.
Если ответ не пришёл
Показываем, что результат ещё требует проверки. До запуска согласуем и тестируем повтор: как найти уже принятую операцию и когда разрешить новую отправку. Полноценную работу без сети оцениваем отдельным требованием — с правилами хранения и последующей передачи данных.
Подтверждённый опыт / Бакаев
Мы уже связали приложение с учётом
В мобильном магазине «Бакаев» работает сервер синхронизации приложения, админ-панели и 1С. Сотрудник меняет фотографию товара в админ-панели — она обновляется в 1С. Покупатель оформляет заказ в приложении — остаток уменьшается в админ-панели и учётной системе. Изменения из 1С доходят до приложения через связанную серверную систему.
Для нового Android-проекта мы отдельно определим доступные интерфейсы вашей CRM или учётной системы, ответственного за данные и правила обработки ошибок.
Как устроен мобильный магазин «Бакаев» ↗Первый релиз и развитие
Что входит в оценку и передачу
Стоимость зависит от числа действий и ролей, готовности серверных интерфейсов, оборудования и поведения при сбоях. Мы показываем состав работ по частям: проектирование, интерфейс, приложение, сервер и интеграции, проверка, подготовка сборки. Расходы на внешние сервисы и сопровождение обсуждаем отдельно.
Для первого релиза предлагаем один завершённый сценарий, согласованные устройства и необходимые права доступа. Если позже понадобится приложение для iOS, учитываем это при выборе технологии. Работу с оборудованием проверяем до окончательного выбора.
Согласуем до договора
- Перечень исходников приложения и сервера, права на них и ограничения сторонних компонентов.
- Инструкцию сборки, зависимости, настройки тестовой среды и порядок доступа к ключам подписи.
- Документацию обмена, перечень проверенных устройств и отчёт по приёмке.
- Ответственных за ошибки после запуска, состав поддержки и порядок оценки следующих изменений.
Каналы распространения и публикацию согласуем в общем плане выпуска приложения.
Приёмка на устройствах
Проверяем действия и исключения
Перед выпуском проходим согласованный сценарий на реальных устройствах. Эмулятор помогает проверить разные версии Android и размеры экрана; камеру, сканер и подключение оборудования проверяем на выбранных моделях.
- Сотрудник подтверждает подбор позиции; менеджер видит её статус в нужной заявке CRM.
- Отказ в разрешении объяснён; доступные действия продолжают работать.
- Пропавший ответ и повтор проверены по согласованному правилу, состояние операции понятно пользователю.
- После обновления сборки сохраняются предусмотренные данные и выполняется основной сценарий.
Подход к разрешениям и проверке устройств опирается на Android Developers и рекомендации по тестированию на устройствах.
До начала разработки
Будет ли приложение работать на всех Android-устройствах?
В проекте фиксируем поддерживаемые версии Android, типы экранов и модели специального оборудования. Проверку расширяем по аудитории приложения. Поддержку конкретного терминала или сканера подтверждаем тестом, с учётом его подключения и документации производителя.
Что подготовить для оценки интеграции с CRM?
Название и версию системы, один пример действия сотрудника, нужные данные и ответственного за доступ. Для технической проверки понадобятся документация интерфейса и тестовая среда. Секреты и клиентские данные в первом обращении не нужны.
Первый шаг
Пришлите один сценарий
Опишите действие пользователя, нужные системы и платформы. Добавьте модели устройств и оборудования, если они уже выбраны. Мы предложим состав первого релиза, обозначим зависимости и подготовим оценку по согласованным вводным.
Для компаний из Москвы, Санкт-Петербурга и других регионов России можем организовать удалённую работу. Передачу тестового оборудования и участие ваших специалистов согласуем до начала проверки.
iOS + Android · состав разработки
Кроссплатформенная разработка мобильных приложений
Определим состав первого релиза для двух платформ и оценим общую работу, интеграции и задачи каждой версии.
Опыт связанных систем: мобильный магазин «Бакаев», админ-панель и 1С.
Если покупатель проходит одинаковый путь на iPhone и Android, часть интерфейса и логики можно разрабатывать вместе. Мы проверяем этот путь и функции телефона до выбора технологии. Финансовый директор и руководитель продукта получают состав проекта, по которому можно сравнить предложения и решить, оправданна ли общая разработка.
Смета
Что можно объединить,
а что оцениваем отдельно
Общая кодовая база позволяет повторно использовать часть разработки. Экономику проверяем по перечню работ: сервер, подключение учётных систем и выпуск двух версий остаются в проекте.
| Работа | Общая часть | Что уточнить в предложении |
|---|---|---|
| Путь покупателя | Каталог, корзина, правила заказа и состояния экранов, если они совпадают на двух платформах. | Какие экраны и правила общие; какие элементы поведения адаптируют для iOS и Android. |
| Функции телефона | Обращение приложения к камере, карте или уведомлениям через выбранные библиотеки. | Поддерживают ли библиотеки нужные функции на обеих платформах; где потребуется отдельный код. |
| Сервер и обмен | Правила обработки заказа и интерфейс обмена данными могут обслуживать обе версии. | Есть ли подходящий сервер; кто дорабатывает 1С или CRM; какие данные и ошибки входят в приёмку. |
| Проверка и выпуск | Один перечень пользовательских сценариев и ожидаемых результатов. | Устройства и версии ОС для каждой платформы, сборки, подпись, материалы магазинов и работа с замечаниями модерации. |
| Поддержка | Доработки общих функций и серверной части. | Обновления ОС и библиотек, повторные проверки обеих версий, ответственность за платформенные сбои. |
Процент общего кода сам по себе не определяет экономию. Сервер и интеграции могут быть общими и для двух нативных приложений. Сравниваем варианты при одинаковых сценариях, интеграциях, устройствах для проверки и условиях передачи результата.
До выбора технологии
Проверяем самое рискованное действие
Каталог, заказ, личный кабинет и история обращений — повод рассмотреть общую разработку, если процесс совпадает на двух платформах. Если ключевая функция зависит от фоновой геолокации, оборудования или специальной библиотеки, сначала предлагаем техническую проверку на целевых устройствах. Её результат включаем в оценку.
Например, в Flutter предусмотрен вызов отдельного кода iOS и Android. Это позволяет подключать системные функции, но требует разработки и проверки соответствующей части. Выпуск каждой версии также включает свои настройки и подпись.
Техническая основа: платформенный код Flutter, выпуск iOS, выпуск Android. Подробнее о применимости технологии — в нашей статье о Flutter.
Пример предлагаемого первого релиза
Проверяем заказ до передачи
сотруднику магазина
Для интернет-магазина предлагаем начать с каталога, корзины, оформления и статуса заказа. Оплату, доставку и уведомления включаем в эту версию по условиям вашего процесса. Программа лояльности, сложные акции и офлайн-работа получают отдельную оценку.
- 01
Назначаем источники данных
Указываем, где ведутся цена, наличие и статус заказа: в учётной системе, сервере магазина или другом согласованном источнике.
- 02
Собираем заказ
Покупатель выбирает товар. Сервер проверяет согласованные условия покупки, сохраняет заказ и передаёт его в рабочую систему.
- 03
Проверяем исключение
Если после отправки пропал ответ, приложение уточняет результат по согласованному правилу. Проверяем повтор и покупку последней единицы на обеих платформах.
- 04
Принимаем результат
Сотрудник видит согласованный состав заказа и статус. Покупатель получает подтверждение. При сбое обмена проверяем сообщение пользователю и путь разбора ошибки.
В приёмке фиксируем ожидаемый результат каждого шага, условия повтора и доступные действия сотрудника. Порядок изменения остатков согласуем с владельцем учётной системы.
Подтверждённый опыт 13FOX
Приложение связано
с учётом магазина
В «Бакаеве» мы связали приложение, админ-панель и 1С через сервер синхронизации. Фото, изменённое в админ-панели, отражается в 1С. Заказ из приложения меняет остатки в админ-панели и 1С; изменения из учёта доходят до приложения.
Этот опыт показывает работу связанной системы. Для вашего проекта отдельно оцениваем интерфейсы двух платформ, доступный обмен и критерии его проверки.
Посмотреть кейс «Бакаев» ↗Сравнение подрядчиков
Сравниваем цену
при одинаковом составе
Отправьте командам один сценарий с исключением, перечень систем и платформы. В каждом предложении попросите выделить общую работу, задачи iOS, задачи Android, сервер и интеграции. Затем проверьте условия:
- Реальный проект. Попросите показать похожий путь пользователя и объяснить вклад команды. Наличие приложения в одном магазине не подтверждает опыт второй платформы.
- Приёмка. Уточните список устройств, проверяемые сбои, состав тестовых сборок и результат, после которого этап считается завершённым.
- Передача. Зафиксируйте в договоре исходники приложения и сервера, права на них, инструкции сборки и необходимые доступы к проекту и аккаунтам публикации.
- Поддержка. Согласуйте, что входит в исправление дефектов, как оценивают новые функции и кто выпускает обновления после изменения ОС или библиотек.
Для компаний из Москвы, Санкт-Петербурга и других городов России предлагаем дистанционный разбор сценария и демонстрации сборок. До договора согласуем участников, порядок приёмки и доступ к тестовым данным.
Перед оценкой
Можно ли заранее назвать стоимость двух платформ?
Оценку готовим после определения сценариев, интеграций и платформенных функций. В предложении показываем состав работ и допущения. Если готовый сервер пригоден для приложения, отдельно учитываем его подключение и необходимые доработки.
Можно ли выпустить версии одновременно?
Планируем разработку обеих версий в одном проекте. Дату доступности в каждом магазине согласуем с учётом аккаунтов, материалов и модерации. Общая кодовая база не гарантирует одновременное одобрение публикаций.
Входные данные для оценки
Начнём с одного
пользовательского сценария
Пришлите путь пользователя, необходимые системы и платформы. Мы определим состав первого релиза, общую и платформенную работу и подготовим оценку с допущениями.
До программирования / UX и UI
Дизайн мобильного приложения на заказ
Согласуйте путь пользователя на кликабельном прототипе, прежде чем передавать экраны в разработку.
Мы предлагаем владельцу продукта и руководителю маркетинга спроектировать сценарии, состояния экранов и визуальный интерфейс приложения. Вы сможете пройти ключевые действия, проверить логику с будущими пользователями и принять комплект макетов для первого релиза.
Оценить дизайн и прототипДля начала: один сценарий, нужные системы и платформы.
В «Бакаеве» мы разработали мобильный магазин, админ-панель и обмен с 1С. Этот опыт помогает учитывать связь экрана с работой бизнеса.
Один сценарий целиком
У каждого действия есть результат и исключения
Начинаем с задачи человека: например, повторить заказ. Уточняем, откуда берутся товары, цена и наличие, какая система подтверждает заказ и кто увидит его в работе. После этого собираем переходы и проверяем ситуации, которые меняют путь пользователя.
Демонстрация подхода · условный магазин
Подтверждение заказа
Выберите состояние
Пользователь видит
Заказ принят
Следите за статусом заказа в истории заказов.
Что фиксируем в проекте
Подтверждение приходит от системы заказов. В макете показываем полученный номер и статус; сотрудник получает заказ в рабочем списке.
Это пример требований к будущему приложению. Поведение сервера проверяется при разработке.
Для этого же пути проектируем загрузку, пустую историю, ошибку ввода и возврат назад. Если приложение работает с несколькими ролями, для каждой согласуем доступные данные и действия.
Как работаем
От описания задачи к проверенному прототипу
- 01
Фиксируем границы
Разбираем пользователей, цель и системы. Вместе выбираем сценарии первого релиза и отдельно записываем будущие функции.
- 02
Собираем структуру
Показываем карту экранов и переходы на простых макетах. Проверяем, как человек входит в сценарий, завершает его и исправляет ошибку.
- 03
Прорабатываем интерфейс
Согласуем визуальное направление, компоненты и состояния. Учитываем выбранные платформы, длинные тексты и увеличение шрифта.
- 04
Проверяем и передаём
Собираем кликабельный прототип. Записываем наблюдения проверки, исправляем согласованные проблемы и передаём исходники с пояснениями.
Проверка с пользователями
Предлагаем дать представителям аудитории задачу без подсказок: например, повторить прошлый заказ и изменить адрес. Смотрим, где человек останавливается, ошибается или теряет следующий шаг. Участников, сценарии и порядок повторной проверки согласуем в составе работ.
Прототип позволяет проверить понятность переходов и сообщений. Скорость загрузки, работу интеграций и доступность готового приложения проверяем уже на реализованной версии.
Результат и приёмка
Комплект, с которым разработчик может продолжить работу
До договора согласуем перечень артефактов и критерии приёмки. В финальном комплекте связываем сценарий, экран и ожидаемое поведение, чтобы команда могла проверить каждое решение.
| Артефакт | Критерий приёмки |
|---|---|
| Карта сценариев и экранов | У согласованных сценариев указаны начало, результат, роли и исключения. Функции следующей версии отделены. |
| Кликабельный прототип | Можно пройти основные действия и согласованные ветки ошибок. Переходы назад и выход из сценария работают; условные данные обозначены. |
| Макеты и компоненты | Есть согласованные экраны, повторно используемые элементы, состояния загрузки, пустого результата и ошибки. Описаны платформенные отличия и поведение при длинных текстах и увеличении шрифта. |
| Материалы проверки | Записаны задача, наблюдения, принятые исправления и открытые вопросы. Повторно проверены затронутые переходы. |
| Исходники и пояснения | Заказчику доступен редактируемый файл в согласованном формате. Переданы графика, комментарии к поведению и перечень внешних ресурсов с условиями использования. |
Отдельно фиксируем передачу прав, доступ к файлам, число согласований и поддержку дизайнера при разработке: разбор вопросов, проверку реализованных экранов и порядок изменения макетов.
Подтверждённый опыт
Экран связан с каталогом и учётом
В «Бакаеве» мы сделали мобильный магазин с каталогом и статусом заказа. Команда магазина управляет товарами, заказами и курьерами в админ-панели.
Сервер синхронизации связывает приложение, админку и 1С. Замена фотографии в админке отражается в 1С; заказ в приложении меняет остатки в админке и учёте. Изменения из 1С доходят до приложения.
В новом проекте мы уточняем эти связи до отрисовки: откуда экран получает данные и что он показывает при задержке или изменении условий.
Посмотреть кейс «Бакаев» ↗Состав оценки
Стоимость определяется сценариями и глубиной проверки
Для сметы считаем уникальные действия, роли и состояния. Один экран оплаты с подтверждением, ошибкой и повтором требует больше работы, чем статичная информационная страница. Несколько платформ, собственные компоненты и проверка с участниками тоже меняют объём.
Что нужно на входе
Цель приложения, один пользовательский сценарий, iOS и/или Android, действующие системы, фирменные материалы и существующие макеты, если они есть.
Что согласуем
Границы первого релиза, список экранов и состояний, проверку прототипа, исходники, число согласований и участие дизайнера в разработке.
Что оцениваем отдельно
Программирование, сервер, интеграции, публикацию и работу с реальными данными. Условия использования платных шрифтов, изображений и инструментов уточняем до их выбора.
С командой из Москвы, Санкт-Петербурга или другого города России можем работать удалённо: проводим разбор сценария и показываем прототип на встрече с ответственным за продукт. График согласований фиксируем в плане проекта.
До договора
Что уточнить перед заказом
Можно заказать только прототип, а дизайн сделать позже?
Да, предлагаем начать с карты сценариев и кликабельных простых макетов. В оценке укажем, какие действия и состояния можно проверить. Визуальную систему и окончательные экраны выделим в следующий этап.
Как сравнить предложения команд?
Дайте всем один сценарий и одинаковые платформы. Сравните список состояний, состав прототипа, участие пользователей, формат исходников и сопровождение разработки. В кейсе попросите показать путь целиком и уточните, за какую часть отвечала команда.
Можно начать с UX-аудита существующего приложения?
Да. Предлагаем разобрать выбранный путь по действующим экранам, обращениям пользователей и доступной аналитике. Результат — перечень проблем, основания и приоритет исправлений. Проверку гипотез на прототипе согласуем отдельной частью работ.
Первый разговор
Пришлите один пользовательский сценарий
Укажите нужные системы и платформы. Мы разберём путь пользователя, предложим состав первого релиза и подготовим оценку дизайна с прототипом по согласованному объёму.
Сценарий можно отправить в Telegram или обсудить с нами после заявки.
Подписной продукт · iOS и Android
Разработка приложения с подпиской
Пользователь оплачивает доступ, видит срок действия и продолжает пользоваться сервисом на своих устройствах.
Мы предлагаем основателю цифрового сервиса разработку приложения, личного кабинета и серверной проверки доступа. Согласуем, что открывает подписка и как продукт ведёт себя после продления, отмены, возврата или смены телефона.
Оценить приложение с подпискойДля начала: один сценарий пользователя, платформы и системы, которые нужно связать.
В «Бакаеве» мы связали мобильный магазин, админ-панель и 1С через сервер синхронизации. Этот опыт работы со связанными данными используем при проектировании нового продукта. Посмотреть кейс ↗
От оплаты к доступу
На сервере хранится право пользоваться продуктом
Для нового проекта мы предлагаем связать аккаунт пользователя, подтверждённую покупку и срок доступа. Приложение получает из этой модели статус подписки. Сервер также проверяет право доступа при запросе платного контента или функции.
- 01
Покупка подтверждается
Проверяем данные у источника покупки: магазина или выбранного платёжного сервиса. Незавершённая оплата остаётся в ожидании.
- 02
Обновляется право доступа
Сервер связывает покупку с аккаунтом, сохраняет продукт, срок, состояние продления и историю изменений.
- 03
Пользователь видит результат
Кабинет показывает доступные возможности, дату следующего продления или окончания и действие для управления подпиской.
Если уведомление задержалось или пришло повторно, сверяем актуальное состояние у источника. При обработке учитываем идентификатор события и период покупки, чтобы старое событие не вернуло прежний доступ. Поддержке предлагаем журнал с причиной изменения и временем последней проверки.
Состояния подписки
Каждое изменение имеет свой результат
Ниже — сценарии, которые мы включаем в проектирование и приёмку обычной подписки с автопродлением. Точные правила зависят от магазина и выбранной модели оплаты.
- Продление
- После подтверждения нового периода обновляем срок доступа. Если списание не прошло, проверяем, предусмотрен ли период сохранения доступа на время повторных попыток оплаты. Он задаётся условиями и настройками платформы.
- Отмена автопродления
- Показываем, что следующего списания не будет. Доступ обычно сохраняется до конца оплаченного периода; окончание проверяем по данным покупки. Правила Google Play ↗
- Восстановление
- После переустановки или смены телефона повторно проверяем покупку и её связь с аккаунтом сервиса. Покупка, уже связанная с другим аккаунтом, требует согласованного правила восстановления и проверки владельца.
- Возврат
- Запрос на возврат и подтверждённый возврат обрабатываем отдельно. Проверяем, к какой транзакции и периоду относится возврат, отозван ли доступ по ним и осталось ли другое действующее право. Затем пересчитываем доступ и показываем причину изменения. Уведомления Apple ↗
Продление и сохранение доступа при проблеме оплаты: документация Apple и документация Google.
Первая версия и оценка
Первый релиз: покупка, доступ и восстановление
В первый релиз предлагаем включить вход в аккаунт, экран предложения с условиями, покупку через согласованный канал, статус подписки, управление и восстановление, серверную проверку прав и рабочее место поддержки.
Стоимость разработки приложения с подпиской складывается из экранов iOS и Android, серверной модели, подключения источников покупки, кабинета, инструментов поддержки и проверки переходов между состояниями. Несколько тарифов, смена плана, пробный период, семейный доступ и офлайн-режим добавляют отдельные сценарии к оценке.
Что проверим до запуска
- Ожидающий платёж не открывает платную функцию. Подтверждённая покупка открывает её нужному аккаунту.
- Повтор и задержка уведомления обрабатываются по согласованным правилам; после сверки отображается актуальное состояние.
- Отмена, окончание периода и возврат меняют доступ согласно условиям покупки.
- После смены устройства доступ восстанавливается владельцу. Другой аккаунт не получает его автоматически.
- При потере сети интерфейс объясняет состояние. Срок использования сохранённого доступа согласован заранее.
До договора
Что стоит уточнить у команды
Попросите показать опыт связи приложения с сервером и объяснить восстановление доступа на одном сценарии. Уточните состав тестов, передачу исходников и порядок работы поддержки после запуска.
Что передаётся вместе с приложением?
В составе проекта предлагаем зафиксировать исходники приложения и сервера, документацию модели подписки, инструкции по сборке и размещению, перечень сервисов и порядок передачи доступов. Владельцев аккаунтов магазинов и инфраструктуры определяем до начала работ; условия передачи и поддержки закрепляем в договоре.
Можно ли работать удалённо из Москвы или Санкт-Петербурга?
Мы обсуждаем проекты из Москвы, Санкт-Петербурга и других городов России удалённо. Для оценки нужны платформы, география пользователей, состав платного доступа и действующие системы. Согласуем демонстрации, ответственных за приёмку и сопровождение.
Пришлите один пользовательский сценарий
Опишите, за что платит пользователь, какие платформы и системы нужны. Мы разберём путь покупки и доступа, предложим состав первого релиза и подготовим оценку с допущениями.
05 / Работа и приёмка
Показываем процесс.
Передаём рабочий продукт.
До старта определяем ответственного со стороны бизнеса, владельцев систем и порядок согласования. На демонстрациях показываем связанную работу приложения и панели сотрудника. Замечания фиксируем по проверяемым действиям.
- 01
Сценарий и оценка
Вы описываете действие пользователя и нужные системы. Мы уточняем роли, проверяем доступность обмена и готовим состав первого релиза с допущениями.
- 02
Прототип и реализация
Согласуем экраны, состояния и правила данных. Собираем приложение, сервер, админку и обмен; показываем законченные участки процесса.
- 03
Проверка на устройствах
Проверяем согласованные версии ОС и устройства, права доступа и ошибки ввода. Отдельно проходим повторы операций и сбои внешних систем.
- 04
Запуск и передача
Проверяем работу в согласованной инфраструктуре и проводим приёмку. Передаём исходники и инструкции по сборке, запуску и управлению продуктом.
Что проверить при сдаче
- Пользователь завершает сценарий на целевых устройствах; сотрудник видит те же данные.
- Статус проходит обратный путь до приложения. Повтор после сбоя обработан по согласованному правилу.
- Пользователь не получает чужие данные через экран или прямой запрос. После отключения пользователя доступ к данным закрыт.
- Сборка и запуск воспроизводятся по переданным инструкциям. Перечень аккаунтов, компонентов и расходов известен заказчику.
В договоре фиксируем состав исходников, права на код и условия сторонних компонентов. Аккаунты магазинов и серверную инфраструктуру согласуем заранее. Для развития после релиза определяем отдельный состав сопровождения.
Что уточнить о правах на код ↗06 / Оценка работ
Сравнивайте предложения
по одинаковым вводным.
Цена и срок зависят от числа сценариев, платформ, ролей и интеграций. Приложение с просмотром данных имеет другой объём, чем продукт с оплатой, изменением остатков и сложными правами.
Мы перечислим включённые экраны, серверные операции, действия сотрудника, проверку и передачу. Отдельно отметим готовность интерфейсов обмена данными (API), тестовых данных, контента и решений со стороны вашей команды.
Что должно быть в предложении
- Первая версия и её критерии приёмки.
- Работы по приложению, серверу, админке и каждой интеграции.
- Зависимости от ваших специалистов и внешних сервисов.
- Расходы на размещение, аккаунты и лицензии.
- Состав запуска, передачи и дальнейшей поддержки.
Технические требования сверяем с документацией платформ. Например, Apple требует проверить приложение на устройстве, обеспечить доступ к функциям с авторизацией и работающий сервер во время проверки.
App Review Guidelines, раздел 2.1 ↗До договора
Вопросы о разработке
Для компаний по России, включая Москву и Санкт-Петербург, согласуем удалённую работу, демонстрации и приёмку.
Можно заказать приложение вместе с сервером и админкой?
Да. Мы предлагаем единый проект: пользовательские сценарии, интерфейс приложения, серверную часть, панель сотрудника и необходимые интеграции. В предложении перечислим, что создаём с нуля и к каким вашим системам подключаемся.
Нужно сразу выпускать iOS и Android?
Это зависит от устройств вашей аудитории и обязательных функций. Можно начать с одной платформы или запланировать обе. До выбора технологии проверим работу камеры, уведомлений, входа и других нужных возможностей на целевых устройствах.
Что нужно для оценки стоимости и срока?
Один пользовательский сценарий, список систем и нужные платформы. Мы уточним роли, данные, исключения и готовность интеграций. После разбора предложим состав первого релиза и подготовим оценку работ с допущениями и зависимостями. Цена и срок зависят от этих вводных.
Как проверить команду до договора?
Попросите показать путь пользователя и сотрудника в выполненном проекте. Уточните, кто отвечает за сервер и интеграции, на каких устройствах проверяют приложение и что передают при завершении. Сравнивайте предложения по одинаковому составу работ и критериям приёмки.
Что передаётся заказчику?
В состав проекта предлагаем включить исходники приложения, сервера и админки, инструкции по сборке и запуску, описание обмена и перечень доступов. Состав передачи, права на код и условия сторонних компонентов фиксируем в договоре. Аккаунты и инфраструктуру согласуем с заказчиком заранее.
Работаете с компаниями из Москвы и Санкт-Петербурга?
Мы обсуждаем проекты удалённо с компаниями по России, включая Москву и Санкт-Петербург. До старта согласуем ответственного со стороны клиента, порядок демонстраций, обратной связи и приёмки.
Входит ли публикация и дальнейшая поддержка?
Готовим приложение к согласованному способу запуска. Работы по магазинам приложений, расходы на аккаунты и дальнейшее сопровождение перечисляем в предложении отдельно. Решение магазина о выпуске зависит от его проверки; объём поддержки согласуем по задачам продукта.
Ваш следующий шаг
Пришлите один сценарий,
системы и платформы.
Расскажите, что пользователь должен сделать с телефона и где сотрудник получит результат. Мы разберём зависимости, предложим состав первого релиза и подготовим оценку работ с допущениями.