Connect the price to the work that must be completed

A five-page website and a five-screen application can require very different work. A public page may need factual review and a reliable enquiry route. An application screen may need permissions, record history, provider access and a recovery path when a change is rejected. Page count alone does not describe those responsibilities.

A proposal should explain the included journeys and the evidence used to accept them. It should also identify who prepares the content, who supplies access and which decisions must be made before implementation can proceed.

What changes the scope

Language coverage affects more than the number of paragraphs. Estonian and English versions need corresponding meanings, appropriate links and a process for reviewing later changes. If a journey includes translated documents or provider messages, those materials need their own scope and owner.

Existing data can add investigation and preparation. A file containing organisation names may not establish which rows are separate legal entities, locations or contacts. Migration work includes agreeing those distinctions and checking the result, not simply importing every row.

External services add dependency questions. Account permissions, supported operations, test arrangements and provider approval can determine what is possible. Their fees and terms should be reviewed directly with the provider; a development proposal should not imply they are included unless it says so.

Separate discovery from a guessed fixed solution

Where an important fact is unknown, a bounded investigation can be more useful than pricing an assumed build. Define what the investigation should answer: whether an export preserves relationships, whether a supported endpoint can perform the needed operation or whether an existing workflow can express the proposed rule.

The result should inform a decision, including the possibility that no new system is justified. It should not become an open-ended list of observations without a recommended next step and an explanation of the remaining uncertainty.

Make review work visible

Specify the review environment, representative examples, expected outcomes and reviewer responsibilities. Include time for resolving findings. A technically completed screen can still wait on a business decision or a language review before it is ready for use.

Name each included workflow and its acceptance evidence in the proposal. If later discussion introduces another audience, language or integration, assess its effect on the scope instead of silently absorbing it into an unrelated task.

Account for continuing costs

Hosting, domains, supplier accounts, updates, content review and recovery arrangements need owners after delivery. An export can also require work before another tool can use it. Ask what the next authorised maintainer will receive and which continuing services require a separate agreement.

Read costs around the build for a practical example, or send a project enquiry with the task and known dependencies. A useful proposal starts from those facts rather than a universal package price.