Do You Need a Custom Client Portal or an Off-the-Shelf One?

TL;DR

• Start with a task the client should finish without emailing your team: find the current status, provide a missing document or approve a specific proposal.
• Check your existing CRM or service platform first. A portal for support tickets and a portal for job approvals do not necessarily solve the same problem.
• Compare native portals, standalone products, configurable builders and custom development against the same client journey, including corrections and exceptions.
• Require evidence that approval belongs to the right version and customer, that internal information stays private, and that failed updates are visible and recoverable.
• Include setup, the required subscription tier, integration maintenance and remaining staff work in the comparison. A new place to copy statuses is not the outcome you are buying.

What should the client finish without emailing you?

For example, suppose a service business tracks jobs in a CRM, receives documents by email and asks clients to approve proposals in message threads. A customer calls for an update because the latest status is not in the thread they have. An employee opens the CRM, finds the job and replies.

The useful requirement is specific: the client can open the right job, see what happens next, supply the missing document and approve the current proposal. Staff receive those actions against the same job they already manage. The customer should not need to explain the job again, and the employee should not need to copy the response between systems.

This service-business example and the tests below are hypothetical. They illustrate a buying decision, not a Caemcore client result.

Collect a few actual requests from your own customers before selecting software. Separate requests for information from requests to change something. Showing a delivery date is one requirement; letting the client request a different date, with staff confirmation, is another.

Also ask whether a full portal is necessary. When the only problem is an occasional file request or a missing status notification, first test a supported upload or notification workflow in the tools you already use. Creating accounts and another destination for customers may add more work than it removes.

Check what the ready-made portal actually exposes

The label client portal does not define a common set of capabilities. Start with the system that already holds the required records, then inspect its customer-facing options. These documentation examples show why that check matters; they are not a product ranking or a report of hands-on testing.

HubSpot's current support portal is ticket-based. Its documentation says only tickets appear, with settings for access to a contact's own tickets or company tickets. That is a useful candidate when the question is about a support request. It does not establish that the same portal can handle the versioned proposal and job-approval workflow in our example. Ask for that behaviour to be demonstrated separately.

Zoho CRM portals can expose selected modules and related records, with permissions for the actions users may perform and fields they can access. This is a different starting point: the client may work directly with selected CRM data. Check how the relationship identifies the right customer's records and which fields remain read-only. Giving someone permission to edit a record is not, by itself, a defined approval process.

A configurable builder also needs an implementation plan. For example, Softr's global data restrictions distinguish viewing from creating, editing and deleting records; the latter global controls require Business or above in the documentation checked for this article. Its Comments block is outside those global restrictions. That exclusion is a reason to inspect the component's own controls, not evidence that comments are necessarily exposed. Include the required plan and permission configuration in the proposed solution.

For any product, write down the supported capability, the configuration or integration it needs, and the requirement still unproved. A connector logo or a feature named approvals should start the next test, not end the comparison.

Compare four routes against the same client journey

Give each candidate the same job, customer roles and exception cases. The choice is not limited to a subscription versus a completely new application. A narrow custom connection may let a suitable ready-made portal do the work while your CRM stays in place.

A standalone portal can be appropriate even when it creates a new place to store records. The question is whether that ownership is deliberate and the handoffs work. Reject a proposal that leaves both systems editable without explaining which status or version wins when they disagree.

Define the customer view and the approval record

For the example, keep the CRM responsible for issuing the proposal and recording the operational job status. Define the customer-facing stages separately: waiting for your document, proposal ready for review, or work scheduled. An internal status used for staff coordination may not tell the client what to do next.

Choose the fields deliberately. A customer may need the delivery date and agreed scope, but not an internal margin, staff note or another customer's attachment. OWASP's authorization guidance calls for permission checks on every request, outside client-side controls. Ask the supplier to test the records and files themselves, including direct requests, rather than only showing that the dashboard hides other jobs.

Treat an approval as a decision about a particular version. In the example, record the job, proposal version, authorized person, decision and time. If the scope changes, preserve the earlier decision as history and require a decision on the new version under the agreed rules. This is an operational acceptance record; the article does not establish legal signature requirements.

An old link must not silently approve replacement terms. When the customer opens version one after version two has been issued, show that the earlier version has been superseded and take them to the current proposal. Verify the version and the person's authority when accepting the decision, not only when the page first loads.

Decide where that decision becomes authoritative and how the CRM receives it. If the portal records a valid decision but the later CRM update fails, retain the decision and show the internal update as pending. If the system cannot verify the current proposal, it must not claim approval is complete. These are different failure states and need different messages.

Microsoft's Retry pattern explains why retrying an operation can repeat its effects when the first request succeeded but its response was lost. Apply that to the portal: a second click or retry must not create another job or overwrite a newer decision. Ask how staff find a pending update and recover it without reconstructing the customer's response from email.

Give every candidate this demonstration script

Use synthetic records in a non-production environment. Create two customer companies and a staff operator. Give the first company an authorized approver and a read-only contact; give the second an unrelated test user. Prepare an existing job with a proposal, a private attachment and an internal note. The proposed configuration or development scope should demonstrate the following six checks.

1. Find the existing job. Invite a customer and have them open the job without staff supplying another reference by chat. Check the stage and next action. Using the other customer, attempt to retrieve the same record and attachment directly; no private information should be disclosed.
2. Provide a document and recover from rejection. Upload an allowed test file to the intended job. Try a file outside the agreed type or size rules and confirm that the failure is explained without marking the request complete. The operator should find the accepted file on the correct job, with no manual reattachment.
3. Open an outdated proposal. Issue a revised proposal after sending the original link. Open the old link and confirm that the customer can identify the current version. Leave a page open while another revision is issued, then attempt approval; it must not accept unseen replacement terms or silently apply a decision to the wrong version.
4. Approve with the right authority. Confirm that the read-only contact cannot submit the approval, including through a direct request. The authorized approver accepts the current version. Inspect the saved version, identity and decision, then repeat the submission and confirm that only one business outcome results.
5. Interrupt the CRM handoff. Simulate a CRM failure after the valid decision is recorded. The client and operator should see the agreed status, not a false confirmation that work is scheduled. Restore the connection and process the pending update. The job and decision history must agree without a duplicate job or a lost approval.
6. Finish and retrieve the evidence. Complete the job, then retrieve its final status, documents and approval history through the agreed customer access and export process. Check that the export is understandable without opening each record in the portal and that it does not include internal notes or another customer's records.

For uploads, OWASP recommends controls such as permitted file types, size limits and authorization, and warns against trusting the supplied Content-Type header alone. Have the implementer verify those controls. A file-picker setting in the browser is not the entire upload policy.

Mark each demonstration as passed, failed or untested, with the relevant configuration and proposed plan. Name the remaining work rather than accepting a promise that it is possible. These are acceptance checks for the selected workflow, not a complete security assessment or certification.

When is custom development justified?

Custom work deserves a proposal when a failed check blocks an essential part of the client journey and a supported configuration or integration cannot close it at acceptable cost and risk. For example, the business may need a proposal assembled from several internal systems, with approval tied to a specific version and a permission model the candidate cannot express.

Before accepting that conclusion, have the product vendor or implementer demonstrate the alleged limit. A failed first configuration attempt does not prove the product cannot do the job. Conversely, a promise about a future feature does not establish that the requirement works now.

If the only missing part is writing an approved decision back to the CRM, investigate that connection first. If the portal's data model cannot represent the required decision and its history, a custom customer-facing workflow may be the smaller coherent solution. It can still use managed sign-in, storage and the existing CRM rather than reproduce those products.

Do not commission custom development just to avoid making process decisions. Someone still has to decide who can approve a proposal, whether an approval can be withdrawn and what happens after a correction. Nor should a custom build be the default response to a branding preference when the business workflow already works in a ready-made option.

Compare the operating work before choosing

Request a costed proposal for the demonstrated configuration, not the cheapest advertised plan. Separate one-time setup, data preparation, integrations, testing and training from recurring subscriptions, hosting and support. Check how the chosen product charges for internal users, external clients, storage and the required access controls.

Then record the work left with staff. Who invites the next client, fixes an incorrect account association, updates the displayed status or investigates a failed handoff? A low subscription with regular manual status copying is a different purchase from an integrated workflow. Do not treat staff hours as automatic cash savings; identify the work those people would actually stop doing.

For a configurable builder or custom system, name who maintains the connections and permissions after launch. For every route, establish how the business retrieves its records, files and decision history on exit. Owning source code alone does not demonstrate a usable export or a maintainable deployment.

Pilot one complete job before inviting every client

Choose a small, representative group and run the whole journey, including a correction. Ask a customer to find their next action and complete it on the device they normally use, without the project team coaching every click. Track where they still need to call and whether staff still move information by hand.

Keep a named fallback for a failed login, upload or status update. It should feed the same job record rather than create a parallel approval history. Review whether the portal answers the original requests more directly before expanding it to more workflows.

If a ready-made portal passes the required checks and the operating arrangement is acceptable, use it. If only the handoff fails, resolve that bounded gap. Build a custom portal when the evidence identifies work the other routes cannot reasonably support, with acceptance conditions that show exactly what the new system must do.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Do we need a mobile app as well as a client portal?

Start by testing the required journey in a mobile browser, including sign-in, reading a proposal and uploading a file. Commission a separate app only when a defined requirement justifies its delivery and maintenance. Offline work or particular device capabilities need their own investigation; a preference for an app icon is not the same requirement.

Can customers keep replying by email?

Yes, provided the operating process connects the reply to the right job and records any decision through the agreed approval route. Identify who handles replies that cannot be matched automatically. Keep the portal and email from becoming two competing histories, and tell customers where to expect the authoritative confirmation.

How much historical work should be visible at launch?

Start with the active jobs and reference documents the customer needs to complete the new workflow. Decide separately which closed jobs must remain searchable and which can stay in an accessible archive. Test the links between current work and old documents before closing an existing service. Do not silently discard history to simplify the first import.

Can we launch the portal without online payments?

Yes, when payment collection is not required to complete the chosen workflow. Keep the existing invoicing process and explain clearly where payment happens. If the portal displays an invoice or payment status, define its source and update behaviour. Do not show a stale copied status as confirmation that an invoice has been paid.

What should we give a supplier before asking for a quote?

Provide an anonymized example job, its documents and revisions, the client and staff roles, and the systems that currently hold the records. Include the actions clients request by email and one difficult exception. Ask the supplier to mark what works through configuration, what needs development, what remains untested and who maintains the result.

Sources

• HubSpot, Set up a support portal. Checked 13 September 2026.
• Zoho CRM, Setting up portals and inviting users. Checked 13 September 2026.
• Softr, Global data restrictions. Checked 13 September 2026.
• OWASP, Authorization Cheat Sheet. Checked 13 September 2026.
• OWASP, File Upload Cheat Sheet. Checked 13 September 2026.
• Microsoft Azure Architecture Center, Retry pattern. Checked 13 September 2026.

The product examples are based on vendor documentation checked on 13 September 2026, not hands-on testing or a ranking. The service-business scenario and demonstration script are hypothetical. The checks are proposed acceptance criteria, not Caemcore client results or a complete security assessment.