Blog Overview
The portal module is cheaper in month one and may cost more after three years. Six dimensions to compare, what the vendor quote omits, and what to prepare before requesting a price.
When a company decides to open a portal for its customers, two options appear quickly: the customer portal module inside the current ERP, or a standalone portal that connects to the ERP through APIs. The first looks cheaper because it “already exists.” The second looks cleaner because it is “designed for the user.” Both impressions can be right or wrong depending on user count, data type, and how the ERP vendor prices access.
The decision is not purely technical. It is a licensing and operational-risk decision. A portal module may cost less in the first month, then become more expensive when the vendor charges per external user, or when customisation falls outside the support agreement. A custom portal may cost more up front, then become cheaper as the user base grows.
What the portal module quote does not tell you
A portal module quote usually states licence and implementation cost. It omits three things: the price per external user, the limits of customisation, and the upgrade path. The first appears in the second annual invoice. The second appears when you ask for a different screen. The third appears when the vendor ships a new ERP version and the customer portal breaks.
Ask these questions before signing, and get the answers in writing: how many external users are included? What is the annual cost per additional user? Can the interface change without leaving support? Who tests the upgrade? What is the service-level agreement when the portal is down? If the answers are vague, the price is not the price.
Where a custom portal wins
A custom portal wins in three places. First, experience: it can be designed around the task the customer performs, not around the ERP schema. Second, integration: it can combine ERP data, ticketing, and payments into one interface. Third, ownership: code, design, and data stay under your control and are not tied to a vendor's upgrade cycle.
But it creates a new responsibility. You now operate a system your customers use every day. That means monitoring, backups, support, and a security plan. If you are not ready for that, the ready-made module may be the more rational choice even if its experience is weaker.
A decision across six dimensions
Compare the two options on the same dimension, not on the final price. Each line below can flip the decision if it is extreme.
| Dimension | ERP module | Custom portal | The deciding question |
|---|---|---|---|
| External users | Often licensed per user | Fixed cost spread across users | How many users in three years? |
| Experience | Constrained by ERP patterns | Designed around the customer task | Is experience a competitive advantage? |
| Customisation | Limited or outside support | Full, within project scope | How many distinct screens do you need? |
| Integrations | Mostly inside the vendor stack | Open through APIs | Do you need systems outside the ERP? |
| Upgrades | Tied to the vendor cycle | Independent, but needs maintenance | What does an upgrade cost every three years? |
| Responsibility | Vendor runs the infrastructure | You run infrastructure and support | Who answers the customer during an outage? |
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
Customer data and compliance
A portal exposes customer data to external parties, which raises the level of responsibility. In Saudi Arabia, the Personal Data Protection Law sets limits on collection, processing, and disclosure, and requires notification when a breach occurs. Before building the portal, define what each user type sees, who approves access, and how activity is logged. These are design decisions, not security add-ons.
Also ask where the data is stored. Some organisations require in-Kingdom hosting; others accept regional hosting under a clear contract. The decision affects the ERP itself, not just the portal. Review the client portal compliance checklist before design starts.
The third path: a portal in stages
The decision does not have to be binary. You can start with the ERP module for a limited set of users while building an independent interface layer that connects through APIs. In year one the module is the official channel; in year two users move gradually to the new interface. This path lowers launch risk, but it adds the cost of running two systems during the transition.
Choose this path only if you have a team that can run two systems, a clear transition date, and a budget for the overlap. Without those three, the staged path becomes two permanent systems, and the customer pays for both without a clear gain.
What you need before requesting a quote
External user list. Current count and three-year forecast, split by user type.
Task map. What each user wants to complete in the portal, not what you want to display.
Source of every data field. From the ERP, another system, or manual entry. Fields without a source become an open decision.
The ERP contract. Licensing, customisation, upgrade, and API clauses.
Sector requirements. Hosting, retention, audit, and incident reporting.
Who answers support. The team, hours, and escalation path during an outage.
Operating budget. Not just build: hosting, monitoring, maintenance, and support.
Exit plan. How you extract data if you change vendor or system.
Frequently asked questions
Is a custom portal always more expensive? For the build, usually yes. For operations, it can be cheaper when the user base is large.
Can we build a portal on top of the ERP without changing it? Yes, through APIs or a read layer. You need a clear agreement on who owns the integration.
How long does a portal take? It depends on the number of tasks and integrations. A focused project starts from a published scope, then is quoted after discovery.
Do we need a new support team? Yes, or a clear support contract. The portal is a channel the customer sees daily, not an internal system.
What if the ERP will be replaced? Do not build deep integration before the replacement decision. Build an interface layer that can move.
Sources
- PDPL implementing regulation — processing, disclosure, and notification duties.
- OASIS — open standards used in enterprise system integration.
- Rasad's published price bands — the figures before the call.
- Enterprise systems — how we build integrations and portals.
- Client portal development cost — the scope breakdown.
