FirstLab

Как выбрать сайт и из чего складывается цена

Цена сайта не «сколько стоит сделать страницу», а сколько стоит риск ошибки на старте. Разбираем конструкторы, CMS и самопис без мифов и без «единственно верного» стека.

Обсудить задачу

Три пути

Нет правильной технологии. Есть задача бизнеса, горизонт и бюджет риска

  • Конструкторы

    Когда уместно

    Лендинг, быстрый тест оффера, небольшой объём контента. Tilda, Webflow, Framer, Wix.

    Плюсы

    • Быстрый старт и ниже чек на входе
    • Клиент может править тексты без разработчика
    • Достаточно для проверки спроса

    Ограничения

    • Лимиты интеграций и кастомной логики
    • SEO, скорость и vendor lock-in
    • Сложнее масштабировать под Ads, CRM и рост
  • CMS и готовые решения

    Когда уместно

    Блог, каталог, типовой e-commerce. WordPress, Shopify и подобные.

    Плюсы

    • Привычная админка и экосистема плагинов
    • Быстрее собрать стандартный магазин
    • Много готовых сценариев «из коробки»

    Ограничения

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

    Когда уместно

    Конверсионный продукт, кастомная логика, контроль скорости и аналитики. Например Next.js.

    Плюсы

    • Гибкость под бизнес-процесс
    • Performance и чистая аналитика под CPL/CPA
    • Ниже долгосрочная стоимость владения

    Ограничения

    • Дороже старт
    • Нужна компетентная команда
    • Без брифа и приоритетов легко раздуть скоуп

Честный fit важнее тренда. Конструктор не «плохой», а самопис не «всегда лучше».

Из чего складывается цена

Прайс «от» в тарифах: ориентир. Ниже факторы, из-за которых смета растёт или падает

  1. Discovery и бриф

    Цели, аудитория, структура страниц, приоритеты. Без этого любая «дешёвая» оценка это лотерея.

  2. UX под конверсию

    Не «красивый макет», а путь пользователя: оффер, CTA, формы, доверие. Это влияет на CPL сильнее цвета кнопки.

  3. Дизайн и адаптив

    Количество уникальных экранов, состояния, мобильная версия. Больше экранов: больше объём работы.

  4. Разработка и интеграции

    CRM, оплата, Telegram, пиксели, личный кабинет. Каждая интеграция это отдельный риск и время.

  5. Аналитика

    GA4, события, готовность отчитываться в CPL/CPA. Без этого реклама «летает вслепую».

  6. SEO-база, контент, миграция

    Тексты, перенос со старого сайта, редиректы. Часто выпадает из «дешёвых» КП.

  7. Тесты, запуск, обучение

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

  8. Поддержка после сдачи

    Кто правит баги, обновляет зависимости, добавляет страницы. В дешёвых предложениях это обычно «потом».

Скрытые расходы

  • Переделки из-за слабого брифа и смены требований посреди проекта
  • Переписывание лендинга под рекламу после первых тестов
  • Подписки конструктора, плагины, лимиты тарифа хостинга
  • Потерянные лиды из-за медленного сайта или сломанной аналитики
  • Смена подрядчика: онбординг, отсутствие кода, повторная работа

Компетенция экономит бюджет

Опытная команда закрывает вопросы до того, как они станут переделками. Дешёвый подрядчик продаёт часы, компетентный снимает неопределённость

  1. Воронка и CTA на старте

    Не переделываем структуру после запуска Ads. Сразу проектируем под заявку.

  2. События аналитики в ТЗ

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

  3. Скорость под рекламу

    Медленный сайт съедает CPL. Закладываем performance до сдачи, а не после жалоб.

  4. Кто владеет кодом и доменом

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

  5. Админка vs ручные правки

    Договариваемся, что клиент меняет сам, а что через команду. Без сюрпризов в поддержке.

  6. Масштаб каталога и логики

    Спрашиваем про рост заранее: 20 SKU сегодня vs 2000 через год требуют разных архитектур.

Когда что выбирать

Короткие сценарии для малого и среднего бизнеса

  • Тест ниши / один оффер

    Конструктор или лёгкий лендинг. Цель: проверить спрос, а не построить платформу.

  • Товарка под трафик

    Лендинг под Meta / TikTok: оффер, форма, пиксели, быстрый запуск. Смотрите блок «Товарка» в услугах.

  • Каталог и оплата

    Нужен полноценный интернет-магазин. Ниже: когда Shopify / CMS, а когда самопис, и из чего складывается смета.

  • Бренд и длинный горизонт

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

  • Сайт уже есть, нужны лиды

    Не обязательно новый сайт. Часто достаточно рекламы и правок конверсии. Смотрите тарифы на рекламу.

Интернет-магазин

Каталог, корзина и оплата: когда это нужно, какой стек выбирать и почему смета магазина выше лендинга

Когда нужен магазин, а когда хватит лендинга

  • Достаточно лендинга

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

  • Нужен магазин

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

  • Гибрид на старте

    Лендинг под рекламу, ограниченный каталог позже. Не стройте полный checkout «на всякий случай», если спрос ещё не подтверждён.

Shopify / CMS или самопис

  • Shopify или готовая CMS

    Типовой checkout, стандартные доставки и оплаты, привычная админка. Хорошо, когда процесс близок к «коробке» и кастом минимальный.

  • Самописный магазин

    Нестандартная воронка, свои правила цен и наличия, глубокие интеграции, жёсткие требования к скорости и аналитике под Ads. Дороже на старте, гибче на дистанции.

  • Как выбирать

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

Из чего складывается цена магазина

Помимо дизайна и вёрстки в смету входят процессы продажи, а не только «страницы»

  1. Каталог и карточка товара

    Категории, фильтры, варианты (размер, цвет), медиа, SEO-поля. Объём растёт с количеством SKU и сложностью атрибутов.

  2. Корзина и оформление

    Шаги checkout, валидация, сохранение корзины, ошибки оплаты. Каждый лишний шаг или исключение добавляет работу.

  3. Оплата

    Платёжные провайдеры, способы оплаты, тестовые / боевые кабинеты, обработка статусов и чеков.

  4. Доставка и наличие

    Перевозчики, самовывоз, зоны, тарифы, остатки. Логика «есть на складе» часто сложнее кнопки «Купить».

  5. Админка заказов

    Статусы, менеджеры, комментарии, экспорт. Кто и как ведёт заказы после покупки, нужно знать до старта разработки.

  6. Фиды и аналитика под Ads

    Merchant / товарный фид, события purchase, соответствие цен и наличия в рекламе. Без этого Shopping и ремаркетинг работают вслепую.

Типичные подводные камни

  • Масштаб: 30 SKU сегодня и 3000 через год требуют разной архитектуры каталога и фильтров
  • Акции, промокоды, опт и персональные цены: если не заложить на старте, переписывают checkout
  • Синхронизация с CRM / учётной системой: дубли заказов и разъезд остатков
  • Возвраты, отмены, частичная оплата: редко в «дешёвом» КП, но появляются в первый месяц
  • Скорость и Core Web Vitals под товарный трафик: медленный каталог съедает CPL в Shopping

Технические моменты, которые нельзя пропустить

Микроразметка, аналитика, скорость и SEO-база. Без этого сайт «есть», но поиск и реклама работают хуже

  1. Микроразметка (Schema.org / JSON-LD)

    Organization, WebSite, BreadcrumbList, FAQ, Product / Offer для магазина. Помогает поиску и расширенным сниппетам. Закладываем в вёрстку с первого релиза, не «допишем потом».

  2. Title, description, Open Graph

    Уникальные title/description на ключевых страницах, корректный OG для шаринга в соцсетях и мессенджерах. Без этого ссылки выглядят как «голый» URL.

  3. Canonical и hreflang

    Канонические URL против дублей. Для нескольких языков: hreflang и понятная структура локалей, чтобы поиск не смешивал версии.

  4. Sitemap и robots.txt

    Карта сайта для индексации, robots без случайной блокировки важных страниц. После запуска проверяем в Search Console.

  5. События аналитики

    GA4 и пиксели с событиями lead / purchase / add_to_cart, не только pageview. Иначе CPL/CPA не посчитать, а реклама оптимизируется вслепую.

  6. Скорость и Core Web Vitals

    LCP, CLS, INP. Медленный сайт съедает конверсию и качество трафика в Ads. Изображения, шрифты, JS: измеряем до сдачи.

  7. Consent и cookies

    Согласие на аналитику/маркетинг там, где это нужно. Пиксели не должны стрелять до согласия, если так требует политика. Иначе риск для аккаунтов и данных.

  8. HTTPS и базовая безопасность

    Сертификат, редирект на https, защита форм от спама, аккуратные заголовки. Для магазина: безопасный checkout и доступы админки.

  9. Формы, ошибки, доступность

    Понятные ошибки валидации, фокус с клавиатуры, alt у изображений, читаемые кнопки. Сломанные формы = потерянные лиды ещё до рекламы.

  10. Редиректы и 404

    При миграции со старого сайта: 301 на новые URL. Страница 404 с навигацией. Иначе SEO и закладки клиентов «умирают».

Интеграции с CRM и сторонними сервисами

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

Как обычно подключают

  • Нативный API / webhook CRM

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

  • Посредник (Make, Zapier и подобные)

    Когда нет прямого коннектора, но есть webhook или email-триггер. Быстрее кастомного кода, но появляется подписка и зависимость от сервиса.

  • Кастомный коннектор

    Пишем под конкретную CRM или учётную систему, если API сложное, нестабильное или нужна двусторонняя синхронизация. Дороже, зато под ваш процесс.

  • Когда интеграция «невозможна»

    Нет API, закрытый кабинет, только ручной импорт. Тогда проектируем обход и фиксируем процесс: кто куда переносит лиды и с какой задержкой.

Обходные решения, если прямой интеграции нет

  • Webhook или форма → email в общий ящик с шаблоном полей для ручного заведения в CRM
  • Экспорт CSV / Excel по расписанию и импорт в CRM (подходит при небольшом объёме заявок)
  • Промежуточная админка заявок на сайте: менеджер видит лиды и переносит в CRM
  • Интеграция только в одну сторону: сайт → CRM сейчас, обратная синхронизация статусов позже
  • Смена CRM или тарифа CRM, если API критично для бизнеса (иногда дешевле вечного обхода)

Что выяснить на брифе до оценки

  • Какая CRM / сервис и есть ли актуальная документация API
  • Какие поля обязательны в сделке / лиде и откуда берутся UTM
  • Кто владеет доступами и есть ли тестовый кабинет
  • Нужна ли двусторонняя синхронизация статусов, или достаточно «заявка пришла»
  • Что делаем, если CRM лежит: очередь, повторная отправка, уведомление команде

Вопросы перед стартом

То, что обычно спрашивают, выбирая подход и бюджет

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

Готовы обсудить ваш проект?

Напишите, что нужно сейчас: сайт, реклама или комплекс. Подскажем формат без давления на «всё сразу».