Price the software work around the service decision it supports
“A service portal” can mean a place to submit a question, a workspace for reviewing documents or a system that schedules people and equipment. Those scopes involve different records, permissions and operating commitments. An estimate becomes useful when the proposal says which of them the business actually needs.
We discuss fees after establishing the requested result and the condition of the existing tools. There is no universal country price or assumed package of Arabic production, integrations and continuing support.
Separate the first useful delivery from later operations
Consider a supplier whose customers report meeting-room display problems. The first delivery might explain the enquiry process, collect the relevant installation context and make the request readable to the office. It might leave appointment decisions in the existing scheduling tool.
A broader delivery could expose approved reports through customer accounts. That adds decisions about account membership, document visibility, corrections and access when a customer contact changes. Automatic scheduling would add further rules about service coverage, availability and exceptions.
The proposal should state which result is included. A request reference is not an appointment; a document view is not a complete field-service platform. These distinctions let you compare scope without assuming that similar page counts mean similar work.
Make investigation an identifiable deliverable
For an existing application, access to its configuration and operating history may be needed before a reliable repair estimate is possible. A short investigation can establish how a request is stored, which component sends a response and whether the reported failure can be reproduced safely.
Agree what that investigation will return: findings, the inspected boundaries, repair options and the remaining uncertainty. It should lead to a decision. It should not quietly become an unlimited commitment to repair every issue discovered in an inherited system.
If key access or provider documentation is unavailable, record the dependency and its effect on the estimate. A confident number cannot remove an unknown connection from the work.
Count language and review work explicitly
Arabic and English content may require separate writing, qualified review and inspection in their intended layouts. Include the messages, forms and documents that belong to the agreed task. A proposal based only on the number of service pages can miss the wording that explains a rejected or incomplete request.
Identify who supplies the approved service facts and who resolves language-review comments. Include a sensible change process for those facts after the draft has been reviewed. Changing what the service promises can affect interface wording and staff handling as well as translation.
Identify costs paid to other organisations
Hosting, domains, commercial software, messaging services and provider accounts may carry separate charges. Establish whose account is used, which arrangement has actually been approved and who monitors renewals. Provider fees and acceptance remain subject to that provider's terms.
Legal, accounting, privacy and other specialist reviews should have named owners. Physical installation work, equipment procurement and site visits are not implied by a website development scope. If they are dependencies of the customer's service, the business must plan them alongside the software work.
Agree acceptance and the next change
The estimate should include the review needed to accept the specified task: the public explanation, ordinary request, relevant exception and receiving record. A successful demonstration should leave a clear account of what remains unfinished.
Discuss handover, recurring maintenance and support arrangements separately where they are outside the delivery. Use support planning to identify the routine responsibilities, then send the task and available evidence so the initial scope can be made concrete.