Smarta — это новый способ владеть смартфоном: клиент платит 60–70% стоимости сейчас, а через 1–2 года решает — доплатить остаток или сдать устройство обратно. При этом сервис «наследует» логику интернет-магазина, в нем есть каталог, фильтры, оформление заказа, личный кабинет.
Проект отличается от trade-In и рассрочки фокусом на остаточную стоимость устройства и удобстве клиента. Пользователь не заботится о продаже старого телефона и получает официальную технику с гарантией.
Проект стартовал с нуля: без технического задания, с жёсткими сроками и минимальными исходными данными. Перед командой стояла задача создать функциональный e-commerce сервис, который сможет выдержать нагрузку и масштабироваться.
Синергия нескольких команд была необходима для соблюдения сроков. Так как сроки были сжатые, то каждая команда разработчиков делала свой функционал. Договорились проводить ежедневные статусные встречи и поддерживать связь в реальном времени.
Это помогло быстро принимать решения, избегать дублирования усилий и сохранять контроль над качеством кода.
«Изначально мы участвовали в проекте двумя командами — backend и frontend. Позже к нам присоединились ещё две backend-группы от других участников проекта. Все решения принимались на статусных встречах между лидами backend-команд. В целом каждая команда работала автономно в своём контексте, сосредоточившись на своей части логики. С командой 1С работали рука об руку, потому что от данных со стороны 1С критически зависел весь наш функционал. Фронтенд-разработкой занималась отдельная команда со своим руководителем. В итоге над проектом трудилось порядка 50 человек технического персонала: 3 backend-команды, специалисты 1С, команда DevOps, тестирование. Мы очень много общались, обсуждали технические детали, проводили ежедневные статусные встречи». — Никита Быков, технический директор Alto
Автоматизация поможет сэкономить время и силы в дальнейшей работе, поэтому на начальных этапах проекта мы повели себя проактивно. Сделали подготовительные работы, подключили необходимые библиотеки и собрали докер.
Собрали Docker-образы. Это инструмент, который позволяет запускать программы и сервисы на любом компьютере одинаково. Это помогло всем участникам быстро запустить локальное окружение и протестировать первые версии сервиса.
Swagger — это документация, которая показывает, какие функции есть у сервиса, как с ним взаимодействовать и какие данные он принимает и возвращает.
Мы договорились, что Swagger будет автоматически собираться прямо из комментариев в коде. То есть разработчик пишет код и сразу указывает, как его использовать — и всё это сразу появляется в интерфейсной документации.
Так все команды видят, как работают разные части системы, и не путаются, как им общаться между собой. Это снижает количество ошибок при стыковке сервисов.
Pipeline — это автоматическая цепочка шагов, которые выполняются каждый раз, когда кто-то вносит изменения в код. Мы добавили в эту цепочку проверку того, что Swagger собирается.
Эти шаги помогли ускорить процесс разработки и минимизировать количество ошибок на ранних этапах.
Разработка e-commerce для Smarta включала несколько подходов, которые обеспечили стабильность и масштабируемость системы. Решения были выбраны так, чтобы минимизировать нагрузку на фронтенд, ускорить работу с данными и гарантировать точность информации о товарах.
В качестве мастер-системы использовалась 1С — центральный источник данных о товарах, ценах и остатках. Именно она выступала основой для всех остальных сервисов, включая интернет-магазин.
Задача состояла в том, чтобы обеспечить быстрый и надежный механизм получения изменений. Для этого мы спроектировали REST API, который позволяет обмениваться данными между сервисом и 1С. Вся контентная часть товаров, цены и остатки полностью управляются на стороне 1С, а наша задача — корректно их получать и использовать.
Еще одной деталью стало группирование товаров по наличию и приоритету («склейки» и «полусклейки»). Это позволило сделать каталог более понятным и удобным для пользователя: посетитель видел возможные варианты определенного девайса и сразу понимал, доступен ли он.
В карточке товара было реализовано пересечение множеств. Магазин автоматически проверяет остатки товара по запросу пользователя исходя из выбранных параметров и отображает статус товара: в наличии, нет в наличии, на поставке.
Целью было сделать интерфейс максимально отзывчивым, исключив множественные запросы к бэкенду и фронтенду. Чтобы достичь этого, мы подготовили данные на стороне сервера. Backend формирует полный список доступных опций для переключателей, что позволяет Frontend не делать лишние запросы.
Для хранения характеристик товара мы структурировали в парадигме бесконечного ENUM. У каждой опции список значений представляет собой динамически наполняемый справочник. Это решило проблему реализации фильтров в каталоге и упростило отображение доступных комбинаций опций в карточке товара.
Так, пользователь может выбрать нужные параметры мгновенно, без задержек. Алгоритм строится на предварительном формировании всех возможных комбинаций торговых предложений, из которых фронтенд «понимает», какое предложение подходит, и какие опции доступны.
Не все каталоги подходят для такого решения. Этот подход хорошо работает, когда: количество комбинаций характеристик ограничено (например, цвет + память) и все возможные варианты можно заранее загрузить целиком на фронтенд. Но если у товара десятки или сотни параметров, то это сильно замедлит загрузку страницы.
Такой подход не подойдет, когда данные слишком динамичны. Если доступность товара зависит от множества факторов, например, складские остатки в реальном времени, ограничения по регионам, акции и т.п., то заранее подготовленные данные устаревают за секунды. В таких случаях проще сделать динамический запрос к серверу , который вернёт актуальный ответ.
Такое решение не универсально, плюс требует согласованности между фронтендом и бэкендом. Чтобы механизм работал, нужно:
подготовить данные на бэкенде в нужной структуре.
убедиться, что фронтенд умеет их корректно интерпретировать.
постоянно синхронизировать логику между частями системы.
Это требует высокой слаженности команд, чего часто нет в больших проектах или при работе с legacy-системами. Если применять его бездумно, оно может усложнить систему вместо упрощения.
Мы смогли внедрить его в условиях ограниченного времени и ресурсов — и добились высокой скорости работы и удобства для пользователя.
«Использование ENUM для характеристик, предварительная подготовка данных для фронтенда и REST API для внешних интеграций, полезны не только в рамках MVP, но и при развитии платформы». — Никита Быков, технический директор Alto
Помимо тех задач, которыми занимались мы напрямую, в проекте были и другие важные участки — над ними работали другие участники разработки:
1. Каталог товаров по лучшим практикам e-commerce
Каталог был реализован с учетом стандартов трендов современного e-commerce. Интерфейс сделан интуитивно понятным, а фильтры обеспечивают быстрый отклик при поиске товаров. Это помогло повысить вовлечённость пользователей и снизить количество отказов на этапе выбора товара
2. Личный кабинет: всё в одном месте
Личный кабинет был спроектирован так, чтобы все ключевые действия были доступны в один клик. Информация о статусах договоров, платежей и доставок собрана в одном разделе. Такой подход упростил навигацию и сократил время на выполнение задач.

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

Ensi — это open-source система для ритейла и электронной коммерции, которая предоставляет готовые решения и практики для построения интернет-магазинов и B2B-платформ. Она включает в себя типовые архитектурные подходы, шаблоны баз данных, интеграции и компоненты, которые можно адаптировать под конкретные задачи.
Компания Alto является официальным партнером Ensi, что позволяет использовать опыт сообщества и проверенные практики при разработке e-commerce решений.
Для реализации сервиса подписки на смартфоны мы взяли за основу структуру хранения данных о товарах и торговых предложениях. Это помогло нам ускорить разработку, снизить риск ошибок и использовать проверенные подходы, уже применяемые в других e-commerce проектах.
Проект реализован за 2,5 месяца — срок, который считается крайне сжатым для создания полноценного e-commerce сервиса. В рамках MVP была создана платформа, способная выдержать нагрузку до 200 пользователей в секунду.
Одним из ключевых элементов стала карточка товара со сложной логикой отображения. Благодаря ей пользователь может просмотреть весь модельный ряд смартфона на одной странице, переключая опции — цвет, объем памяти, комплектацию и другие параметры.
Команда работала в составе нескольких внешних подрядчиков и внутренней команды заказчика. Была выстроена эффективная коммуникация между всеми участниками проекта, что позволило уложиться в установленные сроки.
Для ускорения разработки были использованы наработки из open-source экосистемы, которые были адаптированы под конкретные задачи проекта.
