Compare the responsibilities inside a multilingual project estimate
Two projects with the same page count can require very different work. One may use current, approved language versions in a supported content system. Another may need source reconciliation, provider investigation and new permissions before a page can safely change.
Count distinct review and operating tasks
Identify the service families, maintained languages, forms, messages and downloads included. Translation production, language review and implementing approved text are separate responsibilities. State who supplies each input and what happens when the source changes during development.
A proposal should also say which existing routes are retained, redirected or retired. The time needed to inspect old links and document destinations belongs to the transition, even when those links are not prominent in the new navigation.
Inspect the integration before promising its scope
A supported export, a configured provider feature and a custom exchange have different dependencies. Account permissions, product limits, provider fees and test arrangements can affect feasibility. An initial investigation may be needed before a receiving workflow can be estimated responsibly.
For invoicing or payment work, the organization and its advisers approve the relevant arrangement. A developer's estimate cannot replace that decision or guarantee a provider's approval.
Include acceptance and handover
Language reviewers need context and time. Customer and staff roles need populated fixtures and a way to inspect the receiving result. The proposal should include those checks, known test limits and the operating documentation required for an ordinary future change.
A smaller release can be useful when it completes one task and preserves the rest. It should not be described as complete merely because unresolved work was moved to an unnamed later phase.
Keep recurring work visible
Hosting, subscriptions, content updates, account recovery and ongoing technical support may have different owners. Specify covered components, hours, reporting routes and change limits. The agreement should identify future responsibilities rather than imply that every language and provider will be maintained indefinitely.
Send the task and current system to discuss a scope based on evidence. Repair or replacement and the costs around a release develop the decisions behind that comparison.