Why we do not quote custom development before a scope review

When a store, website or B2B portal is already in production, an exact price without checking the inputs is usually risky for both sides. The request may sound simple: refresh the storefront, speed up the catalog, add an integration or move the frontend to Next.js. Underneath there are roles, data, ERP, CRM, payments, delivery, SEO structure, content workflows and release constraints.

For custom development we start with a short scope review instead of promising fixed price too early. It is not a long specification and not a sales deck. It is a compact project map that shows what belongs in the first phase, what is optional, and what depends on client-specific data or integrations.

What we need before an estimate

• the current stack and the parts of the system that cannot go down;
• money-critical flows: catalog, search, cart, checkout, account area;
• integrations that affect timelines: ERP, CRM, payments, delivery, external APIs;
• data that needs to be migrated or synchronized;
• roles, workflows and acceptance criteria for review;
• the first work slice that can be verified without a large budget.

Where fixed price makes sense

Fixed price works for packaged Frontbox formats: subscription, white-label or a clearly scoped pilot. The solution boundaries and checkpoints are known upfront.

For a non-standard website, replatforming or integrations, a budget range after discovery and phased estimates are more honest. The client does not buy a pretty number that breaks on the first custom scenario.

How we reduce risk

We suggest a small verifiable step: audit, pilot, integration spike or test slice. This shows communication speed, code quality, staging/production checks and whether the team can explain risks clearly.

Then we can discuss a full phase with transparent Git Flow, open source handoff, a client knowledge base and clear acceptance criteria.

Related: about WGP, our process and scope review contact path.