How to Build a Client Portal Without Asking for a Password
A client portal is a private page where each person sees only what's theirs — their order, their appointment, their files. No password needed; just their own link or a verified email.
Adriana is a nutritionist in Pachuca who sees about forty patients a month. Her real job isn’t the consultation — it’s what happens between one consultation and the next. She sells a four-week program that comes with materials: a portion guide, a grocery list, a recipe book, and she sends it all over WhatsApp. She keeps track of the next appointment date. She has a notebook where she writes down who’s paid in full and who’s halfway there. And every week she answers the same message three or four times: “hey, can you resend the guide? I lost it in the chat”.
A client portal solves all of that. And the hard part isn’t the one you’d expect.
What is a client portal?
A client portal is a private page within your site where each client sees only what’s theirs: their order status, their next appointment, and the files that belong to them. It’s not just another section of your website. Your website is public and speaks to anyone who lands on it; the portal speaks to one person and shows them their own things.
For Adriana that means three things: when her next consultation is, the program materials she can download as many times as she wants, and how much she’s paid so far.
Do your clients really need a password?
Almost never — and this is where most of these projects die.
We’ve already talked about how a small business rarely needs an app with sign-up and passwords. That’s still true. The thing is, “portal” sounds like login, and the moment you ask people to create an account you’ve lost half of them: they forget the password, they text you on WhatsApp to remind them, and you end up doing by hand the exact work the portal was supposed to take off your plate. Adriana’s patient isn’t going to remember a password she uses once a month.
A portal that actually works starts with a simpler question: how do I confirm this person is who they say they are, without making them invent a password?
How does your portal know it’s really your client?
There are two ways, and neither one is a password.
The first is their own link. When someone buys from you or books an appointment, a long, impossible-to-guess link gets saved on their phone. That link is the proof. Whoever has it sees their order; whoever doesn’t can’t get there no matter how many addresses they guess. It’s the same principle as the plane ticket that lands in your inbox: they didn’t ask for a username or password, they sent you something only you have.
The second is their verified email. If your client did sign up at some point, they log in with their email and see everything tied to that address.
The difference matters: the link lives on a phone, the email lives with the person. That’s why the link works for the one-time client — the one who bought at the counter and will never sign up — and the email works for the one who comes back every month.
What should your portal say when someone isn’t the owner of an order?
Exactly what it would say if that order didn’t exist. Not “this order isn’t yours,” not “that account exists but you can’t see it”: just, we couldn’t find anything. This is the rule that separates a serious portal from one that’s going to get you in trouble, and it’s the one almost nobody thinks about.
It sounds like a technical detail, and it isn’t. A portal that answers differently for “doesn’t exist” versus “exists but isn’t yours” turns into a way to search for other people’s clients: anyone can start guessing emails and find out who’s a patient of Adriana’s. That’s not a coding mistake — it’s a problem for the people who trusted her. The same goes for a store, a repair shop, or a salon — the list of who buys from you is your clients’ information, not yours.
The whole rule, in one line: the portal never confirms something exists unless you’re the one asking.
What does your client see inside?
Three blocks — and it’s worth keeping it at three, not ten.
Their order. Where it stands, what they paid, and what they still owe. If there’s a balance left, they can settle it right there instead of you having to chase them. If something went wrong, they can request a refund right there without messaging you.
Their appointment. When the next one is. We’ve already covered how to set up the appointment system behind the scenes; on the portal, all that matters is that they can see it without asking you.
Their files. The materials that come with what they bought: Adriana’s guide, the recipe book, the manual for the equipment you sold, the course lessons. It unlocks because they paid, and it stays unlocked. This is what saves you the most manual work, because it’s exactly what people lose and ask you for again.
One clarification, because this is where people get ahead of themselves: this works when the file is the same for everyone who bought the same thing. If you need a different document for each client — a personalized plan per patient — that’s a different, bigger thing. It’s worth doing, but ask for it separately, not as if it comes included.
What it shouldn’t have: messaging. You already have WhatsApp, and so do your clients. A chat inside the portal is just one more inbox to check, and nobody checks it.
What if they bought as a guest and later create an account?
Their past purchases should show up on their own the moment they log in with that same email. No need for them to message you asking you to “transfer” their history.
This happens all the time — someone buys quickly without signing up, and months later creates an account — and it’s the doubt that sinks these projects. If the portal you build doesn’t connect the two, your client ends up living two separate lives in your business, and you end up being the glue between them.
Where to start
Before you ask anyone to build you anything, do this: write down the names of your last five clients, and next to each one, the question they’d ask you today if they messaged you. If three of those five questions already have an answer in something you already know — the date, the file, the balance — those three are your portal. The rest comes later.
With that, you can already describe it in Proyecta just like this: “a portal for my patients where each one can see their next appointment, the materials from the program they bought, and how much they’ve paid, without having to create a password.” Describe it and publish it at proyecta.dev.