Что на самом деле делает разработку e-commerce дорогой

Владелец бизнеса спрашивает три агентства, сколько стоит построить интернет-магазин.

Ответы приходят: $18 000, $65 000 и $190 000.

Один и тот же бриф. Те же фотографии товаров. Та же дата запуска.

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

Обычно ни то, ни другое.

Три агентства могут просто оценивать три разных продукта.

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

Но видимая витрина, это только один слой.

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

Витрина и коммерческая система могут выглядеть почти одинаково снаружи.

Мы строили и то, и другое.

Вот что реально двигает цифру.

SKU обманывает

SKU обманывает

Первый вопрос в большинстве e-commerce брифов звучит так:

Сколько у вас товаров?

Звучит как важное число.

Часто это не так.

Каталог из 5000 простых товаров, у каждого одна цена, один остаток и несколько изображений, это по сути плоский набор данных.

Импортировать его дольше, чем 500 товаров.

Но система под ним может быть относительно простой.

Теперь возьмём 500 товаров, где каждый может отличаться размером, цветом, материалом и отделкой.

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

Это не просто каталог побольше.

Это другая модель данных.

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

Разработчикам приходится думать в терминах связей.

Что меняется, когда клиент выбирает другой материал?

Меняется ли цена?

Меняется ли остаток?

Меняется ли изображение?

Можно ли вообще заказать эту комбинацию?

Должна ли она появляться в поиске?

Может ли клиент её вернуть?

Что происходит, если выбранная комбинация временно недоступна?

Количество товаров говорит, сколько информации существует.

Оно на удивление мало говорит о том, что система должна с этой информацией делать.

Рабочий пример: SHTAYER, бренд премиального домашнего текстиля. Каталог не огромный, но почти каждый товар несёт логику размера и материала, и эти атрибуты влияют на цену, доступность и на то, как клиент сужает поиск. Платформа, на которой магазин изначально запустился, в какой-то момент исчерпала место для этой логики, поэтому сейчас магазин переезжает на кастомную сборку на Laravel. Каталог не стал больше. Он стал структурнее. Проект можно посмотреть в нашем портфолио, а о решении, стоящем за таким переездом, мы писали в статье Когда бизнес перерастает WordPress?

Вариации, множитель

Вариации, множитель

Как только появляются вариации, несколько систем должны согласовываться друг с другом.

Ценообразование должно знать, что один материал стоит дороже другого.

Учёт остатков должен отслеживать правильную комбинацию.

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

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

А CMS должна позволять человеку на стороне клиента управлять всем этим, не сломав каталог случайно.

Мы видим это особенно ясно в категориях, с которыми работаем.

Премиальный домашний текстиль может нести логику размера и материала.

Ювелирка может нести металл, камень, размер и персонализацию.

Мебель может нести габариты, отделки, конфигурации и сроки изготовления.

Ни один из этих бизнесов не обязательно считает себя технически сложным.

Сложны их каталоги.

Здесь же B2B e-commerce становится другой задачей.

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

Каталог перестаёт быть списком.

Он становится инфраструктурой.

Чего клиент не видит

Чего клиент не видит

Бриф обычно описывает то, что видит клиент.

Стоимость часто живёт в том, что бизнес обслуживает за этим.

ERP.

Бухгалтерия.

CRM.

Складской учёт.

Остатки.

Доставка.

Платёжные шлюзы.

Email-автоматизация.

Налоговые сервисы.

Вопрос не просто в том, нужно ли этим системам соединиться.

Вопрос в том, как они должны себя вести, когда что-то идёт не так.

Односторонняя интеграция может быть фидом.

Двусторонняя интеграция, это контракт между двумя системами, каждая из которых считает себя правой.

Если падает фид, информация может устареть.

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

Поэтому нормальная интеграция требует большего, чем перенос данных из А в Б.

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

Для американского бизнеса налог с продаж добавляет ещё один невидимый слой.

Ставки могут различаться по штатам, округам и городам, а классификация товара может влиять на сам расчёт.

Клиент видит итоговую сумму в корзине.

За ней могут стоять налоговый сервис, классификации товаров и логика, которая должна оставаться корректной, пока заказ движется через систему.

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

Цена удобства

Цена удобства

Хостинговые платформы имеют огромный смысл для многих бизнесов.

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

Мы рекомендуем такой подход, когда он подходит бизнесу.

Проблема начинается, когда выбор платформы становится идеологией.

На малых объёмах процент с каждой транзакции может быть незначительным.

На существенных объёмах арифметика меняется.

Бизнес с оборотом $5 миллионов в год может платить тысячи долларов ежегодно только комиссий; при $20 миллионах регулярная стоимость становится заметно ощутимее. Точная цифра зависит от платформы, тарифа и платёжной структуры, но суть проста: процент остаётся процентом по мере роста выручки.

Это не значит, что кастомная разработка автоматически дешевле.

Это значит, что сравнение со временем меняется с:

Какая платформа лучше?

на:

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

Эта точка разная для каждого бизнеса.

Более широкий вопрос build-versus-buy мы разбираем в статье Уравнение «строить или покупать» изменилось.

Разработка и магазин

Разработка и магазин

Один из самых лёгких способов сделать e-commerce предложение выгодным на вид, это оценить видимую разработку и оставить операционную работу на потом.

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

Существующие URL может понадобиться сопоставить и перенаправить, чтобы бизнес не потерял поисковую видимость, накопленную за годы.

Аналитику и e-commerce трекинг нужно настроить корректно.

Платежи и расчёт налогов нужно протестировать на реальных транзакциях.

Кого-то на стороне клиента нужно обучить работать с системой.

Ничего из этого не делает особо впечатляющий слайд в презентации.

Всё это определяет, работает ли магазин на самом деле.

Именно поэтому мы различаем запуск сайта и запуск бизнес-системы.

Магазин, который выходит в жизнь без подготовленных данных, трекинга, платёжной логики, миграции и операционных процессов, не закончен.

Он просто виден.

То же касается сроков.

Относительно простой магазин на теме может запуститься за недели.

Кастомная коммерческая система с реальными интеграциями может занять несколько месяцев.

Но даже эти диапазоны скрывают ещё одну переменную: насколько стабильны требования?

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

Расходы после запуска

Расходы после запуска

E-commerce ближе к эксплуатации системы, чем к владению сайтом.

Есть хостинг.

Безопасность.

Обновления.

Мониторинг.

Исправление ошибок.

Сторонние сервисы.

Приложения.

API-зависимости.

Изменения платформы.

И со временем новые требования.

Поэтому полезная модель планирования учитывает стоимость эксплуатации системы после запуска, а не только начальный бюджет разработки. Распространённый ориентир, примерно 10-20% от стоимости первоначальной сборки ежегодно, покрывающие хостинг, безопасность, обновления, мониторинг и исправления, тогда как хостинговые платформы распределяют эти расходы иначе, через подписки и приложения.

Психология регулярных расходов любопытна.

Одно инженерное решение за $20 000 ощущается крупным.

Пятнадцать приложений по $50 в месяц нет.

Пока их не станет пятнадцать.

И каждое приложение, это ещё и зависимость.

Оно может изменить цену.

Оно может перестать поддерживаться.

Оно может конфликтовать с другим приложением.

Оно может сломаться после обновления платформы.

Именно поэтому дёшево запустить и дёшево владеть, это разные вопросы.

Разброс в десять раз

Разброс в десять раз

Теперь изначальный вопрос про $18 000 против $65 000 против $190 000 становится понятнее.

Иногда низкая смета просто ошибочна.

Иногда высокая смета завышена.

Но часто разница гораздо конкретнее.

Низкая смета может считать витрину.

Высокая смета может считать систему под ней.

Одно агентство может предполагать простые товары, минимум интеграций и чистую миграцию.

Другое могло спросить, что происходит, когда:

• у клиента контрактные цены
• остатки меняются на складе
• у товара десятки комбинаций
• нужно посчитать налог
• заказ должен пройти через несколько систем
• существующие URL должны пережить миграцию
• бизнесу нужна надёжная отчётность после запуска

Это не абстрактные различия.

Это строки сметы.

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

Именно поэтому discovery так важен.

Смета надёжна ровно настолько, насколько хороши вопросы, заданные до неё.

И есть различие, которое стоит проговорить очень ясно:

Дешёвая смета не обязательно плохая смета. Дорогая смета не обязательно хорошая.

Простой бизнес не должен платить за сложность, которая ему не нужна.

Сложный бизнес, однако, должен насторожиться от сметы, которая каким-то образом умудрилась не оценить уже существующую у него сложность.

Обдуманные покупки

Обдуманные покупки

Есть ещё одна переменная, которая мало связана с размером каталога.

Как клиент принимает решение?

Одни товары покупают почти сразу.

Другие обдумывают днями, неделями или месяцами.

Клиенту, покупающему знакомый недорогой товар, обычно полезен кратчайший надёжный путь к оформлению.

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

Это не просто дополнительные страницы.

Это другая архитектура.

Это важно, потому что советы по e-commerce часто подают так, будто оптимизация конверсии универсальна.

Снижай трение.

Сокращай путь.

Убирай отвлечения.

Делай оформление быстрее.

Часто это хорошие принципы.

Но клиент, покупающий обдуманно, не обязательно хочет кратчайший путь.

Ему может быть нужна информация, которая делает следующий шаг комфортным.

Именно поэтому ювелирный магазин, бренд премиального текстиля и розница повседневных товаров могут все быть успешными e-commerce бизнесами, требуя при этом совершенно разного цифрового опыта.

Мы разбирали это в статьях Почему luxury e-commerce нарушает все правила conversion optimization и Как мы проектируем e-commerce: от объектов к опыту.

Оценивать магазин обдуманной покупки так, будто это магазин повседневных товаров, одна из самых дорогих доступных ошибок.

Рабочий пример: Magerit, испанский ювелирный дом, чьи изделия организованы не только по товарным категориям, но и по коллекциям, построенным вокруг мифологии, природы и четырёх стихий. Это даёт клиенту два законных входа: через продукт или через историю. Интерфейс должен был поддержать оба, плюс отдельный раздел детских украшений, где покупатель, язык и процесс принятия решения совершенно другие. Ничего из этого не проблема размера каталога. Это проблема архитектуры. Кейс есть в нашем портфолио.

География и расходы

География и расходы

Ставки разработки существенно различаются по географии.

Это законный фактор при сравнении предложений.

Но почасовая ставка, это не то же самое, что ценность проекта.

Более низкая ставка не означает автоматически более низкую компетентность.

Более высокая ставка не означает автоматически лучшую инженерию.

Более полезный вопрос звучит так:

Что именно я получаю за эту ставку?

Сколько discovery?

Какую архитектуру?

Какие интеграции?

Какую миграцию данных?

Какое QA?

Что происходит после запуска?

Что происходит, когда требования становятся конкретнее?

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

Мы не подаём это как скидку.

Суть просто в том, что структура расходов и качество, это не одна и та же переменная.

И география не решает фундаментальную проблему.

Команда в любой точке мира может очень эффективно построить не ту систему.

Защита от этого, discovery и архитектура.

Команда может быть недорогой и всё равно построить не то. Команда может быть дорогой и всё равно построить не то.

Важная часть, понять бизнес до того, как открыли редактор кода.

Что спросить первым

Что спросить первым

Прежде чем сравнивать e-commerce предложения, задай вопросы, которые вскрывают допущения за цифрой.

• Товары простые или конфигурируемые? Кто определил модель данных товара?
• Какие интеграции включены? Они односторонние или двусторонние?
• Как обрабатывается налог с продаж?
• Включена ли миграция данных о товарах? Включает ли она чистку и переструктурирование?
• Включена ли SEO-миграция? Кто составляет и проверяет карту редиректов?
• Какая аналитика и e-commerce трекинг включены?
• Во что реально обойдётся первый год владения? Включая хостинг, приложения, лицензии и сторонние сервисы.
• Что происходит в первые восемь недель после запуска?

И, пожалуй, самый показательный вопрос:

Какие допущения вы сделали, чтобы прийти к этой цене?

Агентство, которое может ответить на эти вопросы ясно, вероятно, думало о проекте.

Агентство, которое не может, возможно, просто оценивает допущение.

Настоящая цена e-commerce

Разработка e-commerce становится дорогой, когда сложен бизнес за магазином.

Не обязательно потому, что у него тысячи товаров.

Потому что эти товары ведут себя по-разному.

Потому что клиенты видят разные цены.

Потому что остатки живут в другом месте.

Потому что заказы должны двигаться между системами.

Потому что нужно считать налог.

Потому что существующие URL накопили ценность.

Потому что клиентам нужно больше информации перед покупкой.

Потому что бизнесу нужно, чтобы система продолжала работать после запуска.

И иногда потому, что бизнес перерос платформу, с которой начинал.

Именно поэтому мы скептичны к универсальным прайс-листам на e-commerce.

Не существует осмысленной цены на «интернет-магазин» в отрыве от контекста.

Есть цена конкретного каталога, конкретной бизнес-модели, конкретного клиентского пути и конкретного набора операционных требований.

Поэтому правильный вопрос не:

Сколько стоит интернет-магазин?

А:

Что наш бизнес реально требует от системы?

Как только это понятно, цену становится намного легче объяснить.

И намного труднее подделать.