Why complex websites cannot be estimated honestly before discovery

When a client asks for the cost of a complex website or replatforming project, the honest answer rarely fits into one fixed number. If there is a catalog, roles, integrations, SEO, customer accounts, payments or custom workflows, the price depends on actual scope.

That is why WGP starts not with a fixed custom-work promise, but with compact discovery. The goal is to understand what already works, where the business risk is, which parts are required for launch and which parts can stay optional.

What we need before estimation

• current stack, access, hosting constraints and release process;
• critical flows: catalog, search, cart, checkout and customer account;
• integrations: ERP, CRM, payments, delivery, analytics and external APIs;
• content model, user roles, permissions and edge cases;
• SEO surface: URLs, canonical, redirects, sitemap and pages with traffic;
• acceptance criteria: which metrics and checks mean the phase is accepted.

After that we can create a compact requirements structure. Not a 100-page document, but a working map: base scope, optional blocks, risks, dependencies and the first verifiable step.

Why the first work slice beats a large promise

For a new client it is safer to start with a limited phase: technical audit, pilot, integration spike or release-support task. This shows communication quality, delivery pace, Git Flow, staging checks and how carefully the team handles production risk.

If the task is packaged as a Frontbox product format, a clear package price can make sense. If the work is custom development, replatforming or complex integrations, the correct frame is different: discovery first, then base scope, optional scope and an estimate tied to acceptance criteria.

You can see the process on How we work. For budget framing, see Pricing and formats. For a real project, start with a short request through the contact form: send the site URL and a few words about what is slowing you down.