The headless intranet

At some point, someone in every company says: “We need a new intranet.”
Usually the existing one is dead. The search is useless, the content dates back to 2019, and the interface looks like 2014. So a project gets funded, a new portal is chosen, and six to twelve months later it goes live.
Then the same thing happens again. After a few months, nobody uses the new one either.
The problem isn’t the portal itself. You’re layering a new system on top of old workflow problems and hoping the new coat of paint fixes things.
Why portals fail
Most teams work across several SaaS tools: Notion for docs, Jira or Linear for project tracking, Figma for design, Google Drive or SharePoint for files, and Slack or Teams for communication. Then there are specialized tools such as a CRM, analytics dashboard, HR system, or wiki.
Each tool has its own interface, its own search, its own logic. Content lives spread across all of them. That’s fine — you want to edit designs in Figma, not in an intranet portal.
A classic intranet tries to pull all that content into one central place. Either by copying it (instantly outdated) or by embedding it with iFrames (bad user experience). Both approaches create another tool that needs maintaining. And intranets die from lack of maintenance more than anything else.
Nobody wants to open another portal. People just want to know where things are.
What “headless” means here
In software, “headless” means separating content from presentation. A headless CMS stores content but doesn’t display it — other systems handle that part.
For an intranet, you don’t need a portal that displays content. You need a system that knows where content lives and routes people there.
No extra interface, no extra portal. Just a directory that points people to their existing tools.
Compare: an employee opens the intranet, searches for “vacation request,” and tries to find the HR tool. With Lora, they type short, press Space, enter vacation, and open the HR tool directly.
What this looks like in practice
The team creates shortcuts for the most important resources. /roadmap goes to the Notion page with the product roadmap. /hr goes to your HR tool. /brand goes to the Google Drive folder with brand guidelines. /pitch-deck goes to the current presentation.
Shortcuts are visible to everyone on the team and work in the browser. When the URL behind a shortcut changes (because someone moved a Notion page or swapped analytics tools), the shortcut gets updated once. Everyone else notices nothing.
This isn’t an intranet in the traditional sense. There’s no homepage, no news feed, no comments section. It’s a table of contents. A really useful table of contents, because it solves the one problem that actually comes up every day: “Where do I find X?”
Who this works for (and who it doesn’t)
This approach can work well for small and midsize teams that use multiple SaaS tools and either do not have an intranet or struggle to get value from one.
It works less well for companies that need an intranet as a communication channel for news, announcements, CEO updates. For that, you do need an interface with a feed and comments. But even then, a portal doesn’t solve the navigation problem. You need both: a place for communication and a place that tells you where things live.
What this means for IT
Traditional intranet projects can take months and require dedicated administration. Even a capable portal has an adoption problem when people still ask in Slack where the vacation form is.
A navigation layer can start with a small set of high-use links and grow over time. Maintenance can be shared across the team, and the browser extension gives people a direct address-bar workflow.
Larger companies with compliance requirements probably need full intranets. But for a 20-person startup deciding between Confluence or a Notion page as its “intranet”? A lightweight navigation system makes more sense.
Next time someone on your team says “We need an intranet,” ask back: “What exactly should it solve?” If the answer is “People can’t find anything,” you don’t need a portal. You need a table of contents.