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

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

Кто заказывает мобильные продукты в университетском городе

• образовательные проекты – курсы, тренажёры, расписание, электронные пропуска;
• технологические компании – мобильный интерфейс к собственной платформе или прибору;
• медицинские центры и лаборатории – запись, результаты исследований, напоминания;
• доставка, кофейни и сервисы рядом с кампусами – заказ, бонусы, повторные покупки;
• производственные и приборостроительные предприятия – внутренние приложения для смен и обходов.

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

Что входит в первую версию

Мы стараемся выпускать не «всё сразу», а работоспособное ядро: один основной сценарий целиком, регистрация, платёж, если он нужен, и аналитика событий, чтобы через месяц был не спор о вкусах, а цифры. Обычно в первую версию входят авторизация, ключевой рабочий экран, история операций, уведомления и админка для вашей стороны. Отложить можно почти всё остальное – от персональных подборок до сложных отчётов. Такой подход экономит от 30 до 50 процентов бюджета на старте и снижает риск сделать никому не нужный раздел.

Персональные данные и особый случай – аудитория младше 18

Любое приложение с формой имени и телефона делает компанию оператором персональных данных: нужно уведомление в надзорный орган, политика обработки, доступная из интерфейса, и явное согласие пользователя. В образовательных продуктах добавляется отдельный слой: согласие на обработку данных ребёнка даёт законный представитель, значит, в системе должна быть связка «родитель – ученик» и понятный сценарий подтверждения. Магазины приложений тоже смотрят на возрастную аудиторию строже, вплоть до отдельных правил по рекламе и сбору идентификаторов. Мы фиксируем эти условия на аналитике; правовую часть подробнее разбираем в материале о 152-ФЗ.

Инфраструктура: где хранится и как защищено

Базы с данными российских пользователей размещаем на серверах внутри страны, резервные копии держим в том же контуре. Соединение шифруем, доступ администраторов – по двухфакторному входу и с персональными учётными записями, а не общим паролем в переписке. Отдельно занимаемся тем, что не видно снаружи: разделение боевой и тестовой сред, чтобы на демонстрационном стенде не оказалось реальных пользователей, и обезличивание данных в выгрузках для аналитики. Продукт можно спроектировать так, чтобы значительная часть аналитики работала на обезличенных событиях – утечь тогда попросту нечему.

Вход и управление доступом

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

Платежи, подписки и комиссия магазинов

Разовые покупки и подписки подключаем через российские платёжные шлюзы и систему быстрых платежей, карточные реквизиты остаются на стороне провайдера. Чек формирует онлайн-касса. Здесь есть развилка, о которой стоит знать заранее: продажа цифрового доступа – курса, подписки, премиум-функций – в версии для iPhone проводится через встроенные покупки Apple с комиссией, а офлайн-услуги и физические товары можно оплачивать своим шлюзом. От этого зависит и экономика проекта, и то, как будут выглядеть экраны оплаты, поэтому решение принимается до дизайна.

Из чего складывается срок разработки

1. Аналитика, сценарии и модель данных – 1–2 недели.
2. Прототип и дизайн – 2–3 недели.
3. Программирование бэкенда и кроссплатформенного клиента для двух платформ – от 6 недель.
4. Проверка на живых телефонах плюс нагрузочный прогон ключевых методов – 1–2 недели.
5. Релиз: подпись сборок, карточки в RuStore и Google Play, отдельная модерация у Apple.

Если у вас уже есть система, мобильное приложение подключается к ней через прикладной интерфейс – при живом и документированном API сроки сокращаются заметно. Готовые примеры работ смотрите в портфолио, а смежные направления – в разделе услуг.

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

Сможем ли мы развивать продукт своей командой? Да. Мы передаём исходный код, схему базы, документацию по интерфейсу и проводим передачу дел разработчикам заказчика – в Томске с наймом программистов проще, чем во многих городах.

Что быстрее для проверки гипотезы – приложение или веб-сервис? Обычно веб: он выходит быстрее и не проходит модерацию магазинов. Мобильную версию имеет смысл делать, когда нужны офлайн-работа, уведомления, камера или датчики устройства.

Как считается стоимость сопровождения? Либо фиксированная подписка с оговорённым объёмом часов, либо оплата по факту задач. Обновления под новые версии операционных систем нужны минимум дважды в год.

Готовы обсудить задачу – наберите +7 (901) 417-22-12. Разберём гипотезу, вместе решим, что войдёт в первую версию, и назовём срок, к которому продукт можно показать пользователям.