One question comes up before any intranet project really starts: do you build one in-house, or buy intranet software and configure it? It’s a real fork, and the honest answer depends on your requirements, your team, and how long you can commit engineers to something that isn’t your core product.
I’ll be upfront about where I sit: I run Axero, so we’re a buy-side platform. But I spent years at McKinsey watching organizations build things they’d have been better off buying, and the pattern held — the build looks cheaper on the first spreadsheet and rarely stays that way once year-two maintenance shows up. So read the rest of this as the honest version of the trade-off, not a pitch. There are real cases where building is the right call, and I’ll say so plainly when we get to them.
The trade-off has also shifted since this was a simple make-or-buy call. Two things buyers now weigh heavily — security and compliance ownership, and the pace of AI and feature development — used to be afterthoughts. Both make a stronger case for buying than they did a few years ago, but not in every situation. This guide walks the decision criterion by criterion so you can reason it through rather than take anyone’s word that one side “almost always wins.”
First, this isn’t a two-way choice
“Build vs. buy” is how everyone frames it, including us until recently. The framing hides something important: most teams weighing a build are actually weighing three paths, and one of them gets miscategorized constantly.
- Custom or homegrown build. You own the code, the hosting decisions, the roadmap, the patching, and the support line.
- SharePoint and Microsoft 365, configured. This one is usually filed under “build,” and it doesn’t belong there. SharePoint Online is purchased, vendor-managed software. Microsoft runs the platform, patches it, and sets its roadmap. What you or a partner own is the information architecture, governance, branding, integrations, custom extensions, and adoption — which is real work, often a lot of it, but it is not the same job as maintaining a platform you wrote.
- A purpose-built intranet platform. The vendor owns the platform and roadmap; you own configuration, content, governance, identity, and whether people actually use it.
Lumping 2 and 1 together is what makes build-vs-buy comparisons feel rigged. The honest comparison puts all three side by side.
Which posture is your organization already in?
Before the criteria, it helps to know which way you’re oriented.
You’re build-centric if: you have an in-house engineering team you can commit to the intranet for years — not just to launch it, but to patch, secure, and extend it indefinitely — and your requirements are genuinely unlike what any off-the-shelf platform offers. Building only pays off when the intranet is core enough to your business to justify owning the whole stack.
You’re configure-centric if: you’re already deep in Microsoft 365, the licences are sunk cost, and you have IT capacity or a partner budget for information architecture and governance. The platform question is settled; the open question is how much internal-communications capability you can shape out of it, and who maintains that shaping.
You’re buy-centric if: you need to launch in a couple of months rather than the quarters-to-years a build takes, you’d rather your IT team govern and configure than build and repair, and you want new capabilities — mobile, AI search, integrations — to arrive on a vendor’s roadmap instead of your backlog. This describes most organizations, because for most, the intranet is critical to run but not something they want to spend engineering years maintaining.
None of these is “better.” They point at different costs. The rest of this comparison makes those costs concrete.
Three paths, criterion by criterion
| Consideration | Custom / homegrown build | SharePoint & Microsoft 365, configured | Purpose-built intranet platform |
|---|---|---|---|
| Who owns the platform | You do — code, hosting, upgrades, roadmap. | Microsoft. You own how it’s shaped, not what it is. | The vendor. You own how it’s configured. |
| Time to launch | Months to a year or more, depending on scope and how much you build from scratch. | Weeks for something basic; months for a governed, branded, well-structured deployment. | Weeks to a couple of months. In our own implementations it’s commonly around two, though that depends on content readiness, integrations, and security review as much as on the software. |
| Cost over time | Lower upfront if you already have developers — but the real cost is ongoing engineering time to build, then maintain, patch, and extend it indefinitely. | Licences you may already hold, plus the part people forget to budget: partner or internal time for IA, governance, branding, and custom work. | Predictable subscription. The vendor absorbs hosting, upgrades, and R&D across their whole customer base instead of your one team. |
| IT maintenance burden | Falls entirely on your team. Every browser change, security patch, and feature request is your backlog. | Microsoft patches the platform. Your team still owns structure, permissions, governance, and anything custom you built on top. | Handled by the vendor. Your IT team configures and governs rather than builds and repairs. |
| Security & compliance ownership | You own the entire surface — authentication, permissions, audit logging, penetration testing, and the controls and evidence behind every framework you answer to. | Shared. Microsoft runs and certifies the platform; you own identity configuration, permission design, data classification, retention, and governance. | Shared, on the same split. A mature platform ships SAML SSO, SCIM provisioning, and audit trails, and gives you its SOC 2 report and ISO 27001 certificate for your own evidence package. |
| Feature velocity (mobile, AI) | Limited to what your roadmap has room for. New capabilities — a mobile app, AI-powered search, analytics — each become a full project. | Microsoft’s roadmap, which is enormous but aimed at the whole M365 surface rather than internal comms specifically. | You get the vendor’s roadmap without staffing each item yourself. AI search and mobile ship as product updates. |
| Ongoing support | None — your team is the support line for every issue and every new hire’s question. | Microsoft support for the platform; your team or your partner for everything you configured. | A support team, documentation, and an implementation partner who has launched this many times. |
| Fit & customization | Total control. You build exactly the navigation, features, and data model you want. | Highly customizable, but advanced branding, IA, and tailored workflows generally need specialist SharePoint expertise or partner support. | High, within guardrails. A flexible platform is configured to your structure and brand, but you don’t control the underlying code. |
On “inheriting” compliance — you don’t
This is worth stating plainly, because the shorthand everyone uses is wrong. You cannot inherit compliance from a vendor, and two of the four things people list together aren’t the same kind of thing at all:
- SOC 2 reports and ISO 27001 certification belong to the vendor. You can reference them in your own due diligence and hand them to an auditor as evidence about the platform. That genuinely saves you work.
- GDPR and HIPAA are laws and regulatory frameworks, not certifications anyone hands you. No vendor can be “GDPR certified.” Your obligations under them depend on your data, your configuration, your contracts, and your processes.
Buying a certified platform shrinks the evidence you have to produce about infrastructure. It does not move responsibility for identity configuration, permissions, data classification, retention, user behaviour, or your legal obligations. Those stay with you on all three paths.
Budget across three to five years, not one
Whichever path you’re leaning toward, price it over the horizon you’ll actually live with. The line items that decide the answer are rarely in the first quote:
- Internal engineering time — to launch, then to maintain indefinitely
- Product ownership: someone accountable for the thing existing and improving
- Security and compliance work, including review cycles and evidence gathering
- Hosting and infrastructure, where you own it
- Partner or consulting fees, including the ones you’ll need for changes later
- Integrations, and re-doing them when the systems on either end change
- Content migration and the cleanup nobody scopes
- Support — for the platform and for the employees using it
- Upgrades and change requests
- Opportunity cost: what your engineers would otherwise have shipped
Fill that in for each path you’re seriously considering. A build that looks cheaper in year one frequently isn’t by year three, and a configuration project can carry more partner cost than a subscription.
When building is the right call
Buying is the default for most teams, but building deserves a fair hearing — there are situations where it’s genuinely the better choice.
- Your requirements are truly unique. If your intranet has to model a workflow or data structure no commercial platform supports, and that workflow is central to how your business runs, owning the code may be worth it.
- You have a committed in-house team. Not just developers to launch it, but a team you can keep pointed at it for the long haul — security patches, browser compatibility, and feature requests never stop arriving.
- Control is a hard requirement. Some organizations need to own every layer for reasons of data residency, IP, or internal policy. (Worth noting: many buy-side platforms now offer self-hosted deployment, so “we need to control where the data lives” doesn’t automatically mean “we have to build it” — see how a self-hosted platform handles this.)
The honest risk with building is that the costs that sink these projects are the ones that show up after launch: the year-two maintenance, the developer who leaves with the whole thing in their head, the feature the business needs that turns into a six-month internal project. Go in with eyes open about the ongoing commitment, not just the build.
When buying wins
For most organizations, the math favors buying — and the reasons have gotten stronger.
- Speed. A configured platform is live in weeks to a couple of months, depending on your scope. A custom build is a multi-quarter — often multi-year — project before anyone logs in.
- Your IT team does higher-value work. Instead of maintaining an internal tool, they govern access, manage integrations, and configure — and stay free for projects that actually differentiate the business.
- The security surface is already built. SSO, provisioning, audit trails, and third-party certifications ship with the product, so your side of the shared-responsibility line starts much further along. Reproducing that surface in a homegrown build is a large, ongoing, and easy-to-underestimate job.
- You inherit a roadmap. Mobile apps, AI-powered knowledge search, and new integrations arrive as updates. You benefit from R&D funded across every customer, not just your budget.
What to look for when buying intranet software (2026 checklist)
If you land on buying, the platforms are not interchangeable. Here’s what actually separates a strong one — updated for what matters now.
- Transparent pricing. Ask what you’ll pay in year two, not just year one. Implementation, support tiers, and per-feature add-ons aren’t always in the first quote. Watch for fees vendors don’t lead with.
- Security and compliance you can evidence. Confirm SAML-based SSO with your identity provider (Okta, Microsoft Entra / Azure AD, Google), SCIM provisioning so leavers are deprovisioned automatically, and audit logging. Ask for the vendor’s SOC 2 report and ISO 27001 certificate — those are theirs to provide and yours to reference. Then ask separately how the platform supports your obligations under frameworks like GDPR or HIPAA: data residency options, retention controls, a DPA, and a BAA where one applies. Check the security and compliance details before you shortlist.
- AI and knowledge search. This has gone from a differentiator to an expectation in about two years. A modern intranet should let someone ask a plain-language question — “what’s our PTO carryover policy?” — and get an answer drawn from your actual content, with a citation, instead of a folder to dig through. For new hires and frontline staff, search that works is the difference between a tool they use and one they abandon. See how intranet search should behave.
- The features you’ll actually use. Document sharing, wikis and articles, events, spaces, chat, and a homepage you can shape. Map the platform’s feature list against what your teams do every day — if the essentials are missing, you’ll feel it within a month.
- Responsive support. Not a knowledge base and a ticket queue — real people who answer, and an implementation partner who has launched this many times. Ask about response times and who you’ll actually talk to.
- Flexibility without a rebuild. Avoid rigid, one-size-fits-all products that lock you into their layout. You want a platform you can configure to your structure and brand without touching code — and reconfigure as you grow.
Making the call
Build vs. buy comes down to a single question: is your intranet different enough, and central enough, to justify owning and maintaining the entire stack — indefinitely? If yes, and you have the team to commit, building can be the right long-term investment. If not — and for most organizations it isn’t — a flexible platform gets you live faster, hands you the platform half of the security and compliance work, and puts a roadmap behind you.
When a prospect asks me straight out which way to go, I usually answer with a question: if this intranet disappeared tomorrow, would you want to rebuild it yourself, or would you be relieved to hand it to someone whose whole job is running it? Most leaders already know their answer — they’re really asking for permission to trust it. Owning the stack pays off when the intranet is genuinely yours to own; for everyone else, the engineering time you’d pour into maintaining it is better spent on the work only your team can do.
Once you’ve made the decision, the next question is execution: how to actually stand the thing up and get people using it. That’s a separate discipline, and we’ve written the step-by-step version of it. When you’re ready to move from deciding to building, How to Build an Intranet walks through content, spaces, governance, and security as eight build tasks, then covers piloting, launching, and driving adoption.
