Why we're rebuilding the Hudu portal experience
For years, Hudu's client/portal experience has lived as a separate, parallel product: its own login, its own limited feature set, its own maintenance burden. It worked, but it was never going to get better fast enough. Every improvement to the portal meant building it twice — once for core, once for the portal.
We're changing that. Portal users are moving into core Hudu.
The problem with a separate portal
A second product means a second roadmap. Every feature we ship for admins and technicians has to be re-imagined, re-scoped, and re-built for a completely different interface before portal users can benefit from it — if they ever do. That's how you end up with a portal that feels stuck in time next to the product it's supposed to mirror.
It also means more for admins to manage. A separate set of permissions, a separate mental model, a separate place where things can go wrong. Two systems to keep in sync instead of one.
What we're doing instead
Portal users are becoming a role inside core — not a bolt-on, not a stripped-down mirror, an actual part of the same platform everyone else already works in. One platform, one permissions system, one roadmap.
That's not a smaller change dressed up as a big one. It's the single biggest product change we've made — and it's the foundation for everything we want the portal experience to become.
What this actually gets you
Access to more than one company. This has been one of our most requested portal changes for a long time. Portal users tied to a single company has never matched how a lot of MSPs and internal IT teams actually work. In core, that limitation goes away.
Real group-based permissions. Portal users can now live in groups, the same way any other user does — instead of a single fixed set of portal rules that applied to everyone the same way. That means more control over exactly what each client or department can see.
A platform that actually improves over time. Because portal users now live in the same system as everyone else, every future improvement to core — search, permissions, integrations, whatever comes next — reaches them too. No more waiting for a separate portal-specific version that may or may not show up.
Room to grow. Bringing portal users into core also opens the door to things that weren't possible in a standalone portal — like a future paid tier with expanded capabilities. None of that was realistic in the old architecture. It is now.
Still free. A lot more capable.
The role itself isn't changing in cost — portal users remain free. What's changing is everything they get for that price.
The old portal was built to do one thing: let a client view a limited slice of their documentation. Portal users in core get the mobile app, the browser extension, the password vault, secure notes, and Hudini — tools we'd normally reserve for paid roles. We're extending real, meaningful product value to a free tier, not just a coat of paint on the same limited experience.
That's a deliberate call. We'd rather give portal users a genuinely useful experience than a bare-minimum one, because the value of Hudu — to you and to your clients — goes up the more complete that experience is. It's an investment in making the whole platform better, not just the parts people pay for.
What this means for your clients
This isn't only a backend or admin-facing change. It changes what your clients can do, too.
Clients with real access to their own documentation — not a stripped-down view, but the mobile app, the vault, secure notes — actually use it. And when clients use their documentation instead of just receiving it, a few things happen:
Your data gets more accurate. Clients are the first to notice when a device, a login, or a process is out of date, because they're the ones relying on it day to day. Give them a real way to see it, and they become another set of eyes keeping it current instead of a passive recipient of whatever you last updated.
Accountability goes both ways. When clients can see what's documented about their own environment, it's harder for anything — on either side — to live only in someone's head. That's good for trust, and it's good for you when a client asks "did we ever write that down."
Fewer status-check tickets. A client who can look something up themselves doesn't have to email or call to ask for it. That's less inbound noise for you, and a faster answer for them.
A better experience during transitions. If a client's primary contact changes — new hire, new IT lead, whoever — a client with real portal access has somewhere to go on day one instead of starting from zero or waiting on you.
None of this works if the portal experience is an afterthought. That's the whole point of this change.
The bigger point
This is what happens when you treat documentation — and everyone who touches it, including your clients — as one connected product instead of a patchwork of separate tools bolted together. Maintaining a single platform means we can put our full effort into making it stronger, for every user, every time. Long term, that's less work for admins and a better experience for everyone with access to it.
This is the why behind it. For the what — including what's changing, when, and how to prepare your instance — see Upcoming portal changes: what to expect and how to prepare.
