Client portal development: scope, integrations and estimate
Client portal development starts with the tasks clients need to complete on their own: checking order status, downloading documents, placing repeat orders or contacting support. These tasks determine the screens, integrations and checks that make up the estimate.
The portal can be part of an existing website or a separate application. Before requesting an estimate, establish where the data is stored, how users gain access and what happens if an integration fails. Mockups of Profile and My Orders pages do not answer these questions.
This guide explains how a service or B2B business can prepare the project. The brief builder helps define requirements, and the tables help review a developer's proposal. A budget figure requires a review of your systems and an agreed scope.
Choose one main use case for the first release
Describe the client's task in one sentence with a verifiable outcome. For example: “A company representative sees the current status of their order and downloads its invoice.” This task provides a basis for data requirements and product acceptance.
Start with a process that already exists in the company. If employees regularly submit the same document upon request, describe how it is found and who is allowed to receive it. If you want to automate a repeat order, find out which items, prices and conditions should be transferred from the previous order.
| Client task | What to include in the first version | Information needed for an estimate |
|---|---|---|
| Find out the status of your order | Order list, order details, clear statuses and update time | Which system manages the order and what statuses can be shown to the client? |
| Get documents | List of files, link to contract or order, download | Who generates the document, where it is stored and how access is terminated |
| Repeat order | Order history, item selection and confirmation of current terms | How prices, availability and contractual restrictions change |
| Contact support | Create a request, message history, attachments | Where the operator works, who answers and how the client finds out about the answer |
Add the remaining scenarios to the development queue. Each must have a reason: a validated customer task, a reduction in a specific manual task, or a contract requirement. This makes it easier to explain why the feature was included in the first release and why it could be postponed.
Can you add a portal to an existing website?
Review the company's website and systems first. Check source code access, update support, the current sign-in mechanism and backend capabilities. If the developer can only edit pages, the portal will require another application or an architecture change.
Test a ready-made CMS module with a small prototype. It must support the required relationships between users, organizations, orders and documents. A sign-in page in a demo does not show whether the module can enforce your access model.
| Option | When to consider | What to check |
|---|---|---|
| Current CMS module | The module supports the required workflows and permissions | CMS version support, integrations, customisation limits and updates |
| Custom website section | The website can be extended and the portal shares its infrastructure | Impact on public pages, access boundaries and release order |
| Standalone web application | The portal requires independent workflows and frequent changes | Cross-system sign-in, APIs, hosting, operations and an independent launch |
The application can be hosted on a subdomain, but the address itself does not solve the problem of access or integration. The decision depends on the processes, infrastructure and which team will support the product.
The relationship between the interface, backend and business data is explained in our guide to CRM architecture. A client portal adds an external user with restricted permissions to this architecture.
Define the first release scope
Basic features also have choices that affect the work. Define registration, contact verification and account recovery. For notifications, specify the triggering event, delivery channel and error handling. For documents, specify the file source and how long access remains available.
Describe each feature through an action and outcome. “Order history” may cover only orders placed after launch or the entire history from an old database. The latter requires client mapping and data migration. For invoice payments, agree on amounts, payment status and handling repeated payment-provider notifications.
Include error handling in the first release. Clients need a clear message when a document is temporarily unavailable; operators need enough information to diagnose the problem. Also define who can block an account and correct an incorrect organization mapping.
Test mobile workflows with realistic data: a long order number, several documents, an explanatory status and an email containing a sign-in link. Agree which actions must work on a phone and include them in acceptance criteria.
Connect the portal to CRM and 1C
For each data type, identify the system that holds the current value. Orders may be managed in an accounting system, support requests in CRM and documents in file storage. The portal retrieves the data the user is allowed to access and sends changes back where required.
Map data exchanges before designing screens. Include the record identifier, source, direction of exchange, acceptable delay and the person responsible for errors. Implementation depends on the APIs, versions and settings of your systems; the word “integration” in a proposal does not define this exchange.
| Data | Requirement to agree | Check |
|---|---|---|
| Order and status | Agree on the source system and client mapping | The status change appears within the agreed delay |
| Document | Determine file source and download permission | The client receives only documents they are authorised to access |
| Support request | Agree on request creation, identifiers and where operators respond | The response returns to the same request history |
| Payment | Define the payment confirmation source and retry handling | Repeated notifications do not repeat the business operation |
Define a separate workflow for an external-system outage. You might show the last known value with its update time, temporarily disable changes or queue the operation. Choose based on the consequences: an outdated delivery status and an outdated available balance pose different risks.
When writing to another system, you need a way to determine whether an operation has completed. A retry after a timeout must follow an agreed rule. Where possible, use a stable operation identifier and verify the result; agree on the exact mechanism with the API owner.
Delivery of a public website form is covered separately in our article on website integration with CRM. A client portal also reads business data and performs actions for an authenticated client.
Agree on roles and access to individual records
In a B2B portal, a user account may represent an organization, and the organization may have several employees. Before requesting an estimate, define who invites users, who can access documents and what happens when an employee leaves or the contact person changes.
Separate permission to perform an action from permission to access a specific record. Permission to download invoices must account for the organization and order that each invoice belongs to. Hiding a button does not protect a file from direct requests.
OWASP recommends checking permissions on every request and denying access by default. For a specification, make the conditions explicit: users cannot obtain another client's record, file or data through search, exports or direct links. The server serving the data performs the check.
Separate OWASP API recommendation covers access to records by identifier. Even a random UUID does not replace a permission check for the requested record. Acceptance testing must include operations on another client's data, including updates and deletion where those operations exist.
Define a role model before asking for arbitrary future roles. Describe the current roles, how they are assigned and a few expected changes. For example, an accountant may access invoices only, while a purchasing employee may access orders. This makes extensibility assessable without an undefined development scope.
What determines cost and timing?
An estimate requires an agreed use case and technical information. Screen count tells only part of the story: similar order detail screens may use one existing API or several databases with different identifiers.
Ask the contractor to estimate these work areas separately:
- Review of the website, data and integrations; validation of uncertain assumptions.
- Description of scenarios and screen prototypes.
- Development of interface and server operations.
- Integrations, setting up rights and necessary changes to external systems.
- Transfer of history if it is included in the first version.
- Checks, environment preparation, launch and transfer of documentation.
- Post-launch support with specific conditions.
Each estimate item needs an output and clear boundaries. A technical review delivers a data map; integration delivers an agreed exchange with error diagnostics; launch delivers a working environment with operating instructions. List licenses, paid services and work by the CRM or 1C support team separately.
Timing also depends on system access, interface approval and test-data readiness. If API access from another team is unconfirmed, record that dependency. The first-release schedule should identify who resolves each dependency and when.
A project-specific price cannot be given from the label “client portal” alone: the scope has not been agreed. Once you have proposals, compare them against the same boundaries and use the checklist for comparing website estimates. It helps identify migration, operations or integration checks omitted from a quote.
Example project brief for a service company
Consider an illustrative scenario: a company wants to show corporate clients their order progress and documents. The following requirements are an example, with no claim of an actual deployment or measured results.
Goal of the first version: an organization representative checks order status and retrieves invoices independently. Managers continue managing orders in the existing system. Payments, repeat orders and client-managed invitations remain in the development backlog.
Screens: sign-in and account recovery, order list, order details with an update time, documents and a temporary-unavailability message. Data: organization ID, the relationship between a user account and organization, order ID, permitted status and document.
Limitations: orders from other organizations are inaccessible; document access is checked on the server; update timing is agreed after reviewing the API; historical data is migrated only within the approved scope.
Operator actions: assign an organization to a confirmed user, revoke access, find an order exchange error. This can be a separate service screen or an operation on an existing system if it supports the desired process.
Discuss this brief with the contractor, then provide anonymised sample data, system documentation and an agreed process for access to the test environment.
Run acceptance checks before launch
Prepare two clients belonging to different organizations, with orders for each. Use an agreed test environment and data permitted for testing. Review client and operator workflows. The technical team checks direct requests within the agreed scope.
| Scenario | Expected result |
|---|---|
| The client signs in and opens their order | Sees allowed data and when it was updated |
| Someone else's order or document is requested | The server denies access and does not disclose content |
| The manager changes the status in the source system | The portal updates within the agreed time |
| External system not available | The user sees a clear status; the operator can diagnose the failure |
| The client repeats the action after a delay | The system respects the retry rule |
| The operator revokes access | Data becomes unavailable according to the agreed-upon rule for ending active sessions |
| A document is opened on a phone | It can be found and downloaded without broken navigation |
Record results and defects, then retest fixes. At handover, obtain a component list, deployment and update instructions, integration documentation and named operations owners. Share accounts and secrets through an agreed secure channel.
Prepare the information needed for an estimate
Prepare one main use case, a list of users and organizations, data sources, sample records and acceptance criteria. Explain what the website already provides, which systems are accessible and who approves changes.
Add this information to the brief from the builder at the start of the article and use it to discuss web application development. If changes affect internal processes of managers, their scope should be agreed upon with CRM development.
FAQ
Do you need a separate mobile app?
Start by testing the main actions in the responsive website. Consider a separate app when you have specific requirements, such as offline operation or device capabilities. Specify these before requesting an estimate because they change the scope.
Can the first release provide document downloads only?
Yes. Document downloads can be a complete first-release use case. Agree on the file source, client mapping, access rules and operator actions. Even a small interface needs server-side permission checks for every document it serves.
How can several employees of one client use the portal?
Define how users belong to an organization, how invitations work and how roles are assigned. Separately specify visibility of shared orders and documents, and access revocation. The developer can estimate implementation against this model.
What if the CRM has no suitable API?
Start with a technical review: ask the system owner about available exchange mechanisms and test them in a sample use case. If the required operations are unavailable, you may need system changes, another exchange method or a narrower first release. Resolve this dependency before approving the main estimate.
Sources
- OWASP: Authorization Cheat Sheet — rules for checking permissions.
- OWASP API1:2023: Broken Object Level Authorization — checking access to API objects.
Sources checked on October 11, 2026. The brief builder and tables help prepare a project; agree the portal scope after reviewing the data and systems.