Когда заказчик впервые сталкивается с разработкой, главный вопрос звучит не «сколько стоит», а «как вообще происходит разработка приложения и что я получу на каждом шаге». Понимать этапы важно не из любопытства: именно на стыках между ними теряют сроки, бюджет и контроль над проектом. Знаете, что должно быть на выходе каждого этапа, — значит, можете спокойно принимать работу и не платить за воздух.
Разберём этапы разработки мобильного приложения по порядку: что происходит, сколько длится, что вы получаете на руки и на что обратить внимание именно как клиенту. Это карта процесса от первой встречи до магазина приложений и дальше — к поддержке. Если вы только присматриваетесь к идее, начните с гайда как создать мобильное приложение, а сюда возвращайтесь за деталями процесса.
Этап 1. Аналитика и техническое задание
Что происходит. Команда разбирает вашу бизнес-задачу: кто пользователь, какой путь он проходит, какие функции нужны в первой версии, а какие можно отложить. Описывают сценарии, формулируют требования, рисуют схему экранов и фиксируют всё в техническом задании.
Сколько длится. От 3–5 дней для MVP до 2–3 недель для сложного продукта.
Что на выходе. Техническое задание со списком функций и сценариев, карта экранов и оценка по срокам и бюджету. Это документ, по которому потом принимают работу.
На что обратить внимание. Не соглашайтесь стартовать без письменного ТЗ. Размытое «сделайте как у конкурента» — главная причина споров и переделок. Как описать задачу так, чтобы получить точную оценку, мы разобрали в статье как составить ТЗ на приложение. Этот этап кажется «бумажным», но именно он экономит самые большие деньги дальше по проекту.
Полезный приём аналитики — разделить функции на «обязательно в первой версии» и «потом». Чем меньше всего в первом релизе, тем быстрее запуск и тем раньше вы получите реальную обратную связь от пользователей вместо догадок. Большинство «обязательных» функций при честном разборе оказываются желательными — и спокойно ждут второго релиза.
Этап 2. UX/UI-дизайн
Что происходит. Сначала проектируют UX — логику и структуру экранов: где какая кнопка, в каком порядке идут шаги, как пользователь добирается до цели за минимум касаний. Затем поверх накладывают UI — визуальный слой: цвета, шрифты, иконки, фирменный стиль. Дизайнер собирает макеты всех экранов в двух-трёх состояниях: пустой экран, заполненный, ошибка.
Сколько длится. От 1 недели для MVP до 4–6 недель для приложения с десятками экранов.
Что на выходе. Дизайн-макеты всех экранов в Figma и UI-кит — набор переиспользуемых элементов, чтобы приложение выглядело цельно.
На что обратить внимание. Проверяйте дизайн на «мобильность»: кнопки должны попадать под большой палец, текст — читаться на маленьком экране, ключевое действие — быть на виду. Учтите, что iOS и Android следуют разным гайдлайнам — Human Interface Guidelines и Material Design: одни и те же элементы выглядят и ведут себя по-разному, и хороший дизайнер это закладывает. Утверждайте макеты внимательно: переделать дизайн дёшево, переделать готовый код по новому дизайну — дорого.
Этап 3. Прототип
Что происходит. Из макетов собирают кликабельный прототип — по нему можно «пройти» сценарий, как по настоящему приложению, нажимая на кнопки и переходя между экранами. Без единой строчки кода.
Сколько длится. 2–5 дней, обычно совмещается с финалом этапа дизайна.
Что на выходе. Интерактивный прототип, по которому вы и команда проходите ключевые сценарии: регистрация, главное действие, оплата.
На что обратить внимание. Это последний дешёвый момент изменить логику. Пройдите по прототипу как реальный пользователь и поймайте всё, что неудобно или нелогично. Любая правка здесь стоит минуты, а на готовом коде — дни и десятки тысяч рублей. Не пропускайте этот этап ради экономии.
Этап 4. Разработка спринтами
Что происходит. Команда пишет код. Работу ведут спринтами — короткими циклами по 1–2 недели, в конце каждого вы получаете рабочую сборку с новыми функциями. Параллельно идёт разработка двух частей: фронтенд — то, что видит пользователь на экране, и бэкенд — серверная логика, база данных, авторизация, платежи.
Сколько длится. Основной по времени этап: от 2–3 недель для MVP до нескольких месяцев для сложного продукта.
Что на выходе. Работающее приложение, которое после каждого спринта можно установить и проверить вживую.
На что обратить внимание. Требуйте демо в конце каждого спринта — это ваш главный инструмент контроля. Видите прогресс каждые две недели, а не один раз «в конце», когда что-то менять уже поздно. Спросите про стек заранее: для большинства бизнес-задач это кросс-платформенный Flutter или React Native — один код под iOS и Android, дешевле и быстрее в поддержке. Если приложение запускают как MVP, разработка строится вокруг минимально жизнеспособного продукта: сначала ядро, потом обвес.
Здесь же закладывают то, что не видно на экране, но критично для бизнеса: аналитику событий, push-уведомления, обработку ошибок и логирование. Если попросить добавить их потом, это обойдётся дороже, чем заложить сразу. Уточните у команды, как устроен бэкенд и где хранятся данные пользователей: для российского рынка важно, чтобы персональные данные хранились на серверах в РФ — этого требует 152-ФЗ.
Этап 5. Тестирование и QA
Что происходит. Тестировщики проверяют приложение на разных моделях телефонов и версиях ОS: ищут баги, проверяют сценарии, нагрузку, поведение при плохом интернете и нестандартных действиях пользователя. Найденные дефекты заносят в трекер, разработчики исправляют, тестировщики перепроверяют.
Сколько длится. Идёт параллельно с разработкой, плюс отдельный финальный цикл 1–2 недели перед публикацией.
Что на выходе. Стабильная сборка без критичных и серьёзных багов, готовая к публикации, и отчёт о тестировании. Перед релизом приложение обычно прогоняют через закрытый бета-тест — раздают сборку небольшой группе реальных пользователей через TestFlight у Apple или закрытый трек в Google Play. Это ловит проблемы, которые не видны в офисе: поведение на слабых телефонах, в реальной сети, у людей с другими привычками.
На что обратить внимание. QA — это не «лишний» этап, на котором соблазнительно сэкономить. Баг, пойманный до релиза, стоит часы; тот же баг, найденный пользователем в сторе, оборачивается одной звездой в отзывах и оттоком. Уточните заранее, на каком парке устройств тестируют приложение.
Этап 6. Публикация в сторах
Что происходит. Готовое приложение загружают в App Store и Google Play, оформляют карточку (иконка, скриншоты, описание с ключевыми словами), проходят модерацию.
Сколько длится. Google Play — от нескольких часов до пары дней. App Store — от 1 до 7 дней, и Apple проверяет строже.
Что на выходе. Приложение, доступное для скачивания в магазинах под вашим аккаунтом разработчика.
На что обратить внимание. Apple отклоняет релизы за неочевидные вещи: нет политики конфиденциальности, нерабочая тестовая учётка, пустые экраны, функции-дубли браузера. Заложите 1–2 итерации правок по замечаниям модерации — это норма. Аккаунты разработчика (Apple — 99 $ в год, Google — 25 $ единоразово) оформляйте на свою компанию, а не на подрядчика, чтобы приложение оставалось вашим.
Этап 7. Поддержка и развитие
Что происходит. После релиза приложение живёт: выходят новые версии iOS и Android, которые могут ломать совместимость, появляются отзывы и идеи для доработок, растёт нагрузка. Команда обновляет приложение, чинит появляющиеся баги, добавляет функции по данным аналитики.
Сколько длится. Постоянно, пока приложение работает.
Что на выходе. Актуальное приложение, которое не отстаёт от ОS и конкурентов, и регулярные обновления.
На что обратить внимание. Обсудите формат поддержки до запуска, а не после. Обычно это 10–20% от бюджета проекта в год. Убедитесь, что в приложении стоит аналитика событий: без неё вы не увидите, на каком экране уходят пользователи, и будете дорабатывать вслепую. Помните и про обязательные обновления: Apple и Google периодически меняют требования и поднимают минимальные версии SDK, и приложение, которое не обновляют, в какой-то момент просто перестают пускать в стор.
Хорошая практика — собирать обратную связь системно: следить за оценками и отзывами в сторах, отвечать на них, складывать идеи доработок в бэклог и приоритизировать по влиянию на ключевую метрику. Так развитие приложения идёт по данным, а не по принципу «кто громче попросил».
Сколько занимает весь цикл
- MVP: аналитика и дизайн — около недели, разработка и тесты — 2–3 недели. Итого запуск за 3–4 недели.
- Среднее приложение: 1,5–3 месяца от первой встречи до публикации.
- Сложный продукт с интеграциями: от 4 месяцев и дольше.
На сроки сильно влияет скорость согласований на вашей стороне. Если макеты и сметы утверждает один ответственный человек, проект идёт по плану; если каждое решение ждёт совещания, разработка простаивает между этапами. Закладывайте время на свою часть работы — приёмку, обратную связь, предоставление контента и доступов — это часть графика, а не «фон».
Эти этапы не строго линейны: дизайн, разработка и тестирование часто идут внахлёст, а спринты позволяют корректировать продукт по ходу. Но порядок и смысл каждого этапа остаются неизменными — и именно по ним вы контролируете проект.
Кто работает над приложением
Чтобы понимать, за что вы платите, полезно знать состав команды. На типовом проекте участвуют: проджект-менеджер — держит сроки и связь с вами; аналитик — собирает требования и пишет ТЗ; UX/UI-дизайнер — проектирует экраны; мобильный разработчик — собирает само приложение; бэкенд-разработчик — отвечает за сервер, базу данных и интеграции; тестировщик — ищет баги. На небольших проектах роли совмещаются, на крупных — это отдельные люди.
Вам как заказчику не нужно общаться с каждым: для этого есть проджект-менеджер — одна точка входа. Но понимать, что в команде есть и тот, кто проектирует логику, и тот, кто тестирует, важно: если в смете нет аналитика и тестировщика, скорее всего, на этих этапах сэкономят, а расплачиваться придётся переделками и багами в проде.
Вывод
Разработка приложения происходит предсказуемо, если разбита на этапы с понятным результатом на каждом. Аналитика и ТЗ задают рамки, дизайн и прототип ловят ошибки до кода, спринты дают прогресс каждые две недели, QA защищает репутацию, а поддержка держит продукт живым. Ваша задача как заказчика — принимать работу по результату каждого этапа, а не ждать «финала».
Хотите план под вашу задачу с разбивкой по этапам, срокам и бюджету — расскажите об идее, и мы предложим маршрут разработки мобильного приложения с прозрачной сметой.