Why fixed price before discovery is risky in custom development

“Can you give me a fixed price?” is a fair question.

I also want budget clarity when I buy work. Especially for a website, e-commerce platform, internal portal, or any system where small details can turn into expensive production bugs.

But for custom development, a fixed price before discovery often creates the opposite of control.

Someone guesses. Someone adds a huge buffer. Someone gives a pleasant number and then starts negotiating every edge case later.

I have seen all three.

What hides behind “just a website”

The first brief may sound simple: new frontend, catalog, account area, CRM integration, some SEO, a lead form.

Then production reality appears:

the catalog has seven product types, not one;
stock and prices arrive from ERP with delays and conflicts;
managers need different roles and permissions;
old URLs cannot be lost because organic traffic depends on them;
search needs synonyms, typos, and commercial priorities;
acceptance is not “the page opens”, but a set of business scenarios.

That is not a bad client. That is normal production.

The problem starts when the team pretends this is already known and sells a precise price from a three-paragraph brief.

How I prefer to estimate

Start with a compact discovery.

Not a month. Not an 80-page document. Usually the useful artifact is a readable requirements structure that a founder, CTO, or product owner can actually review.

I look at five things:

Scope. What belongs in the first version and what can wait.
Data. Where products, prices, stock, users, and leads come from.
Integrations. CRM, ERP, payments, shipping, email, analytics, search.
Roles and workflows. Who does what, and where mistakes are expensive.
Acceptance criteria. How we know the work is done, not merely “almost working”.

After that, base functionality can be separated from client-specific functionality.

Where fixed price does make sense

Fixed price works when the offer is already productized: repeatable scope, known constraints, and a clearly described result.

For WGP, that can apply to packaged Frontbox formats: subscription, white-label, or another defined productized offer.

For a custom replatform, unusual e-commerce flow, integrations, headless Bitrix project, or role-heavy portal, I do not think it is honest to name the final fixed price before discovery.

You can share an hourly rate. You can show team capacity. You can propose a small paid work slice so the client sees delivery speed, review quality, staging, Git Flow, and communication.

But “everything for X” before risk mapping is not transparency. It is borrowed comfort.

What the client gets

Good discovery does not make the project more expensive. It makes mistakes cheaper.

The client sees what is mandatory, what is optional, and what should not enter the first release.

The team sees which integrations can break the timeline.

Both sides can decide whether to start with a pilot, Catalog Probe, architecture review, or a small production slice.

I like this frame because it does not ask anyone to believe in magic.

There are requirements. There are risks. There is a verifiable piece of work.

Then we can talk about speed.

If you need a calm pre-project review for e-commerce or a complex website, start with WGP: describe the project.