Разработка мобильных приложений в Караганде требует решения о том, какие устройства должна охватить первая версия. Не выбирайте подход только по знакомому названию технологии. Сначала перечислите действия пользователя, необходимую работу с камерой, файлами или другими возможностями устройства и ожидаемые условия использования. Попросите компанию связать свой технический выбор с этим перечнем и назвать ограничения предлагаемого решения.
Если вы рассматриваете iOS и Android, задайте одинаковые вопросы всем кандидатам. Какие части проекта будут общими, а какие потребуют отдельной реализации? Как команда планирует проверять поведение на каждой платформе? Важно понять не только исходную оценку, но и последующую работу: добавление функции, выпуск обновления и исправление различий. Сравнение должно учитывать весь согласованный жизненный цикл первой версии.
При выборе команды в Караганде попросите пояснить различия нативного и кроссплатформенного подхода на вашей функции. Например, как будет работать сканирование камерой и кто проверит его после обновления iOS или Android? Общая кодовая база не отменяет испытания на разных устройствах. Нативная разработка тоже требует согласованных сценариев: отдельные версии не должны по-разному трактовать отправленный заказ или незавершённое действие.
Попросите показать похожее по взаимодействию приложение. Если продукт зависит от сканирования или загрузки больших файлов, красивый информационный каталог мало объяснит о соответствующем опыте. Уточните, кто реализовывал мобильный код и тестировал устройства в приведённом примере. Перечень технологий на сайте компании полезен как начало разговора, но не заменяет разбора её собственной роли в реальном проекте.
Обсудите прототип до окончательного утверждения дизайна. Один и тот же сценарий должен оставаться понятным на выбранных устройствах, даже если внешний вид элементов различается. Попросите пройти путь регистрации, основного действия и просмотра результата. Выявленные на этом этапе правила лучше записать в требованиях, чтобы последующие показы оценивались по общей договорённости, а не по меняющимся представлениям сторон.
Уточните, где проходит граница мобильного приложения и сервера. Если каталог уже хранится в вашей системе, разработчикам нужен способ получать его через API, а не просто ссылка на сайт. Попросите разобрать загрузку списка, открытие карточки и отправку изменений. Это покажет, достаточно ли существующего обмена или нужны серверные работы. Отдельно назовите ответственных за уведомления, учётные записи и тестовые данные.
В смете разделите проектирование, мобильную реализацию, серверные работы, проверку и подготовку выпуска. Спросите, как оценивается новая функция сразу для двух платформ и что происходит при изменении уже принятого сценария. Регулярные платежи за внешние услуги и сопровождение учитывайте отдельно. Итоговая стоимость должна отвечать на вопрос о составе продукта, а не создавать впечатление фиксированной цены любых будущих доработок.
Для тестирования попросите согласованный перечень устройств и условий. На демонстрации полезны плохое соединение, повторный вход и возврат после прерывания действия. Уточните, какие проверки выполняет команда и какие подтверждает заказчик. Не подменяйте приёмку просмотром видео красивых экранов: попросите доступную для согласованной проверки сборку и фиксируйте замечания через воспроизводимые последовательности действий.
Перед передачей спросите, сможет ли другая команда собрать обе версии из полученных исходников. Нужны доступы, инструкция по окружению и перечень зависимостей. Уточните владельца аккаунтов и ответственность за выпуск исправлений. Согласуйте, где заканчивается исправление несоответствия требованиям и начинается платное развитие. Эти условия стоит видеть ещё при выборе подрядчика, а не узнавать после завершения основной разработки.
Сравните несколько предложений в одной таблице: сценарии, поддерживаемые устройства, этапы, приёмка, передача и сопровождение. Отзывы могут подсказать вопросы о коммуникации и реакции на ошибки, но не подтверждают пригодность технологии для вашего случая. Выбирайте компанию, которая объясняет решения через ваш продукт, раскрывает допущения оценки и даёт проверяемое описание результата каждого этапа.