Overview
A portal is an information architecture problem first
The technology is rarely what makes an intranet fail. What kills adoption is a navigation structure that made sense to the project team and nobody else, permissions nobody can explain, and a homepage that stops being accurate three months after launch.
- Information architecture firstSite structure, navigation, metadata and search configuration designed before a single page is built.
- Custom SPFx componentsWeb parts built in React and Fluent UI where out-of-the-box parts fall short — not because custom code is impressive, but because the requirement needs it.
- Governance that holdsSite provisioning templates, naming standards and permission models so growth does not become sprawl.
- Bilingual by designEnglish and Arabic with proper RTL layout handled in the component layer, not retrofitted with CSS overrides.
Architecture
Hub-and-spoke architecture
Departmental sites inherit navigation, branding and search configuration from the hub, so a new site is consistent on day one rather than after a redesign.
What is included
What a portal build includes
Discovery and IA
Stakeholder interviews, content audit, card sorting where it helps, and a documented site map with navigation and metadata schema.
Design system
A component library and page templates in your brand, applied consistently so every new site inherits the same look without redesign.
Custom web parts
SPFx components in React — news rollups, directories, dashboards, request forms — built against SharePoint REST and Microsoft Graph.
Search configuration
Managed properties, refiners and result sources configured so search returns what people are actually looking for.
Provisioning templates
PnP templates so new department sites are created consistently rather than assembled by hand each time.
Training and handover
Author training, admin documentation and a governance handbook your team can maintain without us.
In practice
Where intranet projects usually go wrong
The most common failure we are called in to fix is a portal built entirely by IT without content owners in the room. It launches, looks correct, and then nobody updates it. Six months later the news feed is stale, the document library has three copies of every policy, and departments have quietly moved back to email and shared drives.
The second most common is permissions. Broken inheritance applied ad hoc during the build, spread across hundreds of items, until nobody can answer a simple question about who can see what. Untangling that after the fact costs considerably more than designing it properly at the start.
Both are avoidable, and both are addressed in discovery rather than in development. That is why we will not quote a portal build without an audit first.
Questions
Common questions
Can you work with our existing SharePoint tenant?
Yes. Most engagements are improvements to an environment that already exists rather than greenfield builds. We start with an audit of what is there.
Do we need custom development, or will out-of-the-box work?
Frequently out-of-the-box is enough, and we will say so. Custom SPFx development is worth it when a genuine requirement cannot be met otherwise — not as a default.
How do you handle content migration into the new portal?
Content is inventoried during discovery and mapped to the new structure. Migration runs as a defined phase with validation before cutover. See our migration service for detail.
Will our team be able to maintain it?
That is the point of the governance handbook and author training. If you need us to change a page after handover, we have designed it badly.