Как создать приложение для онлайн-торговли: от MVP до интеграции с 1С

Приложение для онлайн-торговли создают в пять шагов: описывают бизнес-процесс — каталог, корзина, оплата, доставка, — выбирают платформу (нативную, кроссплатформенную или 1С:Мобильную), настраивают синхронизацию с 1С, чтобы остатки и цены совпадали с учётной системой, тестируют на реальных заказах и публикуют в App Store и Google Play. Срок — от 2-3 месяцев, бюджет — от 500 000 рублей.

📱 Из чего состоит приложение для онлайн-торговли

Минимальный работающий продукт закрывает пять задач: показать товар, посчитать корзину, принять оплату, подтвердить заказ и держать клиента в курсе статуса доставки. Дальше начинается развилка. Розничному магазину хватит каталога, фильтров и push-уведомлений о скидках. Оптовой компании нужны персональные прайсы, лимиты отгрузки по контрагенту и история взаиморасчётов — это уже логика B2B-приложения с интеграцией 1С, где у каждого клиента свои условия и минимальная партия заказа. У обоих сценариев одна общая уязвимость: приложение обязано видеть те же остатки, цены и статусы заказов, что видит менеджер в учётной системе, иначе покупатель оформит заказ на товар, которого физически нет на складе.

• ✓каталог с фильтрами и поиском
• ✓корзина и оплата — эквайринг, СБП
• ✓push-уведомления о статусе заказа
• ✓личный кабинет с историей покупок
• ✓синхронизация остатков и цен с 1С в реальном времени

Технологию выбирают под задачу. Нативная разработка под iOS и Android даёт лучшую скорость и полный доступ к камере и геолокации — это важно для служб доставки, где курьер отмечает точку на карте. Кроссплатформенный стек экономит бюджет за счёт одной кодовой базы под обе платформы и подходит, когда нужно быстрее выйти на обе аудитории. А для компаний, где вся торговая логика уже описана в 1С, есть отдельный путь — 1С:Мобильная платформа, которая переиспользует бизнес-логику учётной системы вместо того, чтобы писать её заново на мобильном стеке. В команду при этом входят не только мобильные разработчики: нужен бэкенд-специалист для обмена данными, дизайнер интерфейса и специалист по 1С, который знает структуру конкретной базы клиента. Обычно на старте достаточно двух-трёх специалистов и одного менеджера проекта — команду расширяют, когда добавляются новые модули вроде программы лояльности или интеграции с курьерской службой.

⚠️ Почему возникают сбои при запуске приложения для онлайн-торговли

Мебельная компания в Мытищах запустила приложение в октябре: 12 000 позиций в каталоге, три склада, сезонная распродажа через две недели после релиза. Каталог в приложении обновлялся из выгрузки раз в сутки, но менеджеры в 1С меняли цены и остатки по нескольку раз в день. К началу распродажи разрыв стал критичным: клиент оформлял заказ на диван по вчерашней цене, которого уже не было на складе. Поэтому колл-центру за первую неделю распродажи пришлось вручную обзвонить больше 200 заказов, извиняясь и предлагая замену.

Ставка здесь не абстрактная. Компания либо продаёт товар себе в убыток по устаревшей цене, либо отменяет заказ и теряет доверие клиента, который только что видел товар в наличии. При обороте в несколько миллионов рублей в месяц даже 5% отменённых заказов — это упущенная выручка и клиент, который в следующий раз закажет у конкурента в соседней вкладке браузера.

Три типичные причины расхождения

Первая — выгрузка каталога раз в сутки вместо синхронизации по событию или расписанию. Вторая — приложение обращается напрямую к боевой базе 1С без промежуточного сервиса, из-за чего база тормозит под нагрузкой в пиковые часы и тормозит заодно работу бухгалтерии и менеджеров, которые в это же время закрывают документы. Третья — оплата и подтверждение заказа не связаны с фактическим резервированием остатка в 1С, поэтому два клиента могут одновременно купить последнюю единицу товара, а склад узнаёт об этом только при сборке заказа.

🔧 Как исправить ошибки интеграции с 1С и синхронизации каталога

Ночную выгрузку заменяют обменом по расписанию каждые 5-15 минут или синхронизацией по событию: документ проведён в 1С — уведомление ушло в приложение через очередь сообщений. Обмен данными выносят на промежуточный сервис или API, чтобы мобильное приложение не обращалось к боевой базе напрямую и не создавало на неё лишнюю нагрузку в рабочие часы. Товар резервируют в 1С в момент, когда клиент кладёт его в корзину, на 15-20 минут — этого достаточно, чтобы завершить оплату, но не даёт остатку зависнуть в резерве на часы, если клиент передумал. Для оплаты подключают эквайринг или СБП напрямую в приложении, а статус платежа синхронизируют с документом заказа в 1С автоматически, без ручного подтверждения менеджером. Такая интеграция — работа на стыке 1С и мобильной разработки: нужна команда, которая закрывает и код приложения, и обмен данными с учётной системой, и этим отдельно занимается интеграция приложения с 1С.

🔁 Что делать, если сбои с синхронизацией повторяются после доработок

Интеграцию доработали, вроде исправили, но на следующем пиковом событии — например, в чёрную пятницу — всё повторилось. Здесь помогает не повторный патч наугад, а диагностика по шагам. Логируют каждый обмен с 1С с таймстампом и кодом ответа, чтобы увидеть, где именно рвётся цепочка: сеть, база 1С, очередь заданий или код самого приложения. Перед следующим пиковым событием проводят нагрузочный тест на объём заказов в 1,5-2 раза выше прошлого пикового значения — это выявляет узкое место до того, как его найдут реальные покупатели. Часто причина не в приложении, а в мощности сервера, на котором крутится сама база 1С: она физически не успевает отвечать на возросшее число одновременных запросов от кассы, склада и мобильного приложения сразу. В этом случае разговор смещается из плоскости кода в плоскость инфраструктуры — нужен сервер с запасом ресурсов под пиковую нагрузку и с возможностью быстро нарастить мощность на сезон, а не разовое ускорение обмена, которое перестанет помогать при следующем росте трафика.

✅ Как предотвратить провал следующего запуска

Перед стартом или крупным обновлением стоит закрыть пять пунктов. Поэтапный релиз: сначала на 50-100 постоянных клиентов, потом на всех — так узкие места видно до того, как на них попадёт весь поток заказов. Нагрузочное тестирование перед каждым сезонным пиком, а не только перед первым запуском, потому что структура каталога и число клиентов со временем меняются. Резервный канал приёма заказов на случай сбоя приложения — телефон или сайт, чтобы продажи не останавливались полностью даже при технической проблеме. Проверка соответствия 152-ФЗ при хранении телефонов, адресов и данных карт клиентов: банк-эквайер и регулятор одинаково жёстко реагируют на утечку персональных данных, а штраф и репутационные потери обходятся дороже, чем аудит на этапе разработки. И фиксация SLA с подрядчиком на реакцию при сбое в первый месяц после релиза, когда нагрузка ещё непредсказуема, а покупатели не прощают технических проблем в приложении так же легко, как на сайте.

🚀 Как подготовить приложение к публикации в App Store и Google Play

Перед публикацией нужны аккаунты разработчика в обоих магазинах, комплект скриншотов под разные размеры экранов, описание приложения и политика конфиденциальности — без неё модерация Google и Apple отклонит заявку, если приложение запрашивает геолокацию, камеру или хранит данные о заказах. Apple проверяет заявку от одного до трёх дней и может вернуть её на доработку из-за мелочей: неработающей кнопки, тестового аккаунта без доступа к каталогу, несоответствия описания и реального функционала. Поэтому тестовый аккаунт для модератора готовят заранее, с наполненным каталогом и рабочей оплатой в песочнице. После публикации начинается вторая часть работы — обновления под новые версии iOS и Android, мониторинг падений и обработка отзывов, где чаще всего жалуются как раз на несовпадение цены в приложении и на кассе. Первый месяц после релиза обычно самый нагруженный на поддержку: пользователи находят сценарии, которые не всплыли на тестировании — например, оформление заказа без интернета или повторный ввод одного и того же промокода.

💰 Сколько стоит и сколько занимает разработка приложения для онлайн-торговли

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

Отдельно стоит проверить, планируете ли включать приложение в реестр российского ПО: это даёт льготы по налогу на прибыль и НДС для правообладателя, но требования к архитектуре и правам на исходный код нужно закладывать на старте проекта, а не после релиза — иначе экспертиза реестра потребует переделок.

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

Сколько стоит разработка приложения для онлайн-торговли?

От 500 000 рублей за решение с базовым каталогом, корзиной, оплатой и синхронизацией с 1С. Итоговая сумма зависит от числа интеграций, экранов и того, нужны ли сразу обе платформы — iOS и Android.

Сколько времени занимает разработка приложения?

От 2-3 месяцев для решения на 1С:Мобильной платформе до 4-6 месяцев для нативного приложения или B2B-решения с полной интеграцией в учётную систему и персональными прайсами для контрагентов.

Обязательно ли интегрировать приложение с 1С?

Если товары, цены и остатки ведутся в 1С — да. Без синхронизации в реальном времени каталог в приложении быстро расходится со складом, и компания либо продаёт то, чего нет, либо теряет заказы на актуальный товар.

Приложение уже запущено, но постоянно сбоит при наплыве заказов — что делать?

Сначала логировать каждый обмен с 1С, чтобы найти узкое место — сеть, базу или очередь запросов. Затем провести нагрузочный тест на объём в 1,5-2 раза выше пикового и при необходимости увеличить мощность сервера с 1С.

Нужно ли включать приложение в реестр российского ПО?

Не обязательно, но выгодно из-за льгот по налогу на прибыль и НДС. Требования к архитектуре и правам на исходный код нужно закладывать на старте проекта, иначе экспертиза реестра потребует переделок после релиза.