10 вопросов студии разработки мобильных приложений перед стартом

Начинайте с объема, а не ставки

Две студии могут оценить одну идею по-разному, потому что представляют разные продукты. Одна включает админку, аналитику, публикацию и поддержку. Другая оценивает только мобильные экраны. Одна планирует backend. Другая ожидает, что API уже готовы.

Спросите: что входит в оценку, что не входит, какие предположения сделаны и какая информация может изменить цену?

Scorecard вопросов

10 вопросов студии

1. Как вы превращаете идею в объем работ?

Ищите процесс, где описываются пользователи, первый сценарий, роли, backend, админка, интеграции, аналитика и запуск. Если студия сразу прыгает к экранам, скрытая работа всплывет позже.

1. Какие предположения лежат внутри оценки?

Спросите, включены ли платежи, push-уведомления, карты, чат, подписки, админка, модерация, аналитика, публикация и поддержка.

1. Кто владеет исходным кодом и аккаунтами?

Нужно понимать, кому принадлежат репозитории, аккаунты магазинов, backend, дизайн-файлы, аналитика, сертификаты, домены и внешние сервисы.

1. Как вы работаете с изменениями?

Первый бриф редко идеален. Хорошая команда объясняет, как оцениваются, приоритизируются и фиксируются изменения.

1. Что мы увидим до разработки?

Полезные артефакты: пользовательские сценарии, кликабельный прототип, список функций, критерии приемки, заметки по архитектуре и риски запуска.

1. Как вы тестируете приложение?

Apple и Google ожидают, что приложение перед публикацией работает стабильно и полноценно. Спросите про устройства, crash-проверки, проверку аналитики, тестовые треки, демо-аккаунты и release notes.

1. Что происходит после запуска?

Спросите про период исправления ошибок, мониторинг, обновления SDK, изменения iOS/Android, обратную связь магазинов, реакцию поддержки и небольшие улучшения.

1. Как вы защищаете данные?

Для финтеха, медицины, детских продуктов, корпоративных инструментов и маркетплейсов важны авторизация, роли, журналы действий, резервные копии, тексты приватности, сторонние SDK и доступы к админке.

1. Можете показать похожие работы?

Точное совпадение отрасли полезно, но похожий процесс тоже важен. Маркетплейс, education app, booking app и корпоративное приложение показывают разные операционные навыки.

1. Кто общается с нами каждую неделю?

Спросите, кто принимает продуктовые решения, кто ведет delivery, кто утверждает изменения и как эскалируются риски.

Примеры из разных областей

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

Эти примеры важны: студия может быть сильной в красивых consumer-приложениях и слабой в операциях, или сильной в backend-инструментах и слабой в онбординге.

Что сравнивать между предложениями

Когда вы получили несколько предложений, не сравнивайте только итоговую цифру. Приведите их к одной структуре.

Сначала сравните включенный объем. Есть ли в каждом предложении уточнение продукта, UX-сценарии, визуальный дизайн, мобильная разработка, backend, админка, интеграции, аналитика, проверка качества, публикация и поддержка запуска? Предложение без backend может выглядеть дешевле, но просто переносить большую часть стоимости за пределы документа.

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

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

И отдельно сравните передачу. Если сотрудничество закончится, сможет ли бизнес поддерживать приложение? Нужны доступ к репозиторию, документация, владение аккаунтами, заметки по окружениям и понятный список сторонних сервисов.

Договор и передача проекта

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

Для мобильных приложений отдельно спросите про Apple Developer и Google Play аккаунты, ключи push-уведомлений, доступ к аналитике, backend-хостинг, резервные копии базы, дизайн-файлы, домены, email-сервисы, платежного провайдера и учетные данные админки. На продаже это звучит скучно, но при запуске или смене подрядчика становится срочно.

Еще спросите, что означает «готово». Функция не готова, если она открылась на одном телефоне разработчика. Она должна пройти критерии приемки, работать на целевых устройствах, обрабатывать пустые состояния и ошибки, отправлять нужные события аналитики, если они есть, и не ломать старые сценарии.

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

Не каждый расплывчатый ответ плох на этапе знакомства. Но есть разница. «Нужно уточнить платежные правила до оценки возвратов» — ответственный ответ. «Платежи простые, разберемся потом» — риск. «Мы проверяем на целевых устройствах» полезно. «QA включено» без деталей недостаточно. «Код ваш, доступ к репозиторию передаем» понятно. «Все принадлежит клиенту после оплаты» все равно требует точных формулировок.

Если сомневаетесь, попросите студию записать ответ как предположение в предложении. Если команда не хочет фиксировать это письменно, это тоже сигнал.

Сколько студий сравнивать?

Для большинства основателей достаточно трех серьезных предложений. Одно предложение не дает ориентира. Десять предложений создают шум и превращают выбор подрядчика в отдельную работу. Три предложения позволяют сравнить объем, предположения, процесс и коммуникацию без хаоса.

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

Лучшая студия не всегда та, которая быстрее всех говорит «да». Часто сильнее команда, которая спокойно подсвечивает неясный объем и помогает его привести в порядок.

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

Осторожнее, если студия:

• обещает фиксированную цену без вопросов про роли, backend и запуск;
• уходит от вопроса владения исходным кодом;
• не может объяснить, кто и как тестирует приложение;
• считает публикацию в сторах мелочью;
• не планирует админку и инструменты поддержки;
• говорит, что AI все удешевит, но не объясняет контроль качества;
• не показывает примеры, отзывы или рабочие артефакты;
• говорит, что любые изменения простые, но не имеет процесса изменений.

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

Appfyl начинает с объема: пользователи, первый сценарий, роли, backend, админка, аналитика, риски и путь запуска. Мы используем Flutter-first подход, когда один общий мобильный продукт хорошо закрывает iOS и Android, но технология следует за задачей. Также заранее планируем готовность к магазинам, владельца поддержки и будущую поддержку продукта.

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

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

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

Перед подписанием попросите студию дать краткое резюме объема: включенные функции, исключения, предположения, правила изменений, владение, проверка качества, запуск и поддержка. Appfyl может разобрать вашу идею и превратить ее в объем, который проще сравнивать между предложениями.

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