Customer Portal: What the First Version Should Include

The smallest useful customer portal does four things: gives each client their own login, shows where their job stands, lets documents move safely in both directions, and offers exactly one action clients can take themselves, such as approving a quote or sending a request. Chat, ticketing, dashboards and accounting integrations can wait.

Before you commission anything, check what you already pay for. Many practice-management, project and file-sharing tools include a client area, and for a standard process that is usually enough. A custom portal earns its cost when the way you work with clients is what sets you apart, or when you would otherwise stitch several tools and logins together.

What clients actually use a portal for

A customer portal is a password-protected area where clients sign in to see or update their own information. It pays off where your inbox fills with small follow-ups: "Where are we?", "Did you get my documents?", "Can you resend the quote?"

Before listing features, write down the five questions clients asked most often over the past month. Each feature in version one should answer at least one of them. If clients write in both German and English, note that too: a second interface language is a scope item, not a detail.

Version one: a scope table

This is a typical first scope for a small service business. Adjust it to your process. If the list grows too long, Web App MVP: Which Features Belong in Version One? explains how to prioritise.

Login and roles come first

For a portal, the key question is not design but who can see what. "Broken Access Control" is number one in the OWASP Top 10 2025, the best-known list of common web application security risks, and "Authentication Failures" has its own entry too.

In practice, as the client commissioning the work:

• Every request the portal handles must check that the signed-in person may see that job or document. Put this in the quote and in the acceptance test.
• Ask how the developer tests that client A cannot open client B's files, including by editing the address in the browser.
• Staff accounts see everything, so protect them more strongly than client accounts, for example with a second factor.
• Make sure you can revoke access quickly when a client relationship ends or an employee leaves.

GDPR basics for a portal

A portal almost always processes personal data: names, contact details, and often contracts, photos or financial documents. Four points belong in the plan from the start.

• Collect only what you need (Art. 5(1)(c) GDPR): a required "date of birth" field with no purpose is a liability, not a service.
• Inform people when you collect data (Art. 13 GDPR): at the time of collection, users must learn who the controller is, why the data is processed, on what legal basis and who receives it. Link your privacy policy (Datenschutzerklärung) from the login page and update it for the portal.
• Contracts with processors (Art. 28 GDPR): hosting, file storage and email delivery providers process data on your behalf, and each needs a data processing agreement (DPA, in German "AVV").
• Security (Art. 5(1)(f) GDPR): encrypted connections, protected file storage and regular updates. That is ongoing work, not a launch-day checkbox.

Buy or build?

For many small service businesses, an existing tool is the better first step. Ask your current software vendor whether a client area is available, and trial it with two real clients.

An off-the-shelf tool is usually enough when:

• your process matches the standard in your industry,
• clients mainly need to exchange files and see a status,
• you can live with the vendor's design and terminology,
• per-user or per-client pricing stays affordable at your size.

A custom portal is more likely to pay off when:

• your client process has steps tools only handle with workarounds,
• clients need to enter data in a structure no tool offers,
• you would otherwise combine two or three tools and clients would need several logins,
• the portal is part of what you sell and should look and feel like your brand.

If the main thing clients do is book appointments, that is a different decision, covered in Booking Software or a Custom Booking App? How to Decide.

When a portal stops being a small project

A portal quickly grows beyond a small web app when it must sync in real time with several existing systems, when it is run for many companies with their own configuration and billing (multi-tenant), or when it is meant to replace an ERP system.

To put our own offer in context: a portal along the lines of the "Version one" column can be a small, clearly defined web app of the kind Ichii builds from €1,999 net (plus VAT), one-time. That entry price does not automatically apply to every portal, though; whether yours fits, and what it costs, is settled in a fixed quote based on the agreed features. Hosting, storage, email delivery and technical maintenance (from €29 a month) are charged separately, and the large scenarios above are outside this range. The cost drivers are explained in How Much Does a Custom Web App Cost in Germany?.

Your next step

Write down your clients' five most common questions and mark the rows in the table above you need for version one. Then trial the client area of the software you already use. If it doesn't fit, summarise roles, data and the one client flow with the web app brief template and send us an enquiry about a web app.