Website, Web App, or Customer Portal? What You Actually Need — and What It Costs

Put "website with customer login" in an RFP and you'll get quotes that differ by a factor of ten — and not one of them is miscalculated. The reason: website, web app, and customer portal are three different product classes, each with its own budget logic, its own operating overhead, and its own definition of success. If your requirements document mixes up the terms, you end up comparing quotes that don't describe the same product — and deciding on price instead of substance.

This guide draws the lines the way we draw them in real projects: not by technology — technically, a customer portal is a web app, and both run in a browser just like a website — but by the three criteria that actually determine budget and team: Who uses the system, what is it supposed to replace, and where does the data come from?

The three classes differ less in the initial quote than in what comes after. A website is an editorial matter after launch: maintain content, build search visibility, evolve it occasionally. A web app is software with a roadmap: it lives on continuous development and needs operations, monitoring, and someone who owns it. A customer portal additionally has an integration layer to your ERP or CRM that has to be maintained whenever the underlying systems change — and external users who hold it to the same availability and security expectations as any professional software.

Then there's the most common mislabeling we see in RFPs: "portal" as a catch-all for anything with a login. An intranet is not a customer portal. An internal order-management tool is not a customer portal. This isn't pedantry: internal tools are justified through process costs, customer portals through support relief and revenue — two different business cases with different stakeholders, budget owners, and success criteria.

A website is public. Anyone can see it, nobody logs in. Its goal is visibility: get found, build trust, generate inquiries. Content comes from a CMS, maintained by marketing, and success is measured in rankings, inquiries, and conversion. That sounds trivial, but it has an important consequence: a website is a marketing asset, not a process tool. Forms, a calculator, or a gated download area don't make it a web app — what matters is whether someone actually works in it. If your bottleneck is visibility and lead generation, you don't need software development; you need a good website. That's the cheapest of the three answers, and it's not a consolation prize.

A web app has a closed group of users who work in it — usually your own employees, sometimes partners. Login, roles, and permissions are mandatory, the data lives in its own database, and the goal is a process: replace Excel spreadsheets, retire an isolated tool, digitize a workflow that no off-the-shelf software covers. Success isn't measured in visitors but in process time, error rates, and tools retired. An honest intermediate step belongs here: before you commission a web app, check whether standard software covers the process. Custom development only pays off when the process is your differentiator or when standard solutions fail on your data flows.

A customer portal is technically a web app — but the users aren't your employees; they're your external existing customers. They log in to handle things themselves that today require email and phone calls: checking order status, retrieving invoices, filing tickets, reordering. This drives a different ROI logic: value doesn't come from faster internal processes but from a relieved support team and self-service as a sales channel. In B2B that means, concretely: company accounts where multiple people work with different permissions, single sign-on, and cleanly separated tenants. And there's a hard technical consequence: without a connection to your ERP or CRM, the portal stays empty — order and invoice data live in your existing systems, not in the portal.

For day-to-day classification, six rows are enough. The cost ranges are our published price anchors — not market averages and not "starting at" teaser pricing.

As of July 2026. All prices net of VAT. Cost ranges are published happycoding price anchors, not market averages.

In first conversations, we settle the product class with three questions — usually in under ten minutes.

First: Who logs in? Nobody — then it's a website, no matter how large it gets. Your own employees — then it's a web app. Your customers — then you're talking about a portal, and from that point on, portal rules apply: company accounts with multiple users, role and approval models, and in B2B almost always SSO.

Second: What is the system supposed to replace? A brochure, your trade-show presence, an outdated self-presentation — website. Excel spreadsheets, email ping-pong between departments, an isolated tool — web app. The phone and email requests your customers send to sales and service — customer portal. This question exposes most mislabels: a "portal" that merely digitizes internal case handling is a web app and should be priced and justified as one.

Third: Where does the data come from? From a CMS, maintained by marketing — website. From its own database, created along with the system — web app. From your ERP or CRM — customer portal. In the third case, the integration question matters more than the frontend: we've covered how portals connect to existing systems via SSO and APIs in our guide to SSO and ERP integration for customer portals.

The website question is usually a quality question — the portal question has become an expectation question. As far back as a Microsoft survey published via Statista in 2019, 88 percent of customers said they expect brands to offer an online self-service portal. In B2B, the trend has only sharpened since: according to the Gartner Sales Survey (fielded August/September 2025, published March 2026), 67 percent of B2B buyers prefer a rep-free buying experience — a Gartner survey published in June 2025 still put that figure at 61 percent. The Sana Commerce B2B Buyer Report 2025 — with German buyers in the sample — gets more specific: 73 percent of B2B buyers prefer purchasing online, 75 percent would consider switching suppliers over a poor digital experience, and 40 percent name missing transparency on stock levels and delivery dates as their biggest frustration — exactly the information a portal answers straight out of the ERP. And Gartner expects (August 2025) that self-service and live chat will overtake phone and email as the most-used customer service technologies by 2027.

To be honest, though: expectation is not yet a business case. Whether a portal pays off for your customer structure — and when there simply is no case — is something we've run the numbers on in our article on the business case for a customer portal. If you serve a handful of customers with rare, highly individual transactions, a portal is the wrong investment, no matter what the surveys say.

Path 1: Website. If nobody logs in and the goal is visibility and inquiries, a professional company website is the right — and least expensive — answer. Costs depend heavily on scope, CMS, and content work; we've broken down the published ranges and cost drivers in our 2026 guide to corporate website costs. The most important advice: don't buy a login feature "just in case" — it makes the project more expensive and gets rebuilt later as a separate application anyway.

Path 2: Web app. If your own employees work in the system, you're in custom software territory — our web app development practice. The published anchors: €8,000 to €20,000 for an MVP, €20,000 to €60,000 for a full web app with authentication and roles. The ROI is calculated internally — process hours, cost of errors, retired licenses — and that's the calculation your requirements document should hang on, not a feature list.

Path 3: Customer portal. If your external customers log in and the core is self-service with ERP integration, you're looking at customer portal development — with published anchors: €8,000 to €20,000 for a portal MVP with login and first self-service features, €20,000 to €60,000 with roles, company accounts, and a first ERP integration, €60,000 to €150,000 for portal platforms with multiple tenants or brands. Our recommendation is almost always the MVP entry point: go live with one or two self-service features and validate the business case against real user behavior before committing to the big build-out.

The special case: a system already exists. If there's already a legacy portal, an organically grown intranet, or a legacy system in place, the question isn't "website, web app, or portal?" but "replace, extend, or put a modern layer in front?" — that's a case for software modernization. The most common sub-case in our practice: the legacy ERP stays untouched, and a new portal is built as a modern layer in front of it.

If you're writing a requirements document right now, or comparing quotes that don't seem comparable: answer the three questions from the practical test in writing — user base, replaced process, data source — and assign your project to one of the three classes before you talk about prices. If you want a second opinion: in a free 30-minute call, we'll tell you which product class your project belongs to and what price range is realistic — even when the answer is: a good website is enough, save yourself the software development.