What to send before estimating a custom website or replatform

If you need a realistic estimate for a custom website, replatform, or integration project, do not start with “how much does a website cost?”. Start with a short brief. Better inputs mean fewer buffers, assumptions, and hidden scope disputes.

For WGP this matters most in projects with Bitrix, Laravel, Next.js, Elasticsearch, catalogs, account areas, and external APIs. Cost is driven less by the number of screens and more by data flows, roles, integrations, release risks, and acceptance criteria.

What to send before estimation

• Project goal. What should change for the business: speed, leads, SEO, new sections, less manual work, readiness for growth.
• Current stack. CMS, backend, frontend, hosting, key integrations, and who maintains the system today.
• Critical flows. Catalog, search, checkout, forms, account area, roles, import/export, CRM/ERP/1C, payments, notifications.
• What must not break. SEO URLs, filters, orders, stock, analytics, peak sales periods, internal team workflows.
• Data and access. Where the catalog lives, whether APIs exist, import formats, and who owns content and business rules.
• Timing constraints. Deadlines, seasonality, campaigns, release windows, staging requirements.
• Acceptance criteria. How everyone will know the work is ready: flows, metrics, checklists, production checks.
• Preferred first step. Audit, pilot, test slice, or a backlog for a larger project.

How we use the brief

First we separate the base scope from optional/client-specific work. Then we mark uncertainty: integrations, data, roles, migration, non-standard search, and downtime constraints. After that we suggest the shortest safe next step: audit, pilot, or a small work slice.

We promise fixed pricing only when the product boundaries are already known, such as packaged Frontbox formats. For custom development, the honest answer depends on scope, integrations, data, workflows, and acceptance criteria.

What the client gets

Not a magic website price, but a clear next step: what we check, what we build first, where the risks are, what can wait, how staging/production acceptance works, and how the team sees progress through Git Flow, checks, and documentation.

Send a brief to WGP or review our delivery process.