Пилот за 2 недели: что реально происходит внутри

Почему пилот за 2 недели — правильная точка входа

Полная миграция на headless-архитектуру занимает от 4 до 12 недель и несёт реальный бюджетный риск: вы вкладываете деньги до того, как убедились, что подход работает именно на ваших данных и вашей бизнес-логике. Пилот за 2 недели решает другую задачу — он доказывает гипотезу на реальном каталоге, прежде чем вы принимаете решение о полной миграции.

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

Дни 1–3 — Catalog Probe

Первые три дня — это «Catalog Probe»: мы берём ваш каталог в виде CSV-выгрузки или экспорта из Bitrix, поднимаем индекс Elasticsearch и прогоняем данные через наш Frontbox shell — минималистичный headless-фронтенд, заточенный под тестирование каталога.

Цель этого этапа — не красивая картинка, а диагностика. Вы впервые видите свой реальный каталог в быстром headless-фронтенде: где фасеты не работают из-за пустых атрибутов, где поиск возвращает нерелевантные результаты, где структура категорий создаёт мёртвые зоны. Это честный срез того, с чем придётся работать.

Дни 4–7 — API-аудит и карта интеграций

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

Параллельно фиксируем все проблемы с качеством данных, которые всплыли на этапе Catalog Probe: пропущенные атрибуты, сломанная синхронизация, дубли, товары без категорий. Каждая проблема оценивается: это блокер для миграции, или её можно решить параллельно, или она вообще вне скоупа пилота.

Для этого этапа нам нужно 2–3 часа времени вашего CTO или технического лида — один звонок для разбора структуры и ответов на уточняющие вопросы.

Дни 8–10 — Живое превью

К восьмому дню у вас есть кликабельное превью-окружение с реальными данными вашего каталога. Не макет, не Figma, не демо с тестовыми товарами — ваши реальные позиции, категории, фильтры, поиск.

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

На этом этапе также измеряем базовые показатели производительности: время отклика поиска, скорость фасетной фильтрации, Core Web Vitals. Они войдут в финальный отчёт как baseline для сравнения с проекцией после миграции.

Дни 11–14 — Отчёт и план миграции

Финальный блок — это не «презентация для галочки». Вы получаете четыре конкретных документа:

• Полный технический спек — архитектура решения, список эндпоинтов, схема данных, зависимости
• CWV baseline vs проекция — замеренные показатели сейчас и ожидаемые после миграции, с обоснованием
• Смета и таймлайн — конкретные цифры на полную миграцию, а не диапазон «от 3 до 15 месяцев»
• Лог рисков с митигациями — что может пойти не так, как это отслеживается и как минимизируется

На день 14 нужен доступный ЛПР — чтобы разобрать отчёт вместе, задать вопросы и принять решение. Это не продажа следующего этапа: это деброфинг с фактами на столе.

Что нужно подготовить клиенту

Пилот требует минимальных усилий с вашей стороны:

• Доступ к Bitrix (read-only admin) или выгрузка каталога в CSV — этого достаточно для старта
• 2–3 часа времени CTO или технического лида для звонка по API-аудиту (дни 4–7)
• ЛПР, доступный в день 14 для разбора итогового отчёта

Никаких предварительных интеграционных работ, никакого доступа к production-серверам до подписания NDA и согласования скоупа.

Что вы получаете на выходе

По итогам двух недель у вас есть всё необходимое для уверенного решения:

• Живое превью вашего каталога в headless-фронтенде
• Полный технический спек — готов к передаче любой команде разработки
• Конкретная смета, а не оценочный диапазон
• Честный лог рисков — без замалчивания неудобных вопросов

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

Готовы начать? Запустите Catalog Probe — или напишите нам, обсудим детали вашего проекта.