The test that separates them is a single question: who is looking at the screen?
A client portal faces outward. Your client logs in and sees their own things: their documents, their status, their history, their invoices. It gets used by people outside your company, a little and infrequently, so it has to be obvious from the first visit.
A CRM faces inward. Your team logs in and sees every client at once, what stage each conversation is at, who needs to call whom next. It gets used by your own people, daily, so it can be denser and fuller of information.
They are systems with different users, different rhythms and opposite design requirements. They get requested almost identically in briefs, with the sentence "we need somewhere to see our clients," and that is where the wrong projects begin.
01.Why they get confused so often
Because both contain the word "client" and both appear to solve the same frustration: we do not know where the information lives.
But that frustration has two completely different sources. Either your clients phone to ask things they could see for themselves, which calls for a portal. Or your team does not know who discussed what with whom, which calls for a CRM. The first is an access problem, the second is a record-keeping problem.
If your answer is "both," that is an honest and common answer. The order still matters, and our recommendation is almost always the same: first the one taking more hours out of your week, then the other one, a few months later.
02.Signs you need a portal
- The same questions, by phone or email, every week. "Where is my order?", "can you resend the invoice?", "what stage is the project at?". Each one is a question that already has an answer somewhere in your company.
- You send the same documents by hand. Contracts, reports, invoices, proofs. If someone on the team is searching for and resending attachments, a portal pays for itself fairly quickly.
- Your clients have several people involved. When you work with companies rather than individuals, the question of who received what gets expensive. One shared place solves it.
- You sell something that stretches over time. Subscriptions, projects running for months, recurring services. The longer the relationship, the more there is to show.
03.Signs you need a CRM
- Conversations live in people's heads. When somebody goes on holiday, nobody knows where things stood with their clients.
- Sent quotes get lost. Not because they were bad, but because nobody followed up in time and nobody knew they were supposed to.
- You cannot answer simple questions about your own company. How many quotes are open right now, what they are worth, how many closed last month.
- The team has grown past two or three people. Below that threshold a spreadsheet genuinely works. Above it, it starts to cost.
04.Buy or build: the honest part
This needs saying plainly, even though we build software.
For a CRM, buy first. This category is mature. There are good products with subscriptions of tens of euros a month that do everything a small or mid-sized company needs, plus things you have not thought of yet. A CRM built from scratch costs tens of times more and has to be maintained indefinitely. The real reasons to build one are few: a genuinely unusual sales process, a regulatory requirement the products do not cover, or a headcount at which per-user subscriptions cost more than development. If none of those apply, buy it and configure it.
For a portal, building is more often justified. A portal is tightly bound to what you specifically sell, to your documents, your stages, and the systems it pulls data from. Generic portal products hit the "almost, but not quite" ceiling quickly, and that "not quite" is visible to your client, unlike a CRM only your team ever sees. It is also why a badly built portal costs more than no portal at all: it becomes part of your brand experience.
Many companies end up at the correct answer, which is a mix: a bought CRM for the team, a built portal for the clients, and an integration between them so nothing gets entered twice. We wrote about the integration side in do you need an app or a better process.
05.What a minimum viable portal contains
If you do build, the first version has to be narrow and whole. What cannot be missing:
- Accounts and authentication, with roles. A client sees only what belongs to them. It sounds obvious and it is where the most serious mistakes happen.
- One single type of content, complete. The documents, or the status, or the invoices. One, taken all the way, rather than three started.
- Download and history. The client has to be able to take the document with them and see what came before.
- A notification when something new appears. Without it nobody logs in, and you will draw the wrong conclusion that the portal was not needed.
- A screen for your own team. Somebody has to put things in there. If uploading is clumsy, the team goes back to email within two weeks.
What can wait: messaging, payments inside the portal, signatures, reports, a phone app. The selection logic is the one from what an MVP is: one flow, taken all the way through.
06.Client data: the part that is not optional
A portal holds personal data belonging to people who do not work for you, which puts you directly in GDPR territory. It is not complicated, but it has to be handled from the start, because adding it later costs several times more.
What needs settling before building: what data gets stored and why, how long it is kept, who on your team can see it, what happens when a client asks for their account to be deleted, where the servers sit, and who is responsible if something leaks. All of these are business decisions rather than technical ones, so your supplier cannot make them for you.
One practical thing that gets forgotten almost every time: what happens to a client's data after the relationship ends. If the answer is "it stays there forever," you have a problem growing quietly.
07.How to launch it so it actually gets used
Abandoned portals almost always share the same cause, and it is not a lack of interest from clients. It is the launch.
- Do not announce it by email and leave it there. A general announcement gets read once and forgotten. Bring it into the conversations you are having anyway: at contract signing, at the first delivery, at the first invoice.
- Put new clients straight onto the new route. Existing ones are hard to move because they already have a habit that works. New ones have none, so for them the portal is simply how you work.
- Put something in it that cannot be obtained any other way. If everything in the portal also arrives by email, nobody has a reason to log in. One document that appears there first is enough.
- Close the old road, gently and with a date. As long as a phone question gets the same quick answer, the phone stays the more comfortable option and the portal stays empty.
08.What it costs and how long it takes
The orders of magnitude, for orientation:
- A bought and configured CRM: tens of euros per user per month, plus a few hundred up to a thousand euros, once, for configuration and training done properly.
- A client portal, first version: roughly 4,000 to 10,000 euros, depending on how many systems it has to query. A portal showing manually uploaded documents sits at the bottom of that range. One pulling data automatically from invoicing and from your project system sits at the top.
- A CRM built from scratch: from 5,000 to 12,000 euros for a first usable version, which is exactly why the recommendation stays "buy" unless you have a specific reason.
- Timeline: a minimum viable portal usually takes a few weeks. The stage-by-stage detail is in how long an app takes, and the full price bands in how much an app costs.
09.The GoodGlyph take
If you take one thing from this: answer the question of who is looking at the screen first. If the answer is "my team," start from a bought product and build only if you hit a real limit. If the answer is "my clients," then the conversation about building is justified, because there generic reads as visibly generic. We build custom apps for exactly the second case, and we will tell you honestly when you are in the first. Write to us with the questions your clients ask most often and we will tell you whether a portal answers them.
10.Closing
A portal and a CRM solve two different silences: one where your client does not know where things stand, another where your team does not know where they left off. Both cost real money. Just not the same money, and not in the same order.
Frequently asked questions
A portal is for your clients and shows each of them their own things. A CRM is for your team and shows every client at once, with the stage of each conversation.



