Do not start a site rewrite without a short discovery

Large rewrites often start from the same place: the current site is slow, marketing cannot ship pages quickly, catalog and search behavior is unpredictable, and the team is tired of fixing symptoms. At that point it is tempting to ask a vendor for a timeline and budget for “a new site”. But a confident estimate before discovery is usually either too vague or dangerously precise.

For e-commerce, Bitrix-backed systems, B2B portals and integration-heavy websites, the safer first step is a short technical and product discovery. The goal is to understand what blocks growth, where downtime risk lives, what can be moved in stages, and which first slice can prove value.

What to collect before estimation

• Business context: what is being lost today — release speed, SEO, conversion, stability, catalog control or maintenance cost.
• Technical map: CMS, API, ERP/CRM, search, user roles, payments, delivery, analytics, staging and production workflow.
• Content and data: URL structure, catalog, filters, canonical and redirect rules, sitemap, locales and critical templates.
• Acceptance criteria: what will prove the first phase worked: speed, indexability, stability, release control or search quality.

Keep discovery compact

We usually split requirements into base functionality, optional functionality and client-specific logic. This lets the client see what is needed for the first result and what can safely wait. It also makes the budget conversation concrete instead of speculative.

For example, the base layer may include connecting a Next.js frontend to an existing backend/API, preserving SEO structure and launching a controlled set of pages. Optional work may include advanced admin features, extra roles, new integrations or personalization. Client-specific work is the logic that exists only in your business: unusual workflows, access rules, assortment exceptions or internal reports.

A small pilot beats a large promise

If the system already makes money, it should not be broken for a redesign. A small pilot or test slice checks team workflow, code quality, staging process, communication speed and integration complexity. For headless and replatform projects, this is often more honest than selling the full migration immediately.

A good first slice can be one catalog category, one landing page, one search scenario or one CMS/API/frontend connection. After that, the team has evidence: what was simple, where the risk is, which data is messy, and whether a staged rollout is realistic.

How WGP works

WebGoodPeople moves fast through an experienced engineering team, AI-assisted development, reusable components and transparent Git Flow. But speed does not replace review, staging, production checks or careful SEO work. Source code, project knowledge and documentation should stay open to the client, so the website does not become a black box.

If you are considering a rewrite, headless move or complex integration, start with a compact discovery: show the current pain, available data and the first result you want. Then we can shape a short scope and choose a safer pilot instead of a large delivery risk.

Discuss discovery or a pilot with WGP · See how we work · WGP services