Commissioning a Customer Portal: Features, Cost, and Process

In short: A custom customer portal starts at 10,000 € with us; typical projects run between 15,000 and 60,000 € – the drivers are integrations, the permission model and test coverage, not page count. Multi-tenant portals serving several client companies start at 25,000 €. A serious number only exists after a concept workshop.

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.

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.

Off-the-shelf or custom – the honest preliminary question

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.

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. 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 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.

On top comes ongoing operation: updates, monitoring, backups, and further development. 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.

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.

What this looks like in reality is shown by our Rentlytics project: a Laravel platform serving several municipal rent-index calculators as separate sites from one codebase – including the architecture decision of when a tenancy package is the wrong abstraction.

The three 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.

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.

---

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.