Intranet in a box vs SharePoint: a licence you rent, or a build you own

The question usually arrives mid-evaluation. Someone has sat through a polished demo of an intranet product: a home page that looks finished on day one, a news feed with comments and reactions, a staff directory, a dashboard of pre-built web parts, and a price quoted per employee per month. Somebody else in the room points out that the company already pays Microsoft for SharePoint, and asks what exactly the subscription is buying that the tenant does not already do.

Both people are being reasonable, and the demo is not a trick. What makes the decision hard is that almost everyone publishing on it has something to sell: the product vendors sell the product, and the consultancies sell the build. So here is our position stated plainly before anything else, because you should be able to weigh it: we build native SharePoint intranets, and there are still cases below where we would tell you to buy the product instead.

This page is deliberately the step before the ones we cover elsewhere. It is about whether to buy a per-user intranet product at all. Once you have decided to build natively, the follow-on questions are separate: what drives the cost of a SharePoint intranet covers the money, what a SharePoint intranet in 30 days really looks like covers the delivery, and our SharePoint consulting practice covers who does the work. Nothing on this page carries a fee, a day rate or a band, and we have not put a headcount crossover point on it either, because the honest drivers are qualitative and the numbers you see quoted around this topic belong to whoever was selling at the time. If the shape of this argument feels familiar, it is the same one as Power Apps versus buying software in a different product area.

What the product layer actually adds

Most intranet-in-a-box products are not alternatives to SharePoint. They run on it. The vendor builds pre-configured sites, custom web parts, publishing workflows, theming controls and an administration console on top of SharePoint Online inside your own Microsoft 365 tenant, then licenses that layer per user. Understanding this is most of the decision, because it means you are not choosing between two platforms. You are choosing whether to rent a finished assembly of the platform you already own.

That framing also explains what you get. The product sells you time and defaults: an information architecture someone else already argued about, page designs that look deliberate without a designer, and features that would be a project each if you built them, such as pulse surveys, recognition walls, birthday feeds or mandatory-read acknowledgement tracking. These are real. Dismissing them as "just SharePoint" is the mistake consultancies make.

What it does not sell you is the platform underneath, which you keep paying for either way, or the work only you can do. Microsoft’s own intelligent intranet roadmap (opens in new tab) lists the success factors, and read the list closely: an executive sponsor, goals tied to business outcomes, a governance plan, a content audit before anything moves, and training for content creators and users. Not one of those is a software feature. The same document says intranets “are a constant work in progress and are never really considered done,” which is the sentence both sides of this argument tend to skip.

The two bills are shaped differently

We publish no figures for either option, because both move and a stale number is worse than none: the money question for a native build is handled separately in our breakdown of what drives SharePoint intranet cost. What matters for the decision is the shape of the spend, and the shapes genuinely differ. One tracks your headcount forever; the other tracks the scope of a project that ends.

Read the first and last rows together, because that pairing is the actual trade. A subscription converts a capital decision into an operating one, which is a genuine advantage when budget is annual and small. It also means the intranet is only ever leased, and the leverage in every renewal conversation sits on the other side of the table. A build reverses both halves.

When we would tell you to buy the product

Four situations, and they are not edge cases. If two or more describe you, take the demo seriously.

Nobody internal can own it. This is the strongest case by a distance. An intranet with no owner decays no matter who built it, but a product decays more slowly, because the vendor keeps shipping structure and defaults into it while your attention is elsewhere. If you cannot name the person and the hours they will get, buy the thing that degrades gracefully.

The launch date is hard and external. A merger announcement, an office move, an acquisition close, a compliance deadline with a date attached. Pre-built is faster than designed, and a product that is live and imperfect beats a build that is elegant and late. You can make it yours afterwards.

You genuinely need the pre-built engagement features. Comment threads, reactions, recognition, polls, pulse surveys, birthday and anniversary feeds, mandatory-read acknowledgement tracking. If your communications team will actually use these weekly, buying them assembled is cheaper than commissioning each one, and honest scoping should say so rather than quietly proposing to build a smaller version of the same thing.

You need several languages from the start. SharePoint supports multilingual pages and news, but Microsoft is explicit in its guidance on planning a global intranet (opens in new tab) that “user interface elements and pages are not translated automatically” — each page has a corresponding page in the target language that you, or someone you assign, translates manually, and site name and navigation have to be translated too. Products that build translation workflow into the authoring experience are solving a real, recurring burden rather than a one-off setup task.

What is not on that list: looking finished on day one. Every intranet looks good at launch. The ones that still look good a year later are the ones somebody was tending, which is a staffing decision rather than a purchasing one.

When owning the build wins

The build case rests on three things, none of them about features. First, ownership: when the project ends, the sites, pages, permissions and content are ordinary SharePoint objects in your tenant, and there is no licence whose expiry changes that. Second, fit: an intranet that mirrors how your organization is actually shaped, rather than how a template assumes it is shaped, gets used, and the gap between those two shapes is exactly where products get abandoned. Third, ceiling: the native platform is where the rest of your Microsoft 365 investment already lives, so an intranet built on it extends naturally into Teams, Power Automate approvals and search across everything you own.

There is also a quieter argument that only shows up later. A product layer is a dependency you have to carry through every future decision: the tenant migration, the compliance review, the Copilot rollout, the year the vendor is acquired and the roadmap changes owners. A native build has no such passenger. It is worth noting that the governance work does not disappear when you build — permissions, naming, provisioning and retention still need deciding, which is why we scope SharePoint governance as explicit work rather than assuming it arrives with the platform. The difference is that you are deciding it, and it stays decided.

Which way each signal points

No single row settles this. Run your own situation down the table and look at the pattern: if most rows point one way, trust that, and if they split, the split itself is usually telling you the real constraint is organizational rather than technical.

What changing your mind costs

Ask this before signing either way, because the two directions are not symmetrical and almost nobody raises it during an evaluation.

Leaving a product: your documents are fine. They live in SharePoint libraries in your tenant and they stay there. What does not survive is the part staff actually see, because pages assembled from vendor web parts generally stop rendering when the licence lapses. Navigation, dashboards and page layouts are rebuilt, and the news archive may need re-creating depending on how the vendor stored it. Get the specifics in writing during the evaluation, including what remains readable during any wind-down period, and treat vagueness as an answer in itself.

Leaving a build: there is nothing to leave. A native intranet that stops being useful is redesigned — the scope of a SharePoint intranet redesign is a project of its own — and the sites, libraries and permissions stay where they are while you do it. The cost is the redesign, not a repatriation.

The asymmetry does not settle the decision, but it does price the option. Buying is a reversible decision with an exit fee you can find out in advance; building is a less reversible decision with no exit fee at all. Which of those you prefer depends mostly on how confident you are about the next three years.

How to read the two proposals side by side

You can usually resolve this from documents already on your desk. Five questions do most of the work.

Ask the vendor which parts run in your tenant. Almost all of it usually does, which is reassuring on data residency and clarifying on value: you are paying for the layer, not the hosting.

Ask what happens at non-renewal, specifically to pages, navigation and news, not to files. Files are the easy answer and the one you will be given first.

Ask both sides what is excluded. Content migration, content writing, governance decisions and training are excluded from most product subscriptions and from thin build quotes alike. They are the majority of the effort in either path, so a proposal that is silent about them is not cheaper, only less complete.

Ask who administers it on day 31. If the answer differs between the two proposals, that difference is the real comparison.

Ask for the second-year picture. For the product, that is the renewal against your expected headcount. For the build, it is whatever changes you expect to ask for. Comparing first-year totals flatters whichever option front-loads less.

If that exercise lands you on the build side, this is the work we do as fixed-fee projects: a scope and one written price agreed before anything starts, senior US-based engineers, typical delivery in two to four weeks, 30 days of hypercare afterwards, and an intranet that is yours outright. You can read how the fixed-fee process works before speaking to anyone. And if it lands you on the product side, that is a legitimate outcome of an honest comparison — take the demo, and ask the non-renewal question first.