Build, Buy or Embed? The Document Features Your Enterprise Customers Expect in 2026
Somewhere on your product roadmap, probably filed under a deceptively small heading like “document support”, sits one of the biggest build-versus-buy decisions your SaaS product will ever face. An enterprise prospect asks where contracts live in your platform. A customer success manager reports that users keep emailing files to each other because the product only stores attachments. A competitor announces in-app editing. However it arrives, the conclusion is the same: enterprise customers now assume that documents live inside the product — uploaded, previewed, edited, co-authored, versioned, searchable and retained — not bolted on beside it.
The question is how you get there. In our work with SaaS and software vendors, we see teams weigh the same three routes again and again: build the document capability from scratch, integrate each customer’s own Microsoft 365 tenant, or embed a managed document platform inside the product. This article is a product manager’s guide to that decision — how to add document management to your SaaS product without betting the roadmap on the wrong route, and how to think about build vs buy document editing as the genuinely strategic choice it is. It stays deliberately at product level; if you want the architect’s-eye comparison of the underlying Microsoft technologies, we have written a decision framework for ISVs and enterprise architects separately.
The Expectation Has Moved
Ten years ago, “document support” meant an upload button and a download link. Five years ago it meant an in-browser preview. In 2026, enterprise buyers evaluate your document features against the experience they get in Microsoft 365 itself, because that is what their users live in all day. The expectation stack now looks like this:
- Storage and upload — table stakes, and has been for a decade.
- Preview — viewing a Word document, Excel workbook or PDF without downloading it, with reasonable fidelity.
- Editing — changing the document in place, in the browser, without a download–edit–reupload loop.
- Co-authoring — two or more people in the same document at the same time, with presence and automatic merging.
- Versioning and history — who changed what, when, with the ability to restore.
- Search — finding documents by their content, not just their filename.
- Retention and governance — the ability to answer an enterprise IT team’s questions about where documents live and how long they are kept.
The further down that list you go, the harder the engineering gets — and the more decisive the capability becomes in enterprise deals. Buyers have learned to ask, because the difference between a product that holds documents and a product where document work actually happens is the difference between a system of record and a shared drive with a login screen.
Document-centric features have been product differentiators for as long as we have been building software for SaaS vendors — years ago we built Slidebank.com, a presentation management service, an iPad app so their customers could manage and share libraries of PowerPoint slides on the move. The formats and form factors change; the underlying truth does not. Products win when the document workflow lives where the users already are.
Route One: Build It Yourself
The build-from-scratch route always looks most attractive at the top of the expectation stack and becomes progressively less survivable as you descend it.
Storage and upload are genuinely buildable. Object storage is cheap, mature and well understood, and plenty of products run their own document store perfectly well. Preview is harder but tractable: rendering pipelines and conversion services exist, and for read-only viewing the fidelity bar is lower.
Editing is where the route collapses, and it is worth being blunt about why. Word, Excel and PowerPoint files are not simple formats with a few styling options; they are deep, decades-old formats carrying tracked changes, comments, fields, cross-references, numbering schemes, embedded objects, pivot tables, macros and a long tail of behaviour that users rely on without knowing it has a name. An editor that handles 80 per cent of the format does not deliver 80 per cent of the value — it silently corrupts the other 20 per cent, and the user who opens the mangled document in desktop Word blames your product, not the format. Add real-time co-authoring, which requires correct merge behaviour across all of that structure with multiple concurrent writers, and you are looking at a problem that even very large software companies choose to license rather than solve. For an ISV whose core product is something else entirely, the editor-fidelity problem is effectively unsolvable at commercial quality. This is the heart of the build vs buy document editing decision: the build option exists for storage and preview, but for editing it is a mirage.
There is one honest exception. If your “documents” are highly structured domain artefacts — inspection forms, structured questionnaires, templated reports that never leave your product — a purpose-built editor for that narrow format can be the right call. The trap is scope creep: the moment a customer asks to open the output in Word, you are back in the fidelity problem.
The build route also carries a bill that never stops arriving. You own the security surface of a file-handling system (a favourite target for attackers), the compliance story for the storage layer, and the obligation to keep pace as Office formats and user expectations evolve. That is engineering capacity permanently diverted from the product your customers actually chose you for.
Route Two: Ride Each Customer’s Microsoft 365 Tenant
The second route is to store and edit documents in each customer’s own Microsoft 365 tenant — their SharePoint sites and OneDrive — with your product integrating via Microsoft Graph. Files live in the customer’s estate, open in the customer’s own Office, and inherit whatever governance their IT team has configured.
On paper this is elegant: no storage cost on your side, data residency answered by definition, and editing fidelity delivered by Microsoft. Some products genuinely suit it — if your product is fundamentally an overlay on the customer’s existing Microsoft 365 estate, working with their content where it already lives, this route can be exactly right.
For most SaaS products, though, the friction is real and it compounds with every customer you sign:
- Consent and onboarding ceremony. Every customer’s Microsoft 365 administrator must grant your application access to their tenant, and must do so again whenever your permission requirements change. Each onboarding now has an IT-approval step you do not control, with all the sales-cycle delay that implies.
- Tenant variance. No two enterprise tenants are configured alike. Conditional access policies, data loss prevention rules, retention labels and third-party security tooling can each interfere with your product’s document flows in ways you cannot predict or reproduce. Your test matrix is every customer’s tenant configuration.
- The support burden lands on you. When a document fails to open, the user raises a ticket with you, not with their IT team — even when the cause is a policy change in their tenant that nobody told you about. Diagnosing faults inside an estate you do not administer is slow, and the customer experiences that slowness as your product’s unreliability.
- Uneven capability. What your document features can do becomes a function of each customer’s licensing and configuration. A feature that works beautifully in one account silently degrades in another, which is a miserable foundation for a consistent product experience — and for the marketing claims your sales team wants to make.
The pattern we see is that this route works at five customers and grinds at fifty. The integration cost is not the code; it is the permanent operational entanglement with every customer’s IT estate.
Route Three: Embed Document Management with SharePoint Embedded
The third route is the newest, and it exists precisely because Microsoft recognised the gap between the first two. SharePoint Embedded lets you embed Microsoft’s document platform inside your own product: documents live in dedicated storage containers that your application owns and controls, while users view, edit and co-author them in the full-fidelity Office web editors — inside your product’s interface, under your product’s navigation and branding. If the concept is new to you, we have written an introduction to what SharePoint Embedded is and where it fits; the short version is that it is Microsoft’s modern path for ISVs who want to embed Microsoft 365 document editing without either building an editor or camping in every customer’s tenant. (Microsoft’s earlier partner route to embedded Office editing, the WOPI protocol, still exists; for new products, SharePoint Embedded is the intended path, and the decision framework article covers the choice in depth.)
What makes this route compelling at product level is which problems it removes. Editing fidelity is Microsoft’s problem: documents open in the same Word, Excel and PowerPoint web experiences users already know, so the corrupted-formatting risk of Route One simply does not exist. Co-authoring, presence, autosave, version history and content search arrive as platform behaviour rather than roadmap items. And because the documents live in Microsoft 365 storage, a large part of the compliance conversation — encryption, resilience, the certifications enterprise IT teams ask about — is inherited from the platform rather than built and evidenced by you.
The expectation of full-fidelity, in-product Office editing is one we have watched harden across our document-platform engagements. When we worked with Kendox, a document and process automation provider, the requirement was exactly this shape: their users needed to open, edit and save Word, Excel and PowerPoint documents directly inside the Kendox web application — no downloading, no reuploading — with version control and audit trails maintained in the platform. That is the bar your enterprise customers are measuring you against.
Route Three is not effort-free, and you should not let anyone tell you otherwise. Your team still designs how containers map onto your product’s own concepts — projects, matters, engagements, accounts — how your permission model translates onto document permissions, and how the editing experience launches from your UX. There is also a cost model to price in: storage and usage are consumption-billed to you as the vendor, which means document-heavy customers carry a real cost of goods that your plans and pricing need to anticipate. But this is weeks-to-months of product engineering on top of a managed platform, not the open-ended commitment of Route One or the operational entanglement of Route Two. That trade — your effort spent on your product’s document experience rather than on document infrastructure — is why SharePoint Embedded for ISVs has become the default recommendation in our scoping conversations.
Five Criteria for Making the Call
Strip the decision down and five criteria do most of the work.
Time-to-market. Building editing from scratch is measured in years and rarely completes. Tenant integration is quick to demo and slow to industrialise, because the long pole is per-customer onboarding and support, not code. Embedding puts a credible first release within a quarter for most teams, because the hard capabilities already exist.
Editing fidelity. Only routes that put real Office editors in front of users clear the bar enterprise users actually apply. Routes Two and Three both do; Route One, for general Office documents, does not.
Compliance inheritance. Route Two inherits the customer’s compliance posture; Route Three inherits Microsoft 365’s platform posture within your product; Route One inherits nothing — every control is yours to build and evidence. If your buyers run security reviews, this criterion alone can decide the question.
Cost model. Route One is a large fixed engineering cost plus permanent maintenance. Route Two is cheap in infrastructure and expensive in onboarding and support operations. Route Three is a consumption cost that scales with usage — the most predictable of the three, provided you price for it from day one.
Support burden. Ask one question of each route: when a document fails to open at 4 p.m. on a customer’s deadline day, whose systems do you debug? For Route One, your own editor — bad. For Route Two, the customer’s tenant — worse, because you cannot see it. For Route Three, your integration layer over a managed platform — narrow, observable and yours.
Weight the criteria for your product and buyers rather than scoring them in the abstract. A product selling to regulated enterprises weights compliance inheritance and fidelity heavily, which points firmly at embedding. A product whose entire purpose is augmenting a customer’s existing Microsoft 365 estate may still choose Route Two with open eyes.
Sequencing the Roadmap: Preview, Then Editing, Then Co-Authoring, Then Intelligence
Whichever route you choose, resist the temptation to announce the whole expectation stack at once. The sequencing that works — for engineering risk and for sales narrative alike — runs in four stages.
Preview first. In-product viewing removes the ugliest part of the current experience (the download–open–squint loop) and ships fast. It also forces you to solve the foundational plumbing — where documents live, how your permission model applies — while the user-facing stakes are low.
Editing second. In-place editing is the stage customers actually notice and the stage that starts changing behaviour: documents stop leaking out to desktops and inboxes because there is no longer a reason to take them there.
Co-authoring third. Once editing is embedded, real-time co-authoring is the feature that converts your product from a place documents are kept into the place work happens. On the embed route this is largely a matter of switching it on and designing around it; on any other route it is a mountain. Sell it when it is real, not before.
Intelligence last. Search, summarisation, extraction and the AI-assisted features your roadmap is inevitably accumulating all depend on documents being inside the product with structure and permissions attached. Teams that try to lead with intelligence before the storage and editing foundations exist end up rebuilding twice. Get the documents in first; the intelligence roadmap then has something to stand on.
This sequencing also derisks the decision itself. Preview commits you to very little; by the time you reach the editing stage, you will know your route’s true costs from lived experience rather than from a vendor deck — ours included.
How McKenna Consultants Can Help
McKenna Consultants has spent more than 25 years building Microsoft document integration for software vendors — from the Slidebank mobile presentation app to embedding full in-browser Office editing into the Kendox document management platform. That history is precisely the build-buy-embed decision this article describes, lived from the inside across many products, and it is why our SharePoint Embedded development practice starts with the product decision rather than the code.
If document features are climbing your roadmap and you want an honest, experienced view of which route fits your product, your buyers and your team — or you have already chosen to embed and want it built well — get in touch. A short scoping conversation now is considerably cheaper than a wrong turn discovered two quarters in.
