Customer portal development cost

A portal estimate becomes useful when it describes something a customer can finish. Replace “dashboard and documents” with “an invited contact can find the current statement for the correct company.” Record the trigger, information source, permitted action and confirmation for each journey. Include the person who handles the exception. A portal that displays records and a portal that lets customers change them can look similar while requiring very different validation and recovery work.

Count account relationships as well as user roles. One person might represent two companies; an employee might leave; a document might belong to a department rather than the entire account. OWASP identifies missing authorization on individual records as an API risk. Logging in does not by itself establish permission to view every invoice or attachment. Ask for an access matrix covering list, view, download, create and edit actions, including what happens immediately after access is revoked.

For each source system, ask whether the required API exists, whether access is included in the actual subscription, and whether a test environment is available. Identify the authoritative customer identifier and who repairs mismatches. Read-only status information can still require freshness rules and an outage message. Write operations add questions about duplicate requests, approvals and conflicting edits. An estimate should distinguish a proven connection from an assumption that needs investigation before a dependable commitment can be made.

Consider a distributor deciding between two first releases. Release A lets an invited customer download statements already held in the accounting system and submit a service request to staff. Release B also permits credit-limit changes, payment collection and approval by a customer administrator. The second release adds financial rules, approval history and consequential write operations; it is not simply three additional screens. Price the two scopes separately, then decide whether the extra actions are needed to achieve the first release’s purpose.

Ask every supplier to show discovery, implementation, data preparation, verification and handover separately from recurring services. Recurring responsibility includes hosting, identity-provider subscriptions, monitoring, backups, dependency updates and support. Record who owns each account and whether the business can export its records. Avoid treating a warranty, routine maintenance and incident response as interchangeable. If existing customer data needs cleanup, assign that work explicitly instead of assuming the development team can infer which company every record belongs to.

A practical request contains the selected journeys, role and account matrix, source-system inventory, record volumes, expected busy periods and verification scenarios. Ask suppliers to mark unknowns, exclusions and client dependencies. Request an explanation of which unknown could change the estimate most, plus the smallest investigation that would resolve it. Compare proposals by the work and responsibility included, not only the total. Keep an explicit change process so a new approval rule or integration becomes a visible decision rather than an unplanned obligation.