Разработать приложение

Запрос «разработать приложение» звучит как готовое решение, а на деле это развилка. Одному бизнесу нужен клиентский сценарий в App Store и Google Play. Другому — внутренний инструмент для склада на планшетах. Третьему достаточно веб-кабинета, который открывается с телефона, но не обязан жить в магазине. Если начать с выбора фреймворка, вы купите технологию раньше, чем поймёте задачу.

Практичный старт выглядит иначе: один пользователь, одно действие, один способ измерить результат. Только после этого появляются платформы, дизайн, API, модерация и поддержка. Ниже — как пройти путь от идеи до рабочей версии так, чтобы не оплатить «приложение компании», которым никто не пользуется.

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

Что обычно имеют в виду под «разработать приложение»

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

Пока вы не назвали, какой из четырёх нужен, смета будет «средней по рынку» и никому не подойдёт. Зафиксируйте канал: стор, браузер, оба. Зафиксируйте роли: только клиент или ещё оператор, курьер, администратор. Зафиксируйте источник данных: уже есть CRM и API или всё живёт в переписке.

Примеры рабочих формулировок

• Клиент записывается на услугу, получает напоминание и переносит слот без звонка администратору.
• Торговый представитель оформляет заказ офлайн и синхронизирует его, когда появляется сеть.
• Пациент видит результаты и следующее посещение, клиника не ведёт это в трёх мессенджерах.
• Партнёрская компания принимает заявки от своих клиентов в white-label оболочке.

Нужно ли вам это сейчас

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

Второй фильтр — устройство. Камера, геолокация, пуш, офлайн, NFC, биометрия. Нет ни одного пункта — начните с адаптивного веба. Третий фильтр — готовность компании кормить продукт: контент, модерация, ответы в поддержке, обновления под новые ОС. Без владельца продукта приложение устаревает за квартал.

Связанные разборы: нужно ли мобильное приложение, сайт или приложение, зачем нужен MVP.

Как разработать приложение: этапы без театра

Нормальный процесс не начинается с макетов всех экранов. Сначала discovery: сценарии, роли, интеграции, ограничения ИБ и 152-ФЗ, критерии приёмки. Затем прототип ключевых шагов — дешевле править клики, чем готовые модули. Затем разработка первой версии, тесты, пилот, публикация, наблюдение за метриками.

1. Бриф и гипотеза. Кто, что, зачем, какая цифра через 30 и 90 дней.
2. Границы v1. Must / should / later. Список «не делаем» так же важен, как список функций.
3. Прототип. Главный путь от запуска до результата, пустые и ошибочные состояния.
4. Архитектура. Клиент, API, хранение, очереди, пуши, логи, резервные копии.
5. Разработка спринтами. Демо каждую одну-две недели, а не «big bang» через квартал.
6. Тесты. Устройства, сети, оплата в песочнице, регресс после правок.
7. Пилот. Ограниченная аудитория, канал обратной связи, быстрые патчи.
8. Релиз и сопровождение. Магазины, мониторинг падений, план обновлений ОС.

Подробная карта шагов — в статье процесс разработки приложений. Если вместе с клиентом нужен внутренний контур учёта, смотрите связку разработка ПО и приложений и услугу разработки ПО.

Платформы, сторы и то, о чём забывают в брифе

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

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

Что подготовить до первой сборки в стор

• Юридическое лицо или ИП на аккаунтах разработчика.
• Политика конфиденциальности и порядок удаления аккаунта по требованиям магазинов.
• Контент без «lorem»: названия кнопок, пустые состояния, письма и пуши.
• Тестовые карты, SMS-шлюз, whitelist IP, если есть банк или 1С.

Роли: заказчик, разработчик, другая компания

Заказчик отвечает за процесс и приоритеты. Если три директора правят бэклог в чате, сроки не спасает ни один стек. Назначьте одного владельца продукта. Разработчик отвечает за реализуемость, риски интеграций и качество критичного пути: вход, сохранение данных, оплата. Компания-посредник, которая заказывает продукт для своих клиентов, обязана заранее решить white-label: одна сборка на всех или отдельные бренды.

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

ТЗ, без которого оценку считать рано

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

Для первой версии сознательно сужайте scope. Это и есть смысл MVP: проверить ценность, а не выпустить музей кнопок. Как запускать минимальную версию — что такое MVP. Направление работ по пилоту — разработка MVP, по клиентским приложениям — разработка приложений.

Дизайн, качество и аналитика

Интерфейс первой версии может быть спокойным и системным. Путаница в навигации недопустима даже в MVP. Пользователь должен завершить сценарий без инструкции. Анимации, уникальные иллюстрации и тёмная тема подождут, если воронка ещё пустая.

С первого дня закладывайте события: открытие экрана, старт сценария, успех, ошибка, отказ оплаты. Без аналитики вы не отличите «плохой продукт» от «никто не узнал, что он существует». Канал привлечения (QR в точке, база клиентов, реклама) планируйте вместе с релизом, иначе стор будет пустым.

Ошибки, из‑за которых проект дорожает

Делать «приложение компании» вместо одного сценария. Копировать чужие экраны без своего процесса. Забыть админку. Экономить на тестах оплаты и плохой сети. Обещать две платформы «потому что так солиднее» при аудитории в одном мессенджере. Не закладывать сопровождение: новая iOS ломает то, что «уже сдали».

Отдельная ловушка — ИИ-функции «чтобы было современно» без границы: что модель умеет, где человек проверяет, какие данные нельзя отправлять во внешний сервис. Про код с ИИ — в статье ИИ для написания кода.

Красные флаги на старте

1. Нет владельца продукта с вашей стороны.
2. Интеграция «с 1С» без контакта администратора и тестового контура.
3. Фикс цены при размытом списке экранов.
4. Код только на сервере подрядчика без передачи репозитория.

Когда не стоит начинать разработку приложения

Не стоит, если не можете описать главный сценарий за две минуты. Не стоит, если нет повторного действия и вы не готовы его строить сервисом. Не стоит «для SEO»: поиск приводит на сайт, не в иконку. Не стоит внутренней команде из нескольких человек за десктопами, которым браузер уже удобен.

В этих случаях сначала усильте сайт, учёт заявок и процесс. К мобильному клиенту вернётесь с цифрами, а не с ощущением «все так делают».

Следующий шаг

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

Обсудить границы первой версии можно в Grevin: grevin.info@mail.ru, +7 993 302-62-55, контакты.

Команда, репозиторий и приёмка без сюрпризов

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

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

Если приложение продаёте партнёрам как white-label, заложите смену логотипа, цветовой схемы, домена API и политики конфиденциальности без форка всего проекта. Иначе каждая сеть точек станет отдельной разработкой. Это дороже любой экономии на «потом разберёмся с брендами».

Аналитика, поддержка пользователей и магазинная реальность

События аналитики проектируйте вместе с экранами: иначе через месяц вы не отличите «не нашли кнопку» от «не пришли в приложение». Минимальный набор: первый запуск, логин, старт главного сценария, успех, ошибка сервера, отказ разрешения (камера, пуш, гео). Для бизнеса важнее завершённые действия, чем MAU ради отчёта.

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

Частые вопросы