2-Week Pilot: What Actually Happens Inside

Why a 2-Week Pilot Is the Right Entry Point

A full headless migration takes 4–12 weeks and carries real budget risk: you commit money before proving the approach works on your specific data and business logic. The 2-week pilot solves a different problem — it validates the hypothesis on your real catalog before you decide to migrate.

This is not a demo with dummy products, and it is not a capabilities presentation. At the end of two weeks you have: a live environment running your catalog, a technical audit of your Bitrix structure, a concrete estimate and migration plan. Enough to make a confident go/no-go decision.

Days 1–3 — Catalog Probe

The first three days are the Catalog Probe: we take your product catalog as a CSV export or Bitrix export, set up an Elasticsearch index, and run the data through our Frontbox shell — a minimal headless frontend purpose-built for catalog testing.

The goal of this phase is not a polished UI — it is diagnosis. You see your real catalog in a fast headless frontend for the first time: where facets break because of empty attributes, where search returns irrelevant results, where category structure creates dead zones. This is an honest baseline of what you are actually working with.

Days 4–7 — API Audit and Integration Map

The next four days are a technical audit. We document your Bitrix structure: iblocks, properties, custom modules, 1C sync schema. From this we build an integration map — which endpoints need to be built, in what order, with what dependencies.

In parallel, we log every data quality issue that surfaced during the Catalog Probe: missing attributes, broken sync, duplicates, products without categories. Each issue is assessed: is it a migration blocker, can it be fixed in parallel, or is it outside the pilot scope?

This phase requires 2–3 hours of your CTO or tech lead time — one call to walk through the structure and answer clarifying questions.

Days 8–10 — Live Preview

By day eight you have a clickable preview environment with your real catalog data. Not a mockup, not Figma, not a demo with test products — your actual SKUs, categories, filters, and search.

Your team can log in, browse the catalog, try filters, test search. This matters: the decision to migrate should be based on how the system behaves with your data, not on someone else demo.

This phase also produces performance baselines: search response time, faceted filter speed, Core Web Vitals. These go into the final report as the baseline to compare against the post-migration projection.

Days 11–14 — Report and Migration Plan

The final block is not a checkbox presentation. You receive four concrete documents:

• Full technical spec — solution architecture, endpoint list, data schema, dependencies
• CWV baseline vs projection — measured current performance and expected post-migration, with reasoning
• Estimate and timeline — specific numbers for the full migration, not a range
• Risk log with mitigations — what can go wrong, how it is tracked, how it is minimized

Day 14 requires an available decision-maker — to walk through the report together, ask questions, and make a call. This is not a sales pitch for the next phase: it is a debrief with facts on the table.

What the Client Needs to Bring

The pilot requires minimal effort on your side:

• Bitrix access (read-only admin) or a catalog CSV export — either is enough to start
• 2–3 hours of CTO or tech lead time for the API audit call (days 4–7)
• A decision-maker available on day 14 for the final debrief

No preliminary integration work, no production server access before an NDA and scope agreement are signed.

What You Get at the End

After two weeks you have everything needed to make a confident decision:

• A live preview of your catalog in a headless frontend
• A full technical spec — ready to hand to any development team
• A concrete estimate, not a range
• An honest risk log — no uncomfortable questions swept under the rug

If after two weeks you decide not to proceed — you still leave with a technical audit of your Bitrix structure and a clear picture of what needs to be fixed. That is worth something on its own.

Ready to start? Launch a Catalog Probe — or get in touch to discuss your project.