Commissioning a Customer Portal: Features, Cost, and Process

At some point it tips over: customers email to ask about their order status, documents get sent for the third time, your team answers the same questions on a loop. A customer portal solves exactly that – a protected area where your customers find, trigger, and view for themselves what they currently have to call you for.

This article answers the three questions that precede every portal project: what should it do, what does it cost, and how does development work – including the honest preliminary question of whether it needs to be custom-built at all.

Customer, supplier, partner portal – same build, different users

Before the features, a point of terminology that quotes tend to blur. We regularly get asked for a “supplier portal” or a “partner portal” as though those were different projects. Technically they are not. All three consist of the same parts: protected access, accounts with tiered permissions, cases with a status, documents, and integrations into the systems where the data actually lives.

What differs is the user group – and from that follow the permissions and the scope of data:

• Customer portal. Customers see their orders, invoices, deliveries, tickets.
• Supplier portal. Suppliers see purchase orders, confirm delivery dates, upload certificates and documents. Here data flows in more often than out.
• Partner or dealer portal. Partners see price lists, leads, commissions, training material – often with their own pricing and discount logic.
• Service portal. The focus sits on tickets, service contracts, equipment records, documentation.

This is more than an exercise in vocabulary, because it feeds straight into the cost. If you want to serve customers and suppliers, you don’t need two portals – you need one with two role areas. Two separate applications mean double hosting, double updates, double login logic, and two places where the ERP integration can break. We have taken that apart a few times after it was started separately, and that is more expensive than scoping it properly once.

What a customer portal can do

“Customer portal” is an umbrella term. In practice, portals are assembled from a handful of recurring building blocks – and the craft lies in building only the ones that hit your bottleneck:

• Accounts and roles. Customers log in and see exactly what they are allowed to see – from individual clients to client companies with multiple users and tiered permissions.
• Status and cases. Orders, projects, tickets, or deliveries with their current state – the most common portal feature, because it replaces the most common reason for calls.
• Documents. Invoices, contracts, reports, certificates – stored centrally instead of scattered across email, accessible only to the right customer.
• Requests and orders. Structured forms instead of free-text emails: new order, support case, appointment request – with the required fields your team would otherwise have to chase.
• Integrations. The block that decides the portal’s value: it shows data from your ERP, CRM, or inventory system – instead of someone maintaining it twice. Without integration, a portal is just another island.
• Billing and contracts. From viewing open items to self-managing contract data – depending on your business model.

The bottleneck test: is the portal worth it at all?

We like to open portal conversations with the question that can actually prevent a quote: which specific bottleneck is the portal supposed to remove? If the answer isn’t something you can count, the project isn’t ready – and an expensive portal without a use case helps nobody, us included.

You can count it with numbers that live inside your company, not in an industry study. Take a normal week and note down:

1. How many enquiries reach your team that are pure status requests? (“Where is my delivery?”, “Has the invoice gone through?”, “Did you get the documents?”)
2. How long does one of those take on average, including looking it up in the ERP and writing back?
3. How often does the same record get entered in two places because two systems don’t talk to each other?

Points 1 and 2 give you the hours per week currently spent on giving out information. Projected over a year and valued at your internal hourly rate, your portal budget now has a real number across from it – yours, not ours. We deliberately don’t quote a percentage of relief here, because it depends on your customer mix, and any outside number at this point would be a guess.

Two things matter about this calculation. First: a portal doesn’t remove status enquiries entirely. It shifts them – some customers will keep calling, especially at the start. What’s realistic is that the simple, repeated requests fall away while the substantive conversations remain. Second: point 3 is often the bigger lever than point 1, and it rarely gets counted. Duplicate data entry doesn’t just cost time, it produces discrepancies between systems that somebody cleans up later.

If the calculation comes out thin, that is a good result. Then you don’t build a portal – you remove the bottleneck another way, with a better automated status email, a search function in the existing system, or a tidier way of sending documents.

Off-the-shelf, custom, or extending what you have

Not every company needs a custom portal, and anyone selling you one without this check is advising you badly. Ready-made portal builders and industry solutions go live faster and cost less to start – and they are perfectly sufficient when your processes match the standard and your data doesn’t need deep integration with your systems.

Custom becomes the answer for three reasons:

1. Your processes are your advantage. When the portal should reflect how your company actually works – not how a software vendor imagines companies work.
2. Integrations are mandatory. As soon as ERP, CRM, or inventory systems need connecting, integration depth decides – and that is where builders hit their limits quickly.
3. Data sovereignty. Your own portal runs on your infrastructure, with your data, independent of a vendor’s pricing model and roadmap.

The test question in one sentence: are you adapting your company to the tool – or the tool to your company? The former argues for off-the-shelf, the latter for custom.

There is a third option that comparisons almost always leave out: the portal inside the system you already own. Many ERP, CRM, and shop systems ship a customer account that can do considerably more than most companies use. Before anything new gets built, the existing setup is worth a look – an enabled customer account in the shop, or an activated service portal in the ERP, costs a fraction and is usable in weeks rather than months. The limit of this option is usually the design and the flexibility of the permissions: you get what the vendor envisaged, in the vendor’s look, with the vendor’s wording. For a portal that only provides information, that is often enough. For a portal that is part of your offering and should look like your company, it isn’t.

	Off-the-shelf	Existing system	Custom build
Time to live	weeks	days to weeks	2–4 months (first version)
Entry cost	low	very low	from 10,000 €
Running cost	licence per user/month	usually included	hosting + maintenance
Processes	you adapt	you adapt	mirrors your workflows
Integrations	whatever the vendor offers	only within the system	open, but must be built
Look and wording	vendor standard	vendor standard	yours
Data sovereignty	with the vendor	with the vendor	with you
Dependency	pricing model and roadmap	vendor decisions	maintainability of the code

That last row is the one most often underestimated. A custom build trades dependency on a vendor for dependency on maintainable code and a team that looks after it. That is usually the better dependency, but it is not freedom.

Which feature gets built first

In portal projects, the order matters more than the scope. Our rule: the first version contains one use case completely, not five halfway.

For prioritising, a plain comparison helps – how often does the case occur, and what does it cost today? Status information almost always lands at the top: high frequency, small build, immediately noticeable. Document access usually follows directly, because it reuses the same permission logic that status needs anyway.

What belongs in the first version:

• Login including password reset (surprisingly often forgotten, then bolted on in production)
• the one core function that removes the bottleneck
• the one integration that feeds that function with real data
• a minimum of administration for your team: create users, activate them, lock them

What deliberately waits: notifications in every variant, self-service for contract data, dashboards with analytics, a mobile app, multiple languages, per-field permissions. These are all sensible things. They are just not sensible before real users have been in the portal – because afterwards, part of that list looks different. We have yet to see a portal where the priorities after the first month of live operation were the same as in the workshop.

Login and permissions: the underestimated part

In quotes, “login and user management” usually appears as a single line. In the build, it is the area where costs vary most – between “one afternoon” and “a quarter of the project”.

How users sign in

The choice of sign-in method affects effort, security, and adoption:

• Email and password plus two-factor. The standard case. Cheap, understood, works everywhere. For portals holding business data, the second factor is part of it, not an option.
• Magic link. Sign-in via a one-time link by email, without a password. Pleasant for users who sign in rarely – typical for portals customers look at four times a year. Less suitable where people work daily.
• Single sign-on via the customer’s own company login. If your customers are larger organisations, this gets requested eventually: sign-in through the customer’s Microsoft or Google account, usually via OAuth2 or SAML. Technically feasible and sensible – but every identity provider you connect is its own effort, and SAML adds coordination with your customer’s IT department. That belongs in the cost plan, not on the wish list.
• Passkeys. Sign-in via fingerprint or device key instead of a password. For portals with regular users this is now a serious option, because it structurally rules out phishing.

Our recommendation for the first version: password plus two-factor, built properly, with the architecture laid out so SSO can be added later. Building SSO before a customer has asked for it is usually money better spent on the core function.

The roles model

This is where the biggest cost trap of the whole project sits, and it sounds harmless. “Every customer sees their own data” is a simple sentence and a simple implementation. “Client companies have admin users who can grant permissions to colleagues” is a different project.

The difference: in the first case, a record belongs to a user. In the second, it belongs to an organisation, users belong to organisations, permissions hang off the combination – and every query in the system has to honour that correctly. Miss a single place, and one customer sees another customer’s data. That is the failure that doesn’t make a portal slow or ugly, but unusable.

So two things we don’t negotiate. Access rules get defined centrally, not re-invented per page – in Laravel, via policies. And they get tested, with automated tests that check exactly that: user A requests user B’s data and is refused. Those tests are part of what test coverage costs in a quote, and they are the line item where saving money gets most expensive.

The questions that pin down the roles model are unglamorous and should be settled before the quote: can a user belong to more than one client company? What happens to their cases when they leave the company? Can a customer invite colleagues themselves, or does your team do that? Are there users who may only read? And does your support team need the ability to view the portal as a customer sees it, so they’re looking at the same screen during a query? That last question is almost always raised after launch – and it is more expensive to add later than to plan for.

Integrations: where the project is decided

Connecting ERP or CRM is, in our experience, the part with the most surprises – dated APIs, missing documentation, data quality. That is why it belongs at the start of the project, not the end: only once it is clear which data flows reliably is it worth building the interface on top.

What that looks like concretely is shown by a project of ours that isn’t a portal but had the same problem. For Tekath Headhunting we connected a website to the industry system HR4You. The target system was unknown to the website out of the box, so we built our own integration that pulls data on a schedule, maps it onto our own data model, caches it, and keeps that cache in sync. Tekath maintain their vacancies only in HR4You; on the website they appear automatically. That three-step – pull, map, keep in sync – is exactly the work behind every portal integration. The effort does not sit in fetching the data. It sits in the mapping and in keeping it in sync.

There are three patterns, and they differ a lot in effort:

• The portal asks the system live. Always current, no duplicate storage. Requires the target system to be fast and available enough – if the ERP goes down, the portal shows nothing. A problem for lunchtime maintenance windows in the ERP.
• The portal fetches data on a schedule and stores it. Robust, fast, keeps working when the ERP is briefly away. In exchange, the data is as current as the last sync, and you need an answer to what wins in a conflict.
• The system actively notifies the portal of changes. The cleanest variant where the target system offers it. Many mid-market ERP systems do not.

Almost every portal we have built or looked at runs on a mix: sync master data on a schedule, query status live. That decision isn’t a matter of taste, it hangs off the target system – which is why it comes before the quote, not inside it.

The questions to ask your system vendor

This part is worth preparing before an agency is even in the room. The more of it is answered, the more reliable every quote you receive becomes – including ours:

1. Is there a documented API, and can I see the documentation up front?
2. Does access cost extra – as a licence, a module, or per call?
3. Is there a test system, or is development done against production data?
4. Which fields does the API actually return? (Not: which fields exist in the system.)
5. Is there a limit on how often it may be called?
6. Are changes pushed actively, or does the portal have to poll?
7. Who is the technical contact at the vendor, and how quickly do they respond?

Questions 4 and 7 move the most money. The fact that an API exists says little about whether it hands over the fields your portal is supposed to show. And a project waiting on answers from an external vendor is a project standing still, however good the development team is. “But the ERP has an API” is the most expensive sentence in the portal business, because it substitutes for a check nobody performed.

Also expect the data quality in the target system to be worse than assumed. Customer numbers that appear twice, addresses in a free-text field, statuses that grew historically and are used differently by two departments – that is the normal case, not the exception. A portal exposes these things, because it shows customers data they will act on for the first time. That clean-up work belongs in the budget.

The technology behind it: why we build portals with Laravel

A customer portal is, at its core, a web application made of authentication, permissions, data access, and integrations. Those are exactly the building blocks Laravel ships with as a mature PHP framework: login including two-factor, policies for fine-grained access rules, queues for background jobs like PDF generation or data sync, and a clean foundation for API connections in both directions. Why that is the economically sensible choice for businesses in particular is covered in Why Laravel for Business?.

Two architecture questions decide cost and durability early:

Multi-tenancy. If the portal serves several client companies, each with their own users and strictly separated data, that is a multi-tenant architecture – and it wants to be designed in from the start, not retrofitted. The options and when each fits are covered in our fundamentals article on Laravel multi-tenancy.

Integrations first. As above: only once it is clear which data flows reliably is it worth building the interface on top.

One part that regularly goes missing from portal quotes is the inside. Every portal needs an administration area for your team: activate users, look up cases, upload documents, correct data when the integration delivered nonsense. That inside is effort you have to account for, and it gets forgotten easily because nobody is shown it in a sales conversation. Where it fits, we build it with Filament – an admin toolkit for Laravel that generates lists, forms, and permissions from the data model instead of hand-building them. That saves money in a place where bespoke design buys nothing: your team needs a fast, reliable administration surface, not a design piece.

What a multi-tenant system looks like in reality is shown by our own product Rentlytics: a Laravel platform serving rent-index calculators for several municipalities and housing companies from one codebase, either hosted or as an embeddable web component. We deliberately decided against an off-the-shelf tenancy package there – the reasoning, and when that decision goes the other way, is in when a tenancy package is the wrong abstraction.

Security and data protection

A portal moves business data out of internal systems and onto the public internet. That is the point of it, and it is why security here isn’t an add-on item. The things we consider non-negotiable:

• Access rules central and tested. See the roles model above. The most common serious hole in portals isn’t a break-in from outside, it is a customer who changes a number in the address bar and sees another customer’s data.
• Two-factor sign-in, at minimum for accounts with elevated permissions.
• Encrypted transport throughout, including between the portal and connected systems – not just to the browser.
• Audit logging. Who downloaded which document, and when? You need that less often for technical reasons than for questions from the business, and you only have it if it runs from day one.
• Tested backups. A backup that has never been restored is an assumption. Doubly so when customer data is in it.
• Updates as a process, not as an event. A portal built in 2026 that still holds customer data in 2029 needs regular updates to framework, language, and dependencies across those three years.

On data protection, the usual and genuinely meant boundary: we are developers, not lawyers. What we deliver are the technical preconditions – data minimisation in the data model, deletion concepts that actually delete, a processing agreement where we have access, traceable access. The binding assessment of your case belongs with your data protection officer.

One question arises earlier with portals than with websites: where the data sits. A portal holding customer data in a US cloud is a decision with consequences, and it should be made deliberately rather than as a by-product of picking a host. We handle it on principle: hosting with the client, not with us – and not outside the EU without asking. The reasoning and the options are in EU hosting and digital sovereignty.

Accessibility: when the EAA applies to your portal

This point is missing entirely from most portal quotes, and since 2025 that is a risk. The European Accessibility Act has applied across the EU since 28 June 2025 – in Germany implemented as the Barrierefreiheitsstärkungsgesetz – to e-commerce services for consumers. For portals that means, concretely:

• A portal where private customers order, conclude contracts, or book appointments is generally in scope.
• A pure B2B portal for business customers is not covered in principle – the act protects consumers.
• For micro-enterprises there is an exemption for services: fewer than 10 employees and under 2 million euros annual turnover.

The technical benchmark is WCAG 2.1 AA. Here too: we are not lawyers, and the assessment of your specific case belongs with one. The details, the deadlines, and the technical substance are in Accessible websites: what the EAA requires.

Two practical notes from the portal perspective. First: get the classification checked before you build, not after. Retrofitting accessibility into a finished application – keyboard operation, focus order, contrast, form errors a screen reader also picks up – is considerably more expensive than building it in from the start. Second: even if your portal is purely commercial and therefore out of scope, most of the measures still pay off. Your business customers are people, some of whom work by keyboard, see poorly, or use a screen reader. A portal that locks them out generates exactly the phone calls it was meant to abolish.

What a customer portal costs

Honest numbers instead of “it depends”: with us, custom web applications start at 10,000 €. Typical portal projects range from 15,000 to 60,000 € – where exactly is driven mostly by three factors:

• Integrations. Every connected system brings its own analysis, development, and testing effort. A solid ERP integration can cost as much as the rest of the portal.
• Roles and permissions model. “Every customer sees their orders” is simple. “Client companies with admin users who assign permissions to colleagues” is a multiple of that.
• Multi-tenancy. Portals for several client companies with hard data separation start at 25,000 € with us – the separation runs through the data model, the tests, and operations.

What that range means in practice can be pinned to scope. At the lower end sits a portal with login, one core function, and one integration – status information from one system, permissions at user level, a lean administration area for your team. In the middle, several case types are added, documents with permissions, two or three connected systems, and a roles model with client companies and admin users. At the upper end sit multi-tenancy, single sign-on, bespoke pricing or discount logic, and an administration surface that is a small product in itself.

What is not a cost driver, although it often feels like one: the number of pages and the number of users. A portal for 50 customers costs the same as one for 5,000, as long as the permission model stays the same – load is a hosting question, not a development question. The cost driver is the number of rules: how many roles, how many exceptions, how many systems, how many special cases in your workflows.

On top comes ongoing operation, covered in the next section. A portal that carries customer data is not a “build once, never touch again” project – budgeting that from the start is more honest than leaving it out of the quote.

We name the exact price after a concept workshop. Before that, any number would be a guess – and guessed numbers are the leading cause of failed portal projects. Any effort figure you get from us before the workshop is an estimate and not a fixed price; we say so plainly, because the difference costs money later.

What operation costs – and what it covers

The most common mistake in portal budgets isn’t a development figure that’s too low. It is an operating figure of zero. After launch, a portal consists of three ongoing items:

Hosting. Depends on the provider and the load, and runs directly through you. We don’t host client applications ourselves as a matter of principle – that keeps the data and the contract with you, and it means you aren’t tied to us if you ever want to continue elsewhere. A portal needs a bit more than website hosting: a database, background processes for syncs and email, storage for documents, backups.

Maintenance. Updates to framework, PHP, and dependencies, monitoring, backup verification, small corrections. This is the item that keeps a portal viable three years in, and the first one to get cut. Our WordPress maintenance packages deliberately don’t fit here: a CMS with plugins needs different care than a custom application. For portals we therefore agree either effort as needed at our hourly rate of 120 €, or a fixed monthly budget scaled to the size of the portal.

Further development. The item you should want. A portal that gets used generates change requests – that is a success signal, not a planning defect. A small, fixed budget for it is the difference between a portal that grows with the company and one that gets bypassed after two years because it didn’t keep up with one step.

What we commit to and what we don’t, we keep deliberately tight: our service hours are Monday to Friday, 8 to 18. We don’t promise 24/7 operation and no fixed response time without a corresponding contract. Outside service hours we can usually be reached – we just don’t promise it, because a commitment we can’t always keep is worth nothing.

How development works

1. Concept workshop. Which bottleneck should go, who uses the portal, which systems need connecting? Result: a scoped feature set and a reliable price.
2. Integration analysis. The connected systems get a technical check early – this is where “reliably feasible” gets decided.
3. First usable version. Login, core function, one integration – deliberately narrow and live in two to four months, instead of waiting a year for the grand launch.
4. Iterative expansion. Further features in short cycles, prioritised by what users actually use – not by the original wish list.
5. Operations and evolution. Monitoring, updates, backups, and a named contact person – so the portal still carries you in three years.

It pays to come to the workshop prepared – not with a specification document, but with material from everyday work. What helps us most: a list of the enquiries your team answered in a normal week, including your customers’ own wording. The names of the systems involved, and who looks after them. One example case from start to finish, talked through once. And the answer to the question of who in the company decides when two wishes collide during the project – that role matters more than any document.

One point about launch that rarely appears in the process: customers have to be brought into the portal. A working portal nobody knows about changes nothing about the number of calls. What works is a small group first – a handful of customers who are in regular contact anyway, with a personal invitation and an explicit request for feedback. Their questions in the first two weeks are the best input for further development you can get. Then the breadth, with a pointer in the email signature, on the invoice, in the order confirmation – in the places where the status question arises today.

When a portal already exists: migration

Some portal projects that come to us are not new builds. Something is already there: an ageing customer account, an island solution from an earlier project, a portal whose vendor discontinued support. That changes the process in three places.

The inventory comes before the concept. What is actually used? That question can’t be settled in conversation, only against the usage data of the existing portal. Our experience from relaunch projects is fairly consistent: a substantial share of the features listed as “obviously included again” is used by almost nobody. Not carrying those over is the cheapest way to shrink a migration project.

Data migration is its own line item. Accounts, case histories, uploaded documents – deciding what has to come along is a business question, not a technical one. Bringing historical cases is often more expensive than it sounds, because the old data model rarely matches the new one. A workable shortcut: the old portal stays reachable read-only for a while, and the new one starts with the active cases.

Access is the delicate part. Existing users have passwords that can’t be carried over and shouldn’t be. For every customer, the switch means signing up again – and that is the moment portals lose users. It needs preparing: an announcement, a reset path that works without anyone having to ask, and someone reachable for the first few weeks. For portals serving existing customers, we now plan that switch as seriously as an integration.

How to recognise a suitable agency

Since this is the question that follows the cost question, here are the criteria we would apply ourselves – even where some of them don’t flatter us:

• They ask about the bottleneck, not the feature list. Anyone ticking off features in the first conversation is selling scope. Anyone asking which calls should stop is building a portal that changes something.
• Integrations are checked before the quote. A fixed price for an ERP integration nobody has looked at is either padded with a large risk margin or it won’t hold.
• The off-the-shelf option is genuinely considered. An agency that arrives at a custom build in every portal conversation wasn’t listening.
• Test coverage is part of the quote, not an option. For a system with customer data and permission logic, automated tests aren’t a luxury.
• You get the code and the hosting sits with you. Both are your insurance that you can carry on if the working relationship ends.
• Commitments are concretely bounded. Service hours, response times, what’s in the price and what isn’t. “We’re always there for you” is a platitude, not a commitment.
• There is comparable work to look at. Not necessarily a portal in your industry, but an application with login, permissions, and a real system integration.

And two points where you should turn us down: if you need an off-the-shelf solution at an off-the-shelf price, we are the wrong address – a builder will be cheaper and faster. And if you want a provider who takes over hosting, operations, and data custody entirely so you don’t have to deal with it, our model doesn’t fit, because we deliberately don’t host client applications.

The most common portal project mistakes

1. Wanting everything at once. Full scope as the first version doesn’t double the duration – it often prevents launch entirely. Biggest bottleneck first, the rest iteratively.
2. Underestimating integrations. “But the ERP has an API” is the most expensive sentence in the portal business. Check connections early; don’t bolt them on at the end.
3. Forgetting operations. A portal holding customer data needs care, security, and someone responsible – budget only the build, and you pay for the rest later at a premium.
4. Settling the roles model too late. Whether permissions hang off users or off client companies determines the data model. Turning that question around after the start is one of the most expensive changes a portal project knows.
5. Treating launch as the end. Customers don’t find their way into the portal by themselves. Without an invitation, without a pointer where the status question arises today, and without a contact person in the first weeks, the portal stays empty – and the phone keeps ringing.

An honest conclusion

A customer portal pays off when it replaces a real bottleneck – the daily status request, the document ping-pong, the double data entry between systems. It doesn’t pay off as a prestige project without a clear use case. The order for a good decision: first the bottleneck, then the off-the-shelf-or-custom question, then the scope of the first version – and only after that, the technology.

If you take one thing from this article, take the order of the checks. Count the bottleneck before you look for a budget. Look at the system you already own before you build something new. Have the integration inspected before you sign a quote. And settle the roles model before the first line of code. The portal projects we have watched fail did not fail on the technology – they failed because one of those four checks got skipped.

---

Considering a customer portal? Tell us which bottleneck should go and which systems are attached – we’ll tell you honestly whether custom development pays off for your case and what it costs: drop us a line. More about how we work: custom software and our Laravel agency page.