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 8 to 15 SaaS tools today. Notion for docs, Jira or Linear for project tracking, Figma for design, Google Drive or SharePoint for files, Slack or Teams for communication. Then specialized tools: a CRM, an analytics dashboard, an HR system, a 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: employee opens intranet, searches for “vacation request,” maybe finds a link to the HR tool. Or: employee types short/vacation into the browser address bar and lands in the HR tool directly.
What this looks like in practice
The team creates shortcuts for the most important resources. short/roadmap goes to the Notion page with the product roadmap. short/hr goes to your HR tool. short/brand goes to the Google Drive folder with brand guidelines. short/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 works best for teams of 5 to 100 people who use multiple SaaS tools and either don’t have an intranet or have one that nobody uses.
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 are IT projects. They take months, cost six figures, and need dedicated admins. Most fail not because of the technology but because of adoption. The best portal in the world is useless if people keep asking in Slack where the vacation form is.
A navigation layer takes an hour to set up, not a quarter. Maintenance is distributed across the team. And adoption is high because it doesn’t require new behavior — you type an address into the browser instead of searching for a URL.
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.