Custom client portals: requirements and cost

A client portal should give the right information to the right person. Before pricing, describe what customers can do themselves, which data they see and who updates it. A login screen alone does not define an application.

Access rules before appearance

Define relationships between people, companies and projects. One customer may have several projects; one company may have several employees. Rules are needed for adding users, limiting visibility and revoking access after cooperation ends.

An example initial scope

• Projects assigned to the customer.
• Status and the next action required.
• Shared documents with dates and versions.
• Acceptance confirmation or feedback.

This is a discussion proposal, not an existing WebHeaven product. Payments, messaging and document signing are separate functions needing analysis.

The key test: someone else’s data

Test accounts A and B with the same resource types. User A must not open B’s document by changing an address or identifier. Check revoked access and file links after logout. Hiding a menu item does not replace application-side authorization.

Where does the status come from?

For manual updates, define responsibility and frequency. For CRM or work management data, plan integration and outage handling. An outdated portal can increase calls rather than reduce them.

How should a quotation be prepared?

List roles, data objects and three typical user scenarios. Add a document example and current system details. Cost depends on access rules, integrations, data migration and maintenance, rather than screen counts alone.

Is custom development necessary?

Not always. Compare requirements with an existing CRM or project system offering client access. A custom portal makes sense when the required process exceeds those capabilities.

Send your process and access requirements for technical assessment.