Разработка под e-commerce *

Уверен, у многих есть хотя бы один пет-проект, перспективный B2B SaaS, CRM, другими словами — сервис, который когда-нибудь обязательно выстрелит. В процессе разработки у многих стильных, модных и молодежных проектов рано или поздно появляется вопрос: «А что если добавить генерацию изображений или видео?». На первый взгляд все выглядит просто: берем Comfy UI, собираем workflow, выбираем модели — и готово. Локально все действительно можно собрать за один вечер.

Проблемы начинаются ровно в тот момент, когда решением пользуетесь не только вы. Первый пользователь ждет 20-30 секунд, второй стоит в очереди, остальные уже получили свои тайм-ауты, а вы внезапно ловите себя на том, что читаете документацию про Kubernetes и настраиваете балансировку запросов, вместо того, чтобы сконцентрироваться на развитии продукта... И вот тут уже развертывание Comfy UI кажется не настолько простой задачей как в начале.

Если вам знакома эта ситуация или вы только планируете добавить генеративный ИИ в свое приложение, эта статья для вас. Покажу, как превратить Comfy UI workflow в API, которым можно пользоваться из любого приложения, не поднимая инфраструктуру и не привлекая внимания санитаров.

Мы делаем сервис генерации карточек для маркетплейсов и посмотрели на свои данные: более 7 500 генераций. Внутри — почему «идеальный промпт» — миф и пользователи мыслят диффами, когда селлеры на самом деле делают контент, и пять инженерных историй с кодом: асинхронные джобы, недоверенный base64, каскад моделей, thought_signature у Gemini и список с двумя хозяевами.

Привет, Хабр! Это Сергей Перевозчиков, основатель агентства контекстной рекламы «КонтекстЛаб».

Когда ко мне обратился производитель хозяйственных металлоконструкций, у него уже был успешный опыт продаж на Wildberries. Но на Ozon всё оказалось совсем иначе: компания терпела убытки, несмотря на хороший ассортимент и опыт работы с маркетплейсами.

Разбираясь в ситуации, мы обнаружили сразу несколько проблем: слабые карточки товаров, непонимание принципов работы площадки и новые правила логистики, которые серьёзно влияли на экономику продаж.

Мы полностью переработали карточки товаров, улучшили их для поиска и сделали ставку на продвижение самых перспективных позиций, которые могли «потянуть» за собой остальные продажи.

В результате кликабельность карточек выросла в два раза, а компания получила дополнительно 3,8 млн рублей прибыли в месяц. В этом кейсе я покажу четыре шага, которые помогли перевести бизнес на Ozon из убыточного в прибыльный.

Помните интернет-магазины, где на странице контактов висел номер ICQ? Зелёный цветок показывал, что менеджер онлайн и может ответить на запрос.  А про квитанцию Сбербанка в способах оплаты? Её нужно было распечатать, заполнить и отнести в отделение. Та ещё интернет-торговля.

В 2000-х всё стало иначе. ICQ сменили на чаты поддержки. Квитанции ушли в музей. Потом Price.ru и первые прайс-агрегаторы уступили место маркетплейсам. Интерфейсы стали лучше, оплата быстрее, доставка привычнее. Сейчас уже виден следующий слой: товар может стать ответом AI-ассистента на запрос покупателя. А дальше начнётся новая борьба за то, какие товары попадут в ответ машины.

Привет, Хабр. Меня зовут Дмитрий Смирнов. Я более 20 лет занимаюсь развитием бизнеса в ритейле, FMCG и смежных отраслях. В этой статье хочу описать эволюцию ритейла не как историю красивых интерфейсов, а как историю потери контроля. Кто видит покупателя? Кто управляет карточкой? Кто решает, какой товар будет наверху? И что будет, когда первый контакт с покупателем уйдёт от маркетплейса к AI-ассистенту?

Привет, Хабр!

Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Последние пять лет продавцы массово шли на маркетплейсы — казалось, это единственно верная стратегия. К 2026 году картина уже изменилась. По данным Sellmonitor, еще за 2024–2025 годы число продавцов на Wildberries и Ozon сократилось на 24,5%.

Значит ли это, что маркетплейсы умирают? Нет. Значит ли это, что работать только на маркетплейсе в 2026 году — рискованно? Уже да!

Последние несколько лет я собираю платёжные интеграции для продуктов, которые банки вежливо называют «high‑risk». Под «high‑risk» обычно попадают: iGaming / betting dating (особенно adult dating) crypto onboarding / exchange ramps nutra / supplements travel / subscriptions с free‑trial моделью forex / trading / микрозаймы

Один проект — подписочный сервис на NestJS/TypeORM с рекуррентными списаниями через SOAP‑шлюз прибалтийского банка‑эквайера. Второй — кредитный продукт на Python/FastAPI, где под капотом крутятся три локальных PSP одновременно. Обе системы живут в проде, обе списывают реальные деньги с реальных карт, и обе научили меня вещам, которых нет ни в одной документации шлюза.

Эта статья — не теория из учебника по финтеху. Это то, что я бы хотел прочитать до того, как первый раз задеплоил cron, который умеет списывать деньги.

Разработчики используют GitHub Copilot, Claude Code, Cursor, Codeium, Tabnine, локальные LLM и внутренние AI-агенты не только для генерации тестов или рефакторинга, но и для написания бизнес-логики, инфраструктурного кода, CI/CD-конфигураций, миграций БД и API-контрактов.

Vibe coding действительно ускоряет разработку, но с точки зрения информационной безопасности он меняет саму модель контроля. Организация начинает терять прозрачность в двух критичных точках: какие данные уходят в ИИ-модель, а также откуда взялся сгенерированный код, насколько он безопасен и кто фактически принял инженерное решение.

В этой статье разберём: что ломается в привычной модели DevSecOps при переходе к vibe coding; какие новые риски появляются у AI-сгенерированного кода; почему контролировать нужно не только код, но и все взаимодействия разработчиков и AI-агентов с LLM.

"Если вашего бизнеса нет в Интернете, то вас нет в бизнесе! Скоро на рынке останется два вида компаний: те, кто в Интернете и те, кто вышел из бизнеса." 

А потом вдруг интернета не стало и нужно было срочно что-то придумать для работы нашей ERP-системы оффлайн

Электронная коммерция долго училась понимать покупателя через данные: что человек искал, на какие карточки нажимал, где бросал корзину, как реагировал на скидки и какие товары покупал вместе. Эта аналитика стала основой онлайн-торговли, но у нее есть ограничение — она почти всегда объясняет то, что уже произошло.

Проблема в том, что рынок меняется слишком быстро. Новая цена, рекламный креатив, карточка товара или запуск категории часто проверяются уже «в бою»: когда бюджет потрачен, товар запущен, а команда только начинает понимать, как на это реагируют покупатели. При этом цена ошибки растет вместе с конкуренцией, стоимостью трафика и скоростью обновления ассортимента. Как отмечают в Market Logic, во многих компаниях клиенты меняются быстрее, чем обновляются продуктовые дорожные карты и результаты классических исследований.

На этом фоне в индустрии начинает формироваться новый подход — синтетические покупатели (synthetic customers, или synthetic buyers). Это модели искусственного интеллекта (ИИ), которые имитируют вероятную реакцию реальных клиентов: их предпочтения, сомнения, отношение к цене, рекламе, интерфейсу или самому продукту. Такие модели помогают заранее проверять возможные сценарии: как аудитория воспримет новый товар, вызовет ли промо доверие, где пользователь может отказаться от покупки и почему определенный сегмент не видит ценности предложения.

В PwC называют такой подход «невидимой фокус-группой». Предприниматели в сфере e-commerce получают возможность тестировать стратегию до выхода на рынок — не только через опросы и пилоты, но и через симуляцию поведения покупателей на основе данных.

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

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

В этой статье я разберу проблему по слоям: откуда физически берётся расхождение, какие есть уровни решений (от коробки до event-driven на Go), и почему модный ответ «поставьте Kafka» для одного селлера почти всегда оверкилл. Будет код и будут цифры.

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

Дальше обычно появляется VPN до нужного региона, и на этом задача считается решённой. На практике решённой она не считается — просто проблема переезжает в то место, где её не видно.

Привет, Хабр! На связи Екатерина Серикова и Глеб Дмитриев, мы QA-инженеры в команде Авито Sales. В этой статье мы расскажем, как выстроили процесс обеспечения качества в Распродаже, где сроки нельзя сдвигать, а нагрузка на корчасть почти 2 млн RPM, а цена бага очень высока.

Это не история про «идеальный процесс». Она скорее про рабочую систему, которая помогает не сгореть команде и не терять качество, когда QA в проекте один, а разработчиков восемь.

Распродажа на Авито, где 120 млн пользователей, — это всегда высоконагруженные сценарии без права на ошибку. Поэтому в статье мы объясняем, почему важно подключать QA ещё на этапе идеи, а не тестирования. Перекладывание какой части задач на разработку только ускоряет общий процесс? Что можно скормить ИИ, а что следует выполнять самим? Для чего разделять Seller и Buyer контуры?

Здесь всё на личном опыте, по делу и понятно.

Привет, Хабр! Это Сергей Перевозчиков, основатель агентства контекстной рекламы «КонтекстЛаб». Когда ко мне обратился производитель деревянных игрушек, главной проблемой была не выручка, а экономика продаж. Я часто вижу такую ситуацию на маркетплейсах: продажи вроде есть, а прибыли почти нет, потому что бизнес не считает реальные показатели по товарам и не замечает скрытые возможности для роста.

Мы внимательно разобрали ассортимент, посчитали экономику каждого товара и нашли точки роста, которые раньше оставались незамеченными. В результате клиент смог не просто повысить прибыльность, но и создать продукт с высокой добавленной ценностью — настолько высокой, что покупатели были готовы платить 2 000 рублей за изделие из дерева, которое на первый взгляд кажется очень простым. Итогом этой работы стал рост бизнеса в 14 раз.

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

Привет, Хабр! Это Сергей Перевозчиков, основатель агентства контекстной рекламы «КонтекстЛаб». Когда ко мне обратился ювелирный бренд Vesna Jewelry, ситуация была непростой. На Ozon приходилось конкурировать с тысячами продавцов, дорогие украшения продавались слабо, а выручка практически не росла. Покупатели постоянно сравнивали товары с более дешёвыми аналогами и долго принимали решение о покупке.

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

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

Этот кейс хорошо показывает, что рост продаж не всегда требует радикальных перемен — иногда достаточно сосредоточиться на самых прибыльных товарах и правильно представить их покупателю.

Как мы спасали Magento 2 с 1 млн товаров и 10 млн CMS страниц от 504 ошибок.

Разбор реального кейса оптимизации Magento 2-магазина с более чем 1 миллионом товаров и 10 миллионами CMS-страниц. Покажу, почему возникали ошибки 504 Gateway Timeout, какие узкие места были обнаружены в архитектуре, и как использование Redis, Varnish, MariaDB и OpenSearch позволило добиться стабильной работы системы под высокой нагрузкой.

Привет, Хабр!

Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Пару месяцев назад у меня возник вопрос: как интернет-магазины применяют маркетинговые фишки и насколько используют потенциал наших решений? За основу мы взяли каталог с 1849 сайтами, которые запускали мы и наши партнеры.

Написали парсер, прогнали через него 852 отобранных интернет-магазина по 30 критериям, часть сайтов дополнительно проверили вручную по 100+ параметрам. Результат не удивил — но конкретные цифры все равно оказались показательными.

6 месяцев. Это сколько мы строили продукт с внешним разработчиком. Потом я психанула и сделала за 3 дня сама с помощью AI. Дальше — что я поняла из этого опыта.

Эта статья — не «AI заменит разработчиков». Это про другое — про то, как методология работы меняется, когда у тебя есть AI как партнер.

По данным исследования, 69% интернет-магазинов в периоды высокого трафика сталкиваются со снижением скорости работы сайта, 38% — со сбоями отдельных функций, а четверть — с полной остановкой сайта. В сезон под ударом вся инфраструктура.

Меня зовут Эдуард, я руковожу отделом DevOps и отвечаю за сопровождение проектов по SLA 24/7 в компании KISLOROD. Сегодня расскажу о том, как пиковая нагрузка системы влияет на интернет-магазины и как готовить бизнес к дню икс.

IWANT - наш собственный fashion-магазин. Несколько лет он жил на InSales: на старте это правильный выбор: быстро, без разработки, всё из коробки. Но в какой-то момент мы уперлись в потолок платформы: каждый нужный модуль - это либо платное приложение, либо «так нельзя». Мы посчитали и решили перевезти магазин на собственный движок.

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

Привет, Хабр!

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

Этим я занимаюсь на работе, дома, в отпуске — везде. Такой уж человек.

И вот появилась возможность спокойно заняться старыми пет‑проектами и наконец реализовать давнюю идею: написать простую базу для создания AI‑агента, максимально упростив архитектуру и сделав её удобной для быстрого расширения под собственные задачи.

Если коротко — хочу сделать не «революционный AGI», а понятный конструктор, на основе которого любой разработчик сможет собрать своего личного ассистента.