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

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

Какие задачи бизнес Ставрополя решает через телефон

Сценариев в городе три, и они устойчиво повторяются:

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

Третий тип окупается быстрее остальных: он экономит рабочие часы, а не пытается привлечь новую аудиторию.

Персональные данные: чего требует 152-ФЗ от вашего приложения

Как только пользователь вводит имя и телефон, вы становитесь оператором персональных данных со всеми обязанностями. На практике это значит:

1. подать уведомление об обработке данных в Роскомнадзор;
2. открыть политику обработки прямо из приложения, а не ссылкой в никуда;
3. брать согласие отдельной галочкой без предустановленного флажка;
4. держать базы на серверах, физически расположенных в России.

Мы закладываем эти пункты в техническое задание сразу, потому что переделывать авторизацию и структуру базы после релиза дороже, чем сделать правильно с первого раза. Подробный разбор требований мы собрали на странице о соответствии 152-ФЗ.

Вход по коду вместо пароля

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

Кто что видит: права доступа внутри приложения

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

Деньги в приложении: эквайринг и правила магазинов

Платёж подключаем через российского эквайера или платёжный шлюз, реквизиты карты при этом не проходят через ваш сервер и не хранятся у вас – приложение получает только токен и статус операции. Отдельно проговариваем чеки по 54-ФЗ: онлайн-касса должна отбить фискальный документ и отправить его покупателю. Важный нюанс для App Store: если вы продаёте физический товар или услугу офлайн, платёж можно проводить своим шлюзом, а вот доступ к цифровому контенту Apple потребует проводить через встроенные покупки с их комиссией. Этот вопрос решается до вёрстки экранов, иначе можно попасть на отклонение сборки.

На чём пишем и сколько это занимает

Основную часть проектов делаем на кроссплатформенном стеке: одна кодовая база – две сборки, для Android и iOS. Это примерно на треть дешевле двух нативных команд и удобнее в поддержке. Нативную разработку берём, когда нужны тяжёлая графика, работа с оборудованием или фоновые задачи с высокими требованиями. Обмен с 1С настраиваем через промежуточный слой, чтобы номенклатура, цены и остатки приезжали по расписанию, а заказы уходили обратно; со стороны CRM обычно нужны сделки и история обращений. Простое приложение с личным кабинетом и оплатой – 8–10 недель. Продукт с интеграциями, ролями и админкой – 4–6 месяцев. В смету входят аналитика, дизайн, разработка, тестирование на реальных устройствах и выкладка в магазины.

Выкладка в магазины и дальнейшее сопровождение

Выкладываем в RuStore, App Store и Google Play, аккаунты разработчика оформляем на вашу компанию – так права на продукт остаются у вас, а не у подрядчика. Сборки подписываем, ключи передаём заказчику. После релиза остаётся работа, которую многие не планируют: обновления под новые версии операционных систем, реакция на отзывы в магазинах, разбор аварий по логам. Такие задачи мы ведём в рамках технической поддержки, а если приложение выходит вместе с сайтом, связка обычно строится на общем бэкенде – примеры есть в разделе портфолио.

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

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

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

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

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