How Much Does a Custom Client Portal Cost?

The cost depends on the portal’s users, workflows and connections

Before discussing a custom client portal, define who will use it, what they need to do, which systems it must connect to and what operational requirements apply. A portal that gives clients access to documents may involve different work from one that also handles requests, approvals or payments. A credible quote needs a defined scope.

A client portal is a private online space where a business and its clients can exchange information or complete tasks. For example, a client might submit a request and upload a document; a member of staff then reviews it, updates its status and shares the outcome through the portal.

That differs from a public website, which presents information to visitors, and from a full SaaS product, which is designed to serve multiple customer organisations as a product. A portal may instead be a modest extension of a system your business already uses, or a larger set of connected workflows. The label alone says little about what a portal includes; describe the users, tasks, permissions and connections in the brief.

To assess whether bespoke development is financially justified, first identify the capabilities your clients and staff genuinely need. Then separate one-off work, such as design and integrations, from ongoing costs such as hosting and maintenance. Finally, compare a custom build with adapting software you already have or buying an off-the-shelf option. The following sections break down the work that can affect a quote and help you prepare a focused brief for suppliers.

Portal features that change the amount of work

Portal features can affect the work by adding user journeys to define, build and check. Start with what clients and staff need to do, then decide which capabilities are essential rather than assuming every possible feature belongs in the first release.

• Accounts and permissions: List each user type, such as clients, client contacts and staff. For each, record which records they can view or change. For example, a client may need access only to their organisation’s documents, while staff may need to see and update several clients’ records. Note whether a client can invite colleagues and who approves or removes access. Document these access rules so they can be included in the scope and checked during testing.
• Client dashboard and status: Decide what a client should see on signing in: open requests, upcoming actions, recent documents or the progress of work. Describe what changes the status, who updates it and what the client should see next. If staff update a request in another system, clarify whether that update must appear in the portal too.
• Document exchange: Sharing a file is different from asking a client to submit one and tracking whether it has been received or reviewed. Specify who can upload, replace, download or remove a file; whether staff need to mark it as checked; and what the client sees if something is missing or needs correcting. Be clear about whether documents are linked to a person, an organisation, a request or a particular piece of work.
• Forms and requests: Identify what starts each request, which details the client supplies and who receives it. Then map the next steps: does a staff member assign it, ask for more information, change its status or close it? Record what confirmation the client receives and what they can see while waiting. A form that simply sends an email has a different workflow from one that staff manage through to completion.
• Messaging: Decide whether clients need conversations inside the portal or whether updates by email are sufficient. If messages are included, specify who can start or join a conversation, whether it relates to a request or record, and what staff need to see when responding. Avoid adding messaging unless it solves a defined communication problem.
• Payments and reporting: Include payments only if clients need to pay through the portal, and explain which charges they should see and what staff need to reconcile or correct. For reporting, name the decision the report supports, who uses it and which information they need. A dashboard or report without a clear purpose can add work without helping the business.
• Staff administration: Decide who can add or amend users, change permissions, review activity and correct records. Include the practical tasks staff will perform when a contact changes role, a client account needs updating or an incorrect detail is found. Treating these as staff journeys helps avoid a portal that works for clients but is awkward to operate.

For each capability, mark it essential, useful later or not required. For every essential item, write down who starts the journey, what information moves, who acts next and what the client sees. This gives suppliers a clearer basis for estimating the work and helps keep optional features out of the initial scope.

When custom development is worth considering

Before commissioning a bespoke portal, check whether your existing systems or a packaged service can handle the essential client journeys. Compare the options against the same requirements, including what staff will need to administer and maintain.

• Check what you already use. Ask the person responsible for your CRM or client-management system whether it can support the required client-facing tasks through configuration or an available portal option. List what it can do now, what would need changing and which tasks would still be handled by email or spreadsheets. Confirm how staff would manage client access and updates.
• Assess packaged options. Look for an off-the-shelf portal or service whose established workflows match your needs. Walk through a typical client task, such as submitting a request or finding a document, and check whether the process fits without awkward workarounds. Consider whether its operating model, administration and connections to your other systems are acceptable.
• Identify where the fit breaks down. Custom development may be worth exploring if an important client journey cannot be supported by available tools, staff repeatedly copy information between disconnected systems, or the process depends on steps specific to your business. Be precise about the problem: identify who starts the task, what information they provide, who acts on it and what the client needs to see next.
• Include the cost of owning a bespoke solution. A custom portal can be shaped around agreed workflows, but your business must also specify what it needs, take part in testing and plan for ongoing maintenance. Staff will need clear responsibilities for managing users, handling content or requests, and deciding what happens when a process changes. If no one can own those tasks, a simpler option may be more suitable.
• Consider changing the process instead. If the underlying workflow is unnecessarily complex, adapting it may solve the problem without a new portal. You might configure existing software, use a packaged service, or simplify how staff and clients exchange information. Compare the operational change involved, not just the software.
• Make a like-for-like comparison. Use the same essential client journeys, administration needs, system connections and ongoing responsibilities for each option. Mark which requirements are essential and which can wait. Ask suppliers to explain any requirement their proposal does not cover, so a lower initial scope is not mistaken for a complete fit.

Use this worksheet to break down a portal quote

Use the same worksheet for each supplier, asking them to describe what each work area includes, what it depends on and how much effort they estimate. It is a framework to complete with suppliers, not a market estimate: the figures will only be comparable when the scope and assumptions are clear.

Ask suppliers to estimate effort in days and show the calculation for every line as estimated days multiplied by their day rate. Have them name deliverables and the cases covered, rather than relying on broad labels such as “design” or “testing”.

Ask each supplier to identify exclusions and the assumptions most likely to change the estimate. Dependencies may include access to current systems, usable sample data, timely business decisions and staff availability to review designs and test real journeys. If these are not ready, ask how that affects the estimate and proposed work.

Use the completed worksheet to compare like with like, then ask how additional requests would be assessed and agreed. An estimate remains dependent on its stated scope and assumptions; the worksheet makes differences visible but does not turn an early estimate into a fixed price.

Connections, migration and testing can add effort

• Map each connection. List the systems the portal must exchange information with, such as the tools staff use to manage client records, requests or payments. For each connection, specify which information moves in each direction, how often it needs to update and which system is the source of truth for each record. Ask suppliers to state separately the effort for each integration and any assumptions about access to the existing system.
• Plan for exceptions. Decide what should happen if information cannot be sent or received, arrives incomplete or conflicts with a record elsewhere. Identify who is expected to investigate, correct the information and retry the update. If staff will need to reconcile records across tools, include that workflow in the scope rather than treating the connection as a simple transfer.
• Define what will be migrated. Specify which client records and files need to move, where they are held and whether historical information is needed in the portal. Agree how the imported material will be checked, who will review it and what should happen to duplicated, incomplete or outdated entries. Ask the supplier to separate migration effort from integration work.
• Include real-world exceptions in the journeys. Describe what a client sees when a required document is missing, a request is rejected, an account cannot be accessed or a status needs staff attention. For each case, name the person who acts next and the information they need. This helps prevent a smooth standard journey from hiding unclear hand-offs.
• Test complete journeys. Ask for testing to cover each relevant user type from start to finish, including the points where a client action becomes a staff task and where staff updates become visible to the client. Checking individual screens alone may not reveal a broken hand-off, incorrect permissions or a status that fails to update.
• Agree launch and handover work. Clarify who reviews the portal before release, who will manage users or content, and how issues will be handled afterwards. Record any training, guidance or handover materials expected, along with who on your side will take responsibility for them.
• Make the quote comparable. Return to the worksheet and ask suppliers to show integration, migration, testing and launch effort as separate lines where applicable. Have them note what is included, what depends on your team or another supplier, and what has been left out. That makes differences in scope easier to spot before comparing totals.

Separate build work from the costs of running the portal

Keep the cost of getting the portal built separate from the cost of operating it. A proposal can cover the initial work without including the services, support or staff time needed once clients start using it. Record what is included, what is excluded and who is responsible for each item.

• One-off project work: List discovery, design, development, integrations, data migration, testing, launch and any agreed handover. For each item, note the deliverable and the assumptions it depends on. For example, clarify whether the handover includes guidance for staff who will manage client accounts.
• Hosting: Ask what hosting is included, what it covers and how charges may change as traffic or stored documents change. Check whether the portal relies on separate services for functions such as file storage or email, and whether their charges are included or managed separately.
• Maintenance: Ask what ongoing maintenance covers, how it is arranged and what is excluded. Establish how faults, updates and changes to the portal are handled, and how work that is not part of the agreed maintenance is assessed.
• Support: Clarify how staff can raise a support request, who can do so and what kinds of issue are covered. Confirm how requests for new features are treated; support for an existing capability and a request to change a workflow may be handled differently.
• Third-party services: Ask the supplier to identify any external services the portal depends on, who will set up and manage each account, and who is responsible for any associated charges. Do not assume these arrangements are included in the development proposal.
• Internal staff time: Include the work your own team will need to do after launch. This may include creating and updating client accounts, reviewing requests, uploading or replacing documents and keeping portal information current. Decide who owns each task and what happens when that person is unavailable.
• Compare the operating model: Record the recurring categories, responsibilities and exclusions for a custom portal, a packaged option and software you already use. Compare the ongoing work as well as the initial proposals: a lower build scope may still leave your team with more administration, while an existing tool may already cover the workflow you need.

Before approving a proposal, ask the supplier to distinguish included work from optional work and explain how additional requests are agreed. That gives you a clearer view of what the first project covers and what your business will need to plan for afterwards.

Ask suppliers the same questions before comparing quotes

Send every supplier the same brief so their proposals describe comparable work. Keep it short, but make the business process clear: who uses the portal, what each user needs to do, what information is involved, which systems it must connect to, what data may need moving and what support you expect after launch.

Use this checklist when requesting and reviewing proposals:

• Confirm the scope: Ask each supplier to respond to the same essential client journeys and staff administration needs, including realistic exceptions such as incomplete requests or a document needing correction.
• Request a breakdown: Ask for discovery and design, build, integrations, migration, testing and launch to be shown separately. For each line, ask what is included and what deliverable or outcome it covers.
• Surface assumptions: Ask what the estimate assumes about your existing systems, data quality, access to staff and client feedback, and who will supply or approve content and decisions.
• Check exclusions and dependencies: Ask what is not included, what the supplier needs from you or another provider, and which unresolved decisions could change the scope.
• Clarify change control: Ask how a request outside the agreed scope is assessed, approved and estimated before work proceeds.
• Separate ongoing costs: Ask what hosting, maintenance and support cover, what remains your responsibility, and which costs are separate from the build.
• Compare like with like: Mark differences in included features, responsibilities, assumptions and exclusions before comparing estimated effort. A lower estimate may cover less work.
• Protect the essentials: If the proposal needs narrowing, prioritise the core workflows and defer optional features. Do not remove permissions, exception handling or testing the business needs to run the portal safely and reliably.

Once the brief is clear, you can request a project quote for a custom web application.

Check responsibilities before the portal handles client information

Before including personal information in a client portal, make the information and operating responsibilities part of the supplier brief. This gives you and prospective suppliers a clear basis for checking what the portal needs to do and who must handle each part of its operation.

• List the information: Note what clients will submit, view, change or download, and what your staff will add or manage.
• Map access: Identify which client users and staff roles need access to each type of information, and who will approve or change those permissions.
• Identify other services: Ask which suppliers or services may be involved in hosting, communications, payments or other portal functions, as relevant to your planned scope.
• Assign the checks: Record who in your business is responsible for confirming operational requirements, and what information or decisions they need from the supplier.
• Ask for clear boundaries: Ask suppliers to state what they will handle, what remains your responsibility and which assumptions their proposal makes.

This checklist is a prompt for scoping, not legal or data protection advice. If you are unsure what responsibilities apply to your planned use, check with an appropriate adviser and include relevant requirements in the brief before comparing proposals.