Shopify dev: где команда обычно теряет деньги на кастоме и как это поймать до спринта

Shopify dev: где команда обычно теряет деньги на кастоме и как это поймать до спринта

Чаще всего перерасход начинается не с кода, а с расползания требований: «чуть-чуть» фильтров, персонализация, локализация, подписки, B2B-логика. В итоге frontend уже не про витрину, а про набор исключений, а backend — про вечную поддержку.

Перед стартом разложите задачу на 4 слоя: 1) витрина и скорость рендера, 2) корзина и checkout, 3) интеграции с ERP/CRM/фулфилментом, 4) контент и SEO. Если хотя бы один слой меняется каждый месяц, не тащите это в hardcode — сразу закладывайте конфиг, а не правки руками в компонентах.

Для Shopify dev критично не путать «быстро собрать» и «дёшево владеть». Хрупкие места почти всегда одни и те же: дубли логики в теме и приложении, тяжёлые скрипты, переусложнённые апдейты каталога, отсутствие теста на мобильную корзину. Именно там потом утекает конверсия и время команды.

Хорошее правило: если фича не влияет на AOV, CR или возвраты, не делайте её кастомной без причины. Сначала проверьте, закрывает ли это нативный Shopify или лёгкий app layer, и только потом идите в разработку. Иначе вы платите за сложность дважды: в спринте и в поддержке.