Создание комфортной среды для жизни — это не только архитектура и дизайн. Технологичность — такая же часть комфорта, как удобство двора или качество сервиса. Сегодня жители ожидают, что всё, что связано с домом, доступно из смартфона: от оплаты счетов до вызова мастера. В этой статье поделимся нашим опытом — как мы создаём собственную цифровую экосистему Sminex — нативное мобильное приложение и единый бэкенд, построенные на современном стеке. Расскажем, почему мы отказались от коробочных вариантов, как выстраивали архитектуру и какие инженерные решения легли в основу продукта.
Почему мобильное приложение — это база
Мобильное приложение стало основным каналом коммуникации между жителем и управляющей компанией. Для жителей это привычный, удобный и быстрый способ решать любые вопросы. Для компании — прозрачные процессы и снижение нагрузки на кол-центр.
В Sminex за обслуживание домов отвечает своя Служба комфорта. Это больше, чем классическая управляющая компания. Служба комфорта Sminex — это команда, обеспечивающая премиальный уровень сервиса, инфраструктуру и цифровые инструменты для комфортной жизни. Очевидно, что приложение для клиентов должно соответствовать этим стандартам — быть современным, удобным и технологичным.
Как мы работали раньше и почему ушли от готовых решений
Раньше мы работали с личным кабинетом на SharePoint и нативным мобильным приложением. Оно выполняло базовые задачи, но со временем стало очевидно: архитектура достигла предела масштабируемости, производительность просела, а развивать функционал стало сложно. Требуемую доступность 24/7 оно не обеспечивало.
Мы провели анализ рынка, изучили решения вендоров, включая популярные платформы. Коробочные продукты действительно позволяют быстро запуститься: есть готовые модули, техническая поддержка, базовые функции. Для закрытия первичных потребностей это идеальное решение.
Но есть и ограничения:
сложно сохранить индивидуальность продукта,
доработки возможны только через вендора,
кастомные функции становятся частью общего решения для рынка,
ограниченные возможности интеграции с внутренними системами,
интерфейс не всегда отвечает нашим ожиданиям и в достаточной мере поддерживает бизнес-процессы,
внешний вид и UX приложений других компаний, использующих коробочное решение, практически одинаковы.
Для нас все эти ограничения означали одно: с вендорским решением мы не сможем обеспечить тот уровень цифрового опыта, который считаем комфортным.
Мы рассматривали разные предложения вендоров. Все они решают базовые задачи: подача заявок, оплата счетов, уведомления. Но если посмотреть на экраны этих приложений — одно от другого сложно отличить. В основном различаются цвета и логотипы. А нам важно, чтобы пользователь при одном взгляде сразу почувствовал: это — Sminex.
Команда экспертов и продуктовый подход
Мы решили разрабатывать всё внутри компании. Это позволило сохранить контроль над качеством, развивать экспертизу и выстроить продуктовый подход.
Проект начался с этапа Discovery. Мы провели интервью с жителями, собрали их ожидания, приоритизировали сценарии использования. На основе этого определили требования:
современные стандарты безопасности и производительности,
нативные приложения и продуманный UX/UI,
интеграции с существующими бизнес-процессами,
стабильность привычных функций из старого приложения.
Параллельно формировали внутреннюю экспертизу. Некоторых специалистов приходилось искать долго, но в итоге мы собрали сильную и вовлечённую команду, которая понимала цели продукта не хуже бизнес-заказчиков.
Поиск UX/UI-дизайнера оказался сродни поиску единорога, но мы своего нашли. В дизайнере было важно не только чувство прекрасного и навык подготовки классных макетов в «Фигме». Гораздо больше мы искали умение и готовность посмотреть на всё глазами клиента, понять, какие у него задачи, зачем он открывает наше приложение, и сделать этот пользовательский путь максимально простым, понятным и отвечающим потребностям клиента. А также — желание развивать и совершенствовать продукт, готовность вносить изменения на основании обратной связи и метрик, если что-то неудобно пользователям, и мы не достигли желаемого результата.
Технологический стек: как мы построили платформу
Мы изначально создавали систему, которая сможет развиваться в течение многих лет: адаптироваться под разные проекты и эволюционировать без полной переработки. Поэтому сделали ставку на современный стек и архитектуру.
Backend: микросервисы и изоляция контекстов
Backend реализован на C# и построен на микросервисной архитектуре. Каждый сервис отвечает за отдельный бизнес-контекст и имеет собственную базу данных (подход Database per Service на PostgreSQL). Это позволяет:
независимо развивать схемы данных,
масштабировать только нагруженные компоненты,
минимизировать связанность.
Сервисы развернуты в Kubernetes, что обеспечивает горизонтальное масштабирование и отказоустойчивость. Для синхронного взаимодействия используется gRPC, для асинхронных сценариев — Kafka. Гарантия доставки событий реализована через Transactional Outbox, а контракты версионируются с использованием принципов Semantic Versioning.
Конфигурируемость как часть архитектуры
Каждый дом Sminex — со своей инфраструктуро��: общественные гостиные Friend’s Lab, детские пространства Kid’s Lab, бассейны и фитнес-зоны Fit Lab. Поэтому нам на старте было важно, чтобы приложение адаптировалось без выпуска новой версии, сервисы подстраивались индивидуально.
Например, типы и статусы обращений, а также виды счётчиков загружаются динамически с бэкенда. Это позволяет:
адаптировать функциональность под конкретный проект,
управлять приоритетами,
быстро включать новые сценарии.
Фактически бэкенд выступает не только как API, но и как источник конфигурации пользовательского интерфейса главного экрана.
Приложение реализовано на нативных языках — Swift для iOS и Kotlin для Android. Такой выбор позволяет нам напрямую работать с возможностями операционных систем, быстрее внедрять новые фичи и не зависеть от ограничений кроссплатформенных фреймворков.
В основе iOS-приложения лежит SwiftUI, он используется для большинства экранов компонентов приложения. UIKit применяется точечно — для навигации и реализации сложных экранов.
Android-приложение реализовано на Kotlin с использованием Jetpack Compose для построения пользовательского интерфейса. Работа с асинхронными операциями и состоянием основана на Coroutines и Flow, что позволяет выстраивать предсказуемые и устойчивые цепочки обработки данных.
Data-driven развитие
Эту гибкость мы использовали для адаптации приложения под конкретный проект или даже конкретного пользователя. Мы настроили собственные метрики для отслеживания важных событий в приложении — так наш бэкенд получает информацию о наиболее частых сценариях использования в разрезе проектов. Мы придерживаемся подхода observability, метрики бэкенда собираются и визуализируются при помощи Prometheus и Grafana, Алертим из прометуса о падении сервисов или деградации системы. Аутентификация реализована при помощи idM системы, которая реализует протокол OIDC. Система обеспечивает выдачу JWT токенов и производит их интроспекцию
Функционал продукта основан на собираемых метриках, что позволяет нам:
определять наиболее востребованные функции,
перестраивать главный экран,
упрощать пользовательские пути.
На изображении ниже можно увидеть пример того, что у нас получилось:
На диаграмме видно большое количество метрик, связанных с главным экраном (MAIN). Это помогает нам понять, какие функции и кнопки наиболее востребованы, а от каких можно отказаться. Например, на основе получаемых метрик мы определяем, какие виды обращений лучше размещать на панели быстрого доступа для разных проектов.
Также мы видим, что в мобильном приложении особенно популярны функции создания и отправки обращений. Значит, этот процесс должен быть настолько быстрым и удобным, насколько это возможно. Для этого мы сократили количество действий от момента, когда пользователь открывает приложение, до отправки обращения в CRM: вынесли создание пропуска на главный экран, реализовали предзаполнение полей выбора и добавили виджеты для быстрого создан��я обращений.
Например, для заказа пропуска на курьера клиент ничего не заполняет — ему нужно нажать всего две кнопки и потратить около 5 секунд. Всё остальное мы делаем сами.
Оптимизация cold start
Отдельная и очень важная метрика — время запуска мобильного приложения. Медленный запуск вызывает недовольство пользователя и сводит на нет наши усилия по ускорению создания обращений. Поэтому была проделана работа по сокращению длительности первого запуска на iOS и Android:
настроили метрики холодного старта,
сократили количество синхронных запросов при входе,
минимизировали использование сторонних библиотек,
профилируем влияние каждой новой зависимости на производительность.
Те запросы, которые нельзя отправить асинхронно, скрыли за плавной анимацией входа. В проекте мы почти не используем сторонние библиотеки. Сетевое взаимодействие реализовано через собственный сетевой слой, который инкапсулирует работу с API, обработку ошибок и конфигурацию запросов. Добавление новой библиотеки обязательно проходит через обсуждение, профилирование и анализ того, как она повлияет на время запуска. Если отказаться от библиотеки невозможно, мы отдаём предпочтение статической сборке перед динамической. Всё это помогает нам поддерживать высокие показатели по времени создания обращения.
Ошибка, которую не покажут метрики
Но работа с метриками не всегда однозначна. На диаграмме можно заметить маленькую точку, соответствующую метрикам раздела видеокамер. На старте мы временно исключили раздел видеокамер, ориентируясь на исторические данные использования. Но, как оказалось, отсутствие этого раздела вызвало большое количество обращений от пользователей, для которых он был критически важен. Это негативно повлияло на оценки приложения в сторах сразу после релиза. В итоге мы сосредоточились на срочном добавлении функционала камер и спустя неделю после первого релиза выпустили обновление с этим разделом.
Этот случай стал для нас хорошим уроком: не всё в приложении можно измерить только с помощью метрик. Наша задача — делать приложение удобным не просто для большинства, а для каждого пользователя.
Что уже работает
В текущей версии доступны:
новости и уведомления,
передача показаний счётчиков,
оплата счетов,
обращения в Службу комфорта Sminex,
заказ пропусков,
просмотр камер видеонаблюдения.
Пользователи положительно оценили приложение уже на старте. В первую неделю после запуска 80% активных клиентов перешли на новое приложение, а доля пользователей, которые регулярно им пользуются, выросла с 45% до более чем 60%, что выше среднерыночных показателей.
В результате: 96% обращений клиентов и 98% оплат проходят через мобильное приложение, SLA по заявкам увеличился с 70% до 92%, продажи дополнительных услуг - на 25%.
Что дальше
Мы развиваем функциональность в сторону единой экосистемы для жителей. В планах:
управление доступом для членов семьи и арендаторов,
бронирование клубных пространств,
интеграции с умным домом,
собственный маркетплейс для сервисов и предложений в домах Sminex,
афиша мероприятий.
Заключение: о чём эта история на самом деле
Мобильное приложение Sminex стало не просто удобным инструментом, а частью повседневного взаимодействия с домом. Мы следуем подходу перфекционистов Fine Development и создаём цифровую платформу для комфорта жителей. В ней на виду — продуманные детали и отточенные процессы, вне поля зрения — работа с реальными потребностями жителей, постоянное совершенствование и крутая команда, способная всё это реализовать.
