Audit before rewrite: what a decision maker should get

When a business says “we need to rewrite the site”, the real problem is rarely the framework choice. The problem is uncertainty: where the base requirement ends, where hypotheses begin, and which integrations, data models or workflows carry hidden risk.

A useful discovery audit is not a polished deck. It should give the owner, CTO or e-commerce lead enough clarity to decide whether to run a pilot, change the plan, stop, or collect missing data first.

1. Constraint map, not a wish list

The first output is a map of the current contour: speed, catalog, search, SEO, checkout, 1C exchange, CRM, payments, delivery, roles and content workflows. The key is to separate symptoms from causes. “The catalog is slow” may mean heavy filters, weak API design, a missing cache strategy, or conflicting business rules in product data.

At this stage, a fixed price for full custom replatform would be the wrong promise. The honest output is a view of what is simple, what needs validation, and what should not be touched without a rollback plan.

2. Scope split: base vs optional

The common mistake is mixing the smallest measurable pilot with the ideal future platform. The budget grows, the team loses focus, and the decision maker only sees risk.

A better structure separates base scope, optional blocks and client-specific scenarios. For example: one category, listing, product page, search and basic analytics belong in the pilot; complex personalization, rare roles, extra integrations and full content migration come after the first result is proven.

3. Acceptance criteria before development

If acceptance criteria appear after development starts, the project is already exposed. Before coding, agree which metrics matter: LCP, TTFB, indexing, zero-result searches, add-to-cart conversion, API errors and checkout stability. Not every metric must become a pilot KPI, but every risky area should be named upfront.

This protects both sides: the client understands what is being bought, and the team avoids selling abstract “modernization” without measurable evidence.

4. First work slice instead of a large promise

For complex custom development, the right next step is a small work slice or a pilot on real data. It reveals communication speed, Git Flow quality, staging checks, review discipline, documentation and the team’s ability to avoid breaking a live business.

WGP usually starts with a constrained slice: one category, catalog, search, SEO-risk map or integration probe. It is faster and more honest than selling a large rewrite before data, roles, workflows and acceptance criteria are clear.

Next step: if you are considering a Bitrix rewrite or migration, start with a short audit. We will map the current contour, separate base scope from optional work and show which small slice can produce enough evidence for a decision. See Headless Pilot or contact us.