Buy an off-the-shelf customer portal when your process resembles the market standard and the vendor's data model fits your account structure. Build when the portal must expose your own operational data, follow rules no product supports, or become something customers choose you for. Compare three years of total cost, not the licence fee.
The decision is usually settled by two things buyers examine last: how deep the integration needs to go, and how complex your account hierarchy is.
Key takeaways
- Account structure decides more than features: Resellers, parent accounts and delegated access are where standard products most often stop.
- Integration depth is the second test: Products present their own data model well and struggle with yours.
- Compare three years: Licence, configuration, integration, per-user growth, internal admin time, and the cost of workarounds.
- Workarounds are a real cost: Price them annually rather than accepting them as free.
Start with your account model, not your feature list
Feature comparisons rarely decide this. Almost every portal product does documents, status and messaging adequately.
What separates them is whether they can represent how your customers are actually organized. If a customer is one person with one login, most products will fit. If a customer is a company with several users at different permission levels, a parent organization that needs visibility, a reseller acting on their behalf, or a delegated administrator who can add colleagues, you are testing something most standard products handle shallowly.
Write down your real account structure, including the awkward cases, and test each candidate against it during evaluation rather than after purchase.
Test the four dimensions that decide the outcome
Workflow fit is whether your process can adapt to the product without damage. Some adaptation is healthy — standard products encode reasonable practice. Adaptation becomes damage when it removes something customers value or forces staff into a parallel system.
Integration is how well the product reads and writes your systems of record. Ask specifically whether it can write back, or only display. Read-only portals are far cheaper to implement and far less useful.
Launch effort favours buying, usually by months. This is the strongest argument for off-the-shelf and it is real.
Control favours building: over the roadmap, the data, the user experience, and whether a vendor's pricing change becomes your problem.
Price three years, not the licence
Build a total figure for each option that includes:
- Licence or build cost
- Configuration and implementation
- Integration work, which is required either way
- Growth in per-user or per-transaction fees at your projected volume
- Internal administration time
- The annual cost of the workarounds you will adopt where the product does not fit
That last line is the one buyers omit, and it is frequently decisive. If a product cannot handle your approval hierarchy and the workaround is two staff spending an hour a day reconciling, that is a real annual cost belonging in the comparison.
For how to assemble that comparison so it survives review, see how to build a business case for custom software.
Recognize when buying is clearly right
Buy when most of these hold: your process is close to the industry norm; the portal is a service improvement rather than a differentiator; you need it live this quarter; you have no internal capacity to own software long term; and the vendor's account model matches yours without contortion.
Under those conditions, building is usually a more expensive route to a similar outcome, and the delay costs more than the flexibility is worth.
Recognize when building is clearly right
Build when the portal must surface data that lives only in your own systems; when your rules — pricing, approvals, entitlements — have no equivalent in any product; when the portal is part of why customers choose you; or when you have already bought a product and are paying for workarounds that exceed what building would have cost.
That last case is common and rarely examined. Organizations often persist with a poor fit because the licence is already paid, without pricing the operational cost of the gap.
Consider the middle path
You do not have to choose once and forever. A frequently sensible route is to buy for the standard capability, integrate it properly, and build only the specific piece the product cannot do — a custom entitlement view, a bespoke ordering flow — presented alongside it.
This keeps the delivery speed of a product with the fit of custom work in the one place fit actually matters. It requires that the product has a usable API, which is worth confirming during evaluation rather than discovering later.
Related guides
- Alongside Custom vs Off-the-Shelf Customer Portals: How to Decide, continue with Customer Portal Development: Workflows, Integrations, and Adoption.
- Alongside Custom vs Off-the-Shelf Customer Portals: How to Decide, continue with Digital Customer Onboarding: Steps, Metrics, and Examples.
If the work prompted by Custom vs Off-the-Shelf Customer Portals: How to Decide leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Customer Platform.
Ali Boran Gazel