Разработка e-commerce-приложений — это инженерия мобильных витрин: каталоги товаров, корзины, оформление заказа, отслеживание доставки и механики лояльности, которые возвращают покупателя. От обычной разработки она отличается тремя конкретными вещами: каталог больше устройства (поэтому поиск, кэширование и доставка изображений решают, каким приложение ощущается), оформление заказа — место, где каждый дефект превращается в потерянную выручку, а одна и та же витрина часто должна существовать в нескольких экземплярах — на бренд, на рынок, на валюту.

Flutter подходит ритейлу необычно хорошо, потому что рисует интерфейс сам: сетка товаров, промо в формате сторис или кастомный сценарий оформления заказа ведут себя одинаково на iOS и Android из одной кодовой базы — примерно на 30–40% дешевле, чем строить ту же витрину дважды нативно. То, что напрямую касается платформы, — шторки Apple Pay и Google Pay, часть SDK платёжных провайдеров — идёт через : это рутина, но это реальная инженерная работа.

Какие продукты мы делаем

  • Приложения-витрины — каталог, поиск, корзина, оформление заказа, отслеживание доставки и отзывы для одного бренда
  • Приложения лояльности и кэшбэка — баллы, вознаграждения и предложения, как в кэшбэк-платформе, которую мы построили и ведём как парк приложений
  • White-label-парки для ритейла — одна кодовая база, производящая брендированное приложение для каждого мерчанта или рынка; платформенная работа вынесена в отдельную страницу услуги
  • Приложения для мерчантов — парное приложение продавца или менеджера магазина, которое мы сделали для той же платформы
  • Витрины маркетплейсов — где каталог принадлежит многим продавцам; двусторонняя динамика разобрана на нашей странице про маркетплейсы

Кто будет делать ваше e-commerce-приложение

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

Парк из пятнадцати брендированных потребительских приложений

Для платформы кэшбэка и лояльности под NDA одна кодовая база на Flutter производит больше пятнадцати полностью брендированных приложений — каждое со своим именем, темой и карточкой в сторе, — плюс приложение мерчанта по другую сторону каждой транзакции и админ-панель, которая запускает новый бренд без участия инженеров. Восемь месяцев разработки, и архитектура подробно описана. Если ваша ритейл-стратегия — больше одной витрины, это ровно та же форма задачи.

Платежи, знакомые изнутри

Nerdy Production возглавляет Илья Никсан, ранее CTO QIWI — одной из крупнейших платёжных платформ на своём рынке, где его команды вели карточный процессинг и отвечали за зону PCI-DSS. Связь с магазином прямая: оформление заказа — это платёжная интеграция, одетая в витрину, и человек, который ведёт вашу разработку, эксплуатировал другую сторону этой интеграции. Дисциплины, которые из этого следуют, — деньги целыми числами в наименьших единицах валюты, состояние доступа на сервере, карточные данные вне зоны вашего приложения — те же, что полностью описывает наша страница про финтех.

Механика каталога на масштабе маркетплейса

OneTwoDo — не магазин, но это просматриваемый каталог объявлений с фотографиями, поиском, мультивалютными ценами и лентой, отфильтрованной по языку и локации, — спроектированный и выпущенный за семь недель. Механика «красиво показать большую коллекцию вещей на среднем телефоне» переносится целиком.

Что на самом деле требуют e-commerce-приложения

В каждом ритейл-проекте возникают пять задач. Вот как мы решаем каждую.

Каталог больше устройства

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

Оформление заказа, где отказ — основной сценарий

Платежи падают: карты отклоняются, челленджи 3-D Secure истекают по таймауту, приложение сворачивают посреди оплаты, сеть обрывается между подтверждением у провайдера и тем моментом, когда о нём узнаёт ваш бэкенд. Оформление заказа проектируется вокруг этих случаев, а не вокруг счастливого пути: идемпотентное создание заказа, чтобы повтор не мог списать деньги дважды, состояние платежа на сервере, а клиент лишь отражает его, и однозначный ответ на экране для любого исхода. «Платёж прошёл у провайдера, но не подтвердился на бэкенде» — класс багов, который стоит реальных денег, и его убирают на этапе архитектуры.

Нативные платёжные шторки — нативно

Apple Pay и Google Pay конвертируют на мобильных заметно лучше, чем формы ручного ввода карты, и оба доступны из Flutter через platform channels поверх собственного SDK каждой платформы. Мы подключаем их рядом с карточным сценарием провайдера, а не вместо него, и держим сырые карточные данные внутри SDK провайдера, чтобы ваша зона PCI оставалась настолько маленькой, насколько позволяет продукт.

Цены — это деньги, а деньги — не float

Каждая цена, скидка, налоговая строка и итог — это целые числа в наименьших единицах валюты или decimal-тип, и никогда не число с плавающей точкой, где 0.1 + 0.2 не равно 0.3, а итог корзины может разойтись с суммой её строк. Правила округления явные и покрыты тестами на каждой границе, где деньги показываются, передаются или сохраняются. Длинная версия — в статье Почему 0.1 + 0.2 ≠ 0.3.

Правила сторов, которые ритейл-команды обнаруживают поздно

Оба стора берут комиссию с цифровых товаров, но не с физических: продавать физические товары через собственного платёжного провайдера можно, а вот подмешивание цифровых бонусов в ритейл-приложение — то место, где начинаются проблемы на ревью. Гайдлайн Apple 4.2.6 — вторая ловушка: парк тонких, почти одинаковых брендированных приложений — ровно то, что он и призван отклонять, и проектирование white-label-платформы так, чтобы она его проходила, — наша специализация, а не сюрприз на двадцатой неделе. Удаление аккаунта, декларации о данных и сроки ревью закладываются в план отдельной фазой — как и на каждой странице этого сайта.

Почему Flutter для e-commerce

ТребованиеКак это решает Flutter
Оба стора при одном бюджетеОдна кодовая база, примерно на 30–40% дешевле двух нативных витрин
Интерфейс точно по брендуFlutter рисует каждый пиксель, поэтому дизайн-система ваша, а не платформы
Быстрые сетки товаров на дешёвых телефонахКомпиляция в нативный код держит 60 fps там, где реально сидят покупатели, — на среднем Android
Скорость сезонных итерацийHot reload быстрее секунды; промо-экран выходит за дни, а не за релизные циклы
Больше одной витриныТа же кодовая база масштабируется от одного бренда до парка — см. white-label-платформу

Где нативная разработка всё ещё выигрывает: если ваша витрина по сути обёртка вокруг возможности одной платформы — сценарий, ведомый App Clip, глубокая интеграция с Wallet как сам продукт, — кроссплатформенная экономия не главное, и мы так и скажем. Общая страница услуги — разработка на Flutter.

Как мы работаем

Проект с фиксированным объёмом. Мы полностью отвечаем за поставку — дискавери, архитектура, разработка, публикация в сторах. Наш процесс разработки описывает, как это выглядит неделя за неделей.

Staff augmentation. Наши инженеры входят в вашу команду, в ваш репозиторий и спринты — см. расширение команды.

В обоих случаях смету под задачу мы присылаем в течение двух рабочих дней после того, как разберёмся в требованиях.

Сколько стоит e-commerce-приложение

Витрина — каталог и поиск, корзина и оформление заказа, интеграция платёжного шлюза, отслеживание доставки, отзывы — это отдельный тариф на странице разработки на Flutter: 4,5–8,1 млн ₽, за четыре-шесть месяцев. Мультивендорная платформа, брендированный парк приложений или глубокая интеграция с ERP и складом — это enterprise-работа, от от 8,1 млн ₽.

Это те же опубликованные тарифы, что и в таблице цен пилларной страницы — обе страницы рисуются из одних ключей, поэтому разойтись они не могут. Что двигает цифру ритейл-проекта внутри них: количество платёжных методов и рынков, какую часть каталожной машинерии уже даёт ваш бэкенд и не является ли «одно приложение» на самом деле парком.

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

Что чаще всего спрашивают команды, которые строят ритейл- и e-commerce-продукты на Flutter.

Да. Flutter рисует интерфейс сам, поэтому сетка товаров, промо-экран или кастомное оформление заказа выглядят и ведут себя одинаково на iOS и Android из одной кодовой базы — обычно на 30–40 процентов дешевле, чем разработка двух нативных витрин. Он компилируется в нативный код, что сохраняет плавность скролла на средних Android-устройствах, где на самом деле происходит заметная часть ритейл-трафика. Платформенные части — шторки Apple Pay и Google Pay, часть SDK платёжных провайдеров — доступны через platform channels: это рутинная, но реальная инженерная работа.
Наш опубликованный e-commerce-тариф покрывает каталог и поиск, корзину и оформление заказа, интеграцию платёжного шлюза, отслеживание доставки, отзывы и управление складом за четыре-шесть месяцев — точный диапазон открыт на этой странице и на странице разработки на Flutter, а не спрятан за звонком с менеджером. Мультивендорные платформы и парки брендированных приложений оцениваются как enterprise-работа. Цифру двигает в первую очередь количество платёжных методов и рынков, во вторую — то, какую часть каталожной машинерии уже даёт ваш бэкенд.
Да, через platform channels поверх собственного платёжного SDK каждой платформы — в виде нативной платёжной шторки, которую пользователи узнают. Нативные шторки конвертируют на мобильных измеримо лучше, чем формы ручного ввода карты, поэтому мы подключаем их рядом с карточным сценарием провайдера, а не вместо него. Сырой ввод карты остаётся внутри SDK платёжного провайдера, что держит ваше приложение вне зоны PCI везде, где провайдер это позволяет.
Да, при правильной архитектуре: каталог живёт на сервере, а приложение держит над ним постраничное окно, поиск выполняется на бэкенде, изображения нарезаются и кэшируются под экран, а страницы товаров мгновенно рисуются из закэшированных данных списка, пока детали грузятся следом. Провальный сценарий — не Flutter, а отношение к каталогу на сто тысяч позиций как к списку, который нужно скачать. Мы выпускали механику браузинга на масштабе маркетплейса — с мультивалютными ценами и лентами, отфильтрованными по локации.
Не всегда, и мы так и скажем, когда честный ответ — хорошо сделанный мобильный веб. Приложение окупает бюджет за счёт поверхности удержания, которой у сайта нет: пуш-уведомления об акциях и статусах заказов, иконка на домашнем экране, нативные платёжные шторки и механики лояльности, награждающие за возвращение. Если большая часть выручки — повторные покупатели, аргументы обычно сильные; если это разовый поисковый трафик, вкладывайтесь сначала в веб — его мы тоже делаем.
Да — это наш самый прямой аргумент в коммерции. Одна построенная нами кодовая база на Flutter производит больше пятнадцати полностью брендированных потребительских приложений плюс приложение мерчанта, с админ-панелью, которая запускает новый бренд без участия инженеров. Ловушка политики сторов — гайдлайн Apple 4.2.6, существующий, чтобы отклонять парки почти одинаковых приложений, и white-label-платформу нужно с самого начала проектировать так, чтобы она его проходила. Полная архитектура описана на нашей странице white-label-услуги и в сопутствующей инженерной статье.

Разбор стоимости — в статье Стоимость разработки Flutter-приложения в 2026 году, посмотрите, как устроен парк платформы лояльности, или начните с пилларной страницы разработки на Flutter.