SharePoint Buy vs Build Framework: OOTB vs Marketplace vs Custom Development
Executive Summary
Every SharePoint environment eventually hits a gap. The out-of-the-box calendar does not aggregate across sites. The default list view cannot render a Kanban board. The intranet needs a layout that communication sites do not provide natively. At that gap, a decision gets made — usually fast, usually without a framework, and usually expensive in the wrong direction.
This guide exists because organizations keep getting that decision wrong in two predictable ways. Some over-buy: licensing a full intranet platform or workflow suite at five or six figures annually when the actual need is narrower than the product. Others over-build: engaging a consulting firm or internal team to write custom SPFx code for functionality that already ships as a tested, supported product on Microsoft AppSource or the Azure Marketplace.
Both mistakes share a root cause. The decision skips a step. There are not two options in SharePoint — buy or build. There are three: configure what Microsoft already provides, purchase a marketplace product that extends it, or build something custom. Most organizations collapse the first two into "we already tried SharePoint and it didn't work" and jump straight to a build engagement. Or they purchase a broad platform license without checking whether a targeted marketplace product — or even native configuration — would have been enough.
The framework presented here — the Solution Hierarchy — provides a structured, repeatable method for evaluating these three tiers in order. Configure first. Buy second. Build last. Each tier has explicit decision gates that prevent premature escalation to the next. The goal is not to avoid custom development. The goal is to make sure custom development only happens when the first two tiers have been honestly evaluated and ruled out.
This guide is written for IT directors, CIOs, program managers, and SharePoint administrators who influence or approve technology decisions in their organizations. It applies equally to federal agencies evaluating FITARA-compliant modernization paths, commercial enterprises managing M365 sprawl, and nonprofits trying to stretch limited IT budgets.
The Problem: Two Expensive Defaults
Organizations that run SharePoint and Microsoft 365 tend to fall into one of two dysfunction patterns when they encounter a platform gap. Both are expensive. Both are avoidable.
Dysfunction 1: The Licensing Trap
A department needs an intranet with branded navigation, news aggregation, and an employee directory. Someone — usually a vendor rep, sometimes an internal champion who attended a conference — recommends a packaged intranet product. The product is impressive in demos. It has features the team did not know they needed. It integrates with Teams, Viva, and half a dozen other services.
The problem surfaces at procurement. The per-user licensing model, applied to the full site audience, produces an annual cost that dwarfs the actual requirement. A mid-size organization with 2,000 active SharePoint users can find itself evaluating intranet licenses in the range of $50,000 to $150,000 per year — recurring — for a product that addresses perhaps 60% of what they actually need while introducing 40% of features they will never configure.1
This is the square-peg-in-a-triangular-hole problem. The product was built for a broad market. The organization has a specific need. The gap between the two is filled with unused features, unnecessary complexity, and annual renewal invoices.
The same pattern plays out with workflow platforms. An organization needs approval routing on three document libraries. Instead of configuring Power Automate flows — which are included in their existing M365 license — they purchase a third-party workflow engine with visual designers, audit dashboards, and enterprise governance features scaled for organizations running hundreds of workflows. The implementation takes months. The annual license quietly compounds.
Dysfunction 2: The Custom Code Trap
A department head needs a service desk. Users need to submit tickets, IT staff need to triage and assign them, managers need reporting on resolution times. The SharePoint admin raises the requirement. A consulting firm or internal dev team scopes it as a custom SPFx application — a ticket submission form, a technician dashboard, status tracking, SLA timers, email notifications, and a reporting page.
Four to five months later, the custom service desk ships. It works. It cost somewhere between $60,000 and $120,000 in development time, depending on scope creep and the billing rate of the team. It has no roadmap. It has no other customers testing edge cases. When SharePoint pushes its next major update, someone has to regression-test it. When the developer who built it moves on, the institutional knowledge goes with them.
Meanwhile, Microsoft AppSource lists multiple help desk and ticketing solutions built for SharePoint — commercially supported, continuously updated, tested across thousands of tenants — for a fraction of the custom build cost.2
This dysfunction is not limited to small gaps. Organizations have built entire project management boards in SPFx — sophisticated Kanban and Agile tracking interfaces — when AppSource and the Azure Marketplace already offered mature alternatives. Standish Group data consistently shows that only about 31% of IT projects meet success criteria, with large projects succeeding less than 10% of the time.3 In some cases, Microsoft eventually ships the capability natively, and the custom investment becomes a maintenance liability competing with a free, integrated feature.
The custom code trap is often driven not by a lack of marketplace awareness, but by incentive structures. Consulting firms that bill by the hour have no economic incentive to recommend a $5,000 annual product when they can scope a $75,000 build engagement. Internal development teams measured on output rather than outcomes have no structural reason to evaluate commercial alternatives. The result is the same: custom code where commercial products would have been faster, cheaper, and more sustainable.4
What "Buy vs Build" Actually Means in SharePoint
The phrase "buy vs build" is a false binary when applied to the Microsoft 365 ecosystem. SharePoint and its surrounding platform provide three distinct tiers of capability, each with different cost profiles, maintenance burdens, and risk characteristics. Collapsing them into two options is where most decision-making goes wrong.
Tier 1: Configure (OOTB)
SharePoint Online and Microsoft 365 ship with substantial native functionality that most organizations underutilize. Modern communication sites, hub site architecture, out-of-the-box web parts (news, events, highlighted content, quick links, people), Microsoft Lists, Power Automate for workflow, and Power Apps for lightweight forms — all of this is included in the licensing the organization already pays for.
Configuration means using these native capabilities, potentially with customized site designs, content types, managed metadata, and branding within the supported theming framework. No code is deployed. No third-party license is purchased. The total incremental cost is the labor to configure and the ongoing governance to maintain.
The limitation of this tier is real: OOTB SharePoint has well-documented gaps. Calendar aggregation. Advanced people directories. Sophisticated page layouts. Interactive dashboards. When the native capability does not meet the requirement, the question is whether to buy or build the extension — not whether to abandon the platform.
Tier 2: Buy (Marketplace)
Microsoft AppSource and the Azure Marketplace host hundreds of SharePoint-targeted applications — SPFx web parts, Teams apps, Power Platform connectors, and full solutions — built by independent software vendors (ISVs). These products go through Microsoft's certification process, are deployed through the SharePoint App Catalog, and are commercially supported by their publishers.5
The marketplace tier is the most frequently skipped option in the buy-vs-build evaluation. Organizations often jump from "OOTB doesn't do this" directly to "we need to build it" without checking whether a tested, supported product already exists at a fraction of the custom development cost.
Marketplace products carry their own cost profile: per-user or flat licensing fees, typically annual. But they also carry advantages that custom builds cannot replicate. They are tested across thousands of tenants. They are updated by a dedicated product team. They have roadmaps driven by broad customer feedback. When SharePoint ships breaking changes, the ISV absorbs the regression testing and ships a compatible update — the customer does not carry that burden.
Tier 3: Build (Custom)
Custom development means writing and deploying code — typically SPFx web parts, SPFx extensions, Power Platform solutions with custom connectors, or Azure-backed services that integrate with SharePoint. This tier delivers maximum flexibility and can address requirements that no existing product covers.
But custom builds carry the heaviest total cost of ownership. Industry research consistently shows that 60% to 90% of a software product's lifecycle cost accrues after initial development, in the form of maintenance, updates, security patches, and adaptation to platform changes.6 A $60,000 SPFx build can easily generate $150,000 to $250,000 in total lifecycle cost over five years once maintenance, developer turnover, and SharePoint version compatibility are factored in.
Custom builds are the right answer when the requirement is genuinely unique — when no marketplace product and no OOTB configuration addresses the core need. They are the wrong answer when chosen by default, out of habit, or because the decision-maker was not aware of alternatives.
The Hidden Fourth Option: Hybrid
In practice, the best outcomes often combine tiers. A marketplace web part handles 80% of the requirement. A lightweight Power Automate flow or a modest SPFx extension covers the remaining 20%. This hybrid approach captures the maintenance and testing benefits of a commercial product while addressing the organization's specific edge cases with minimal custom code.
Hybrid decisions require the maturity to accept an 80% fit from a commercial product rather than demanding 100% from a custom build that will cost five times as much to maintain. That trade-off is uncomfortable for some decision-makers — and recognizing it as a valid strategy is part of what the Solution Hierarchy is designed to enable.
The Solution Hierarchy: Configure → Buy → Build
The Solution Hierarchy is a three-tier decision framework for evaluating SharePoint and M365 capability gaps. The tiers are evaluated in strict order. Each tier has an explicit gate — a set of conditions that must be met before escalating to the next tier. Skipping tiers or evaluating them out of order is the root cause of most over-spending.
Tier 1: Configure
Evaluate first. Before any external product or custom code enters the conversation, exhaust the native M365 capabilities. This includes modern SharePoint site templates, hub site architecture, OOTB web parts, Microsoft Lists, Power Automate, Power Apps, Dataverse for Teams, and the SharePoint Framework look-book for design inspiration.
Gate to Tier 2: The OOTB capability has been honestly evaluated by someone who understands its current state (not its state two years ago), and a documented gap exists that cannot be addressed through configuration, theming, or supported customization. The gap must be described in functional terms — "we need a ticketing system where users submit requests, technicians triage them, and managers see resolution metrics" — not solution terms — "we need a custom web part."
Tier 2: Buy
Evaluate second. Search AppSource, the Azure Marketplace, and known ISV catalogs for products that address the documented gap. Evaluate at least two commercial products against the functional requirements. Assess licensing cost at the organization's scale, deployment model (App Catalog vs. tenant-wide), vendor support posture, update frequency, and roadmap alignment.
Gate to Tier 3: No marketplace product addresses the core functional gap at an acceptable fit level (generally 70% or higher). Or the total cost of ownership of the marketplace product — including licensing at scale over 3–5 years — exceeds the projected TCO of a custom build with maintenance. Or the requirement involves proprietary business logic, sensitive data handling, or integration with internal systems that no commercial product can safely accommodate.
Tier 3: Build
Evaluate last. Scope the custom build with a full lifecycle cost estimate: initial development, Year 1 stabilization, annual maintenance for Years 2–5, developer knowledge transfer documentation, and SharePoint version compatibility testing. Compare this TCO to the Tier 2 marketplace option — not just to the initial license fee, but to the full 3–5 year cost including renewals.
Build only when: The requirement is demonstrably unique. The marketplace products have been evaluated and rejected for documented reasons. The organization has a plan for maintaining the custom code beyond the initial developer or consulting engagement. The lifecycle TCO has been calculated and accepted.
Why the Order Matters
The hierarchy works because each tier functions as a filter. Tier 1 eliminates requirements that were never real gaps — they were knowledge gaps about native capability. Tier 2 eliminates requirements that feel unique but are actually common enough for a product market to exist. Tier 3 catches only the genuinely unique requirements where custom code is the defensible answer.
When the order is reversed — when an organization starts with "let's build it" and works backward to justify that decision — every gap looks like it requires custom code. The framework prevents that gravitational pull toward the most expensive option.
The Scoring Layer
The hierarchy determines evaluation order. Scoring determines the best option within that order. These are complementary, not interchangeable — the hierarchy ensures no tier is skipped, and the scoring ensures the decision is quantified rather than instinctive.
The process works in two passes. First, evaluate each tier in sequence and confirm whether it clears the gate to the next tier. Second, score every option that was evaluated — including the ones that cleared the gate — using a consistent set of criteria. The highest-scoring option that satisfies the hierarchy gates is the recommended path.
Three rules govern the scoring layer:
Rule 1: Never evaluate Build before Configure and Buy. The hierarchy gates exist to prevent premature escalation. A Build option that was never compared against a marketplace alternative is not a scored decision — it is an assumption.
Rule 2: Score each option using the same evaluation criteria. Functional fit, total cost of ownership over 3–5 years, maintenance burden, upgrade survivability, and time to value. Organizations with regulatory requirements may add compliance and audit risk as a sixth criterion. Each criterion is scored 1–5, where 5 is the most favorable.
Rule 3: Select the option with the highest score that satisfies the hierarchy gates. A Build option can win — but only after Configure and Buy have been evaluated, scored, and documented as insufficient. The scoring makes the rationale auditable.
This structure prevents three common failure patterns. It prevents over-customization by forcing a score comparison against marketplace products before any build is approved. It prevents licensing traps by requiring TCO analysis at organizational scale, not just sticker price. And it prevents long-term maintenance cost surprises by weighting maintenance burden and upgrade survivability as explicit scoring criteria — dimensions that custom build advocates typically minimize during the pitch and discover during Year 2.
The illustrative scores in the diagram above reflect a service desk requirement where OOTB configuration scores highest because the functional gap is moderate and the cost and maintenance advantages are decisive. In a different scenario — say, a requirement with highly specialized business logic and no marketplace equivalent — the Buy column scores lower on functional fit, and Build may legitimately win. The framework does not predetermine the answer. It predetermines the process.
Scoring criteria and weights should be adapted to the organization's priorities. A federal agency under FITARA oversight may weight compliance and audit risk heavily. A startup may weight time to value above all else. The criteria are a starting point, not a prescription.
Key rule: Never evaluate Build until Configure and Buy have been exhausted. The hierarchy is not optional. Scoring quantifies the comparison — it does not override the evaluation sequence.
Applying the Hierarchy: Evaluation Criteria
At each gate in the Solution Hierarchy, the evaluation should address these dimensions. Not every dimension carries equal weight for every organization — but skipping any of them produces blind spots.
Functional Fit
Does the option address the core requirement? Not every feature on the wish list — the core need that prompted the evaluation. A marketplace product that covers 80% of the stated requirements and 100% of the critical ones is a better investment than a custom build that promises 100% coverage but arrives six months late with half the features descoped.
Honest fit assessment requires separating must-have requirements from nice-to-have preferences. Organizations that skip this step consistently over-build because every preference gets treated as a requirement.
Total Cost of Ownership (TCO) Over 3–5 Years
Initial cost is the wrong lens. A marketplace product at $8,000 per year looks expensive next to a "free" OOTB configuration — until the OOTB approach requires 120 hours of Power Automate development to approximate the same functionality. A custom SPFx build at $60,000 looks cheaper than a marketplace product at $15,000 per year — until year three, when the cumulative marketplace cost is $45,000 and the custom build has already incurred $40,000 in maintenance and compatibility fixes.
TCO analysis must include: initial development or license cost, implementation and configuration labor, annual maintenance or renewal fees, developer time for updates and regression testing, training and documentation, and the opportunity cost of tying up development resources on maintenance rather than new capabilities.7
Maintenance Burden
Who carries the ongoing maintenance? For OOTB configurations, Microsoft does — through platform updates. For marketplace products, the ISV does — through product updates that tenants receive automatically. For custom builds, the organization does — through its own developers or a retained consulting engagement.
This dimension is where custom builds carry disproportionate risk. Federal agencies and enterprise organizations frequently discover, two or three years after a custom SPFx deployment, that the developer who built it is gone, the documentation is thin, and the next SharePoint update breaks the solution. The maintenance burden is not theoretical — it is the single largest hidden cost in custom SharePoint development.8
Upgrade Survivability
SharePoint Online updates continuously. Microsoft pushes changes to the platform regularly, some of which affect the SPFx runtime, the page rendering model, or the API surface. OOTB features survive these updates by definition — they are the platform. Marketplace products survive them because the ISV is incentivized to maintain compatibility across their customer base. Custom builds survive them only if someone is actively testing and patching.
The question to ask at the Tier 3 gate: who will regression-test this custom solution after the next SharePoint update? If the answer is unclear, the build decision carries more risk than it appears.
Knowledge Transfer Risk
Custom code creates a dependency on the people who wrote it. When those people leave the organization — or when the consulting engagement ends — the institutional knowledge walks out with them. Marketplace products insulate against this risk because the vendor retains the expertise. OOTB configurations carry the least knowledge transfer risk because the platform itself is the documentation.
For federal agencies operating under FITARA guidance, knowledge transfer risk has compliance implications. GAO has repeatedly flagged federal IT programs that created unsustainable dependencies on specific contractors or individuals.9 The Solution Hierarchy reduces this risk by defaulting to options that externalize expertise retention.
Time to Value
How quickly does the organization get a working solution in front of users? OOTB configuration can often deliver value in days or weeks. Marketplace products typically deploy in days to a few weeks, with configuration time varying by complexity. Custom builds operate on development timelines measured in months — and frequently exceed their initial estimates.
BCG research on large-scale technology programs found that more than two-thirds fail to deliver on time, within budget, or to scope expectations.10 While SharePoint SPFx projects are not typically "large-scale programs," the same planning and estimation biases apply at smaller scales. Custom development timelines are optimistic by default. The Solution Hierarchy corrects for this by ensuring faster options are evaluated first.
Common Failure Modes
The Solution Hierarchy looks obvious on paper. In practice, organizations deviate from it in predictable ways. Recognizing these failure patterns is as important as understanding the framework itself.
The $100K Intranet That Could Have Been OOTB Plus One Web Part
An organization decides it needs a modern intranet. A vendor demos a full intranet-in-a-box platform — branded navigation, news targeting, employee directory, event management, departmental sites. The demo is impressive. The contract is signed. The annual license runs $80,000 to $120,000 depending on user count.
Six months later, the intranet is live. The organization uses the branded navigation, the news web part, and the employee directory. The event management module is unused. The departmental site templates were too rigid, so teams built their own communication sites anyway. Meanwhile, SharePoint's native communication sites, hub navigation, news web part, and people web part — included in the existing M365 license — would have covered 70% of the delivered value. A single marketplace directory web part at $3,000 to $8,000 per year would have covered the rest.
The Custom Kanban Board That AppSource Already Sold
An internal development team spends four months building a custom SPFx Kanban board with drag-and-drop task management, swimlanes, and Agile sprint views. The board is well-built. It integrates with SharePoint lists. The project cost, burdened with developer salaries and overhead, exceeds $100,000.
AppSource listed multiple Kanban and Agile board web parts at the time of development, priced between $2,000 and $10,000 annually. No one checked. The team was measured on what they built, not on the problem they solved.
Three years later, Microsoft ships native board views in Microsoft Lists and Planner integration improvements that render much of the custom functionality redundant. The custom board is now a maintenance burden competing with a free, integrated feature. The sunk cost makes it politically difficult to decommission.
The InfoPath Form That Refuses to Die
InfoPath was deprecated years ago. Microsoft has been actively migrating organizations toward Power Apps for form customization. Yet custom InfoPath forms persist in production across federal agencies and enterprises — maintained by specialists who understand a dead technology, creating a dependency that grows more fragile with every platform update.
This failure mode is not about the initial decision. It is about the failure to re-evaluate. The Solution Hierarchy is not a one-time exercise. It should be re-applied whenever a custom solution reaches a major maintenance milestone — or when the platform evolves to cover what the custom solution was built to address.
The Power Platform App That Became a Governance Nightmare
Power Apps and Power Automate are powerful configuration tools that live in the Tier 1 (Configure) layer of the Solution Hierarchy. But without governance, they metastasize. An organization empowers business users to build Power Apps. Eighteen months later, there are 200 apps, 80% unmaintained, many with premium connector dependencies generating monthly costs, and no inventory of what connects to what.
The failure is not Power Platform itself. The failure is treating configuration-tier tools as if they carry no maintenance burden. They do — just a different kind than custom code. The Solution Hierarchy should account for governance overhead in Tier 1 the same way it accounts for maintenance overhead in Tier 3.
Three Real-World Scenarios
The following scenarios illustrate the Solution Hierarchy applied to different organizational contexts. Names and identifying details are fictionalized or composited, but the decision patterns reflect real engagement experience.
Scenario A: IT Asset Tracking — Buy Wins on Fit, Build Wins on Uniqueness
A mid-size healthcare company needs to track IT assets — laptops, monitors, mobile devices, network equipment — through a lifecycle that includes procurement, assignment, maintenance, and decommission. The workflow has internal-specific requirements: assets must be approved through a multi-tier chain that routes differently depending on asset category, and the decommission process triggers compliance documentation specific to the organization's data handling policies.
The team evaluates the Solution Hierarchy. Tier 1 (Configure): SharePoint lists with Power Automate flows could handle basic tracking, but the multi-tier conditional routing and compliance document generation exceed what Power Automate delivers cleanly without premium connectors and extensive flow complexity. Tier 2 (Buy): Two AppSource IT asset management products are evaluated. Both cover standard lifecycle tracking well. Neither accommodates the organization's specific approval routing or compliance documentation triggers without significant customization — and the customization paths available in both products are limited to their built-in configuration options.
The team proceeds to Tier 3 (Build) — but scopes the build narrowly, following the kind of pragmatic custom application development approach that targets only the unique delta. They purchase the marketplace product that covers 70% of the requirement (standard asset tracking, assignment, and reporting) and build a targeted Power Automate + Azure Function integration that handles the unique approval routing and compliance document generation. Total cost: $6,000 annual license plus approximately $25,000 in custom integration work. Compared to the $90,000+ a full custom build was initially scoped at, the hybrid approach delivers faster, costs less, and reduces the custom maintenance surface to a small, well-documented integration layer.
Scenario B: Intranet for a Large Nonprofit — Build Wins on Math
One of Zenpo's Microsoft 365 consulting clients — a large nonprofit organization — needed a modern SharePoint Online intranet. Branded navigation, department pages, news targeting, document management, executive communications. The requirement was substantial but not exotic.
The conventional recommendation was straightforward: license a well-known intranet solution and deploy it. The product was mature, well-reviewed, and widely used. The problem was the math. At the organization's user count, the annual licensing cost landed near $100,000 per year — recurring, indefinitely.
The Zenpo consulting team proposed an alternative. Build a bespoke SPFx intranet using modern SharePoint development practices. No proprietary platform dependencies. No recurring per-user license fees. The estimated build timeline: approximately three months. The build cost was a fraction of what three years of licensing would total.
The team delivered. The intranet launched on time, built entirely on SPFx and modern SharePoint infrastructure. Because the solution was built on supported, modern frameworks rather than legacy approaches, it has remained stable through SharePoint updates with minimal maintenance. No $100,000 annual renewal. No vendor dependency for feature requests. The organization owns its intranet outright.
This is a case where the Solution Hierarchy correctly advanced to Tier 3. The marketplace product existed and was evaluated (Tier 2). It was not rejected on capability — it was rejected on TCO at scale. The 3–5 year cost comparison made the build decision defensible, and the execution team had the SharePoint expertise to deliver and maintain the result.
The key lesson: build decisions are valid when the TCO analysis supports them and the team can sustain the result. The danger is making the same decision without running the analysis or without the team to back it up.
Scenario C: Project Kanban — OOTB Wins Retroactively
A federal agency's internal development team built a custom Agile task board in SPFx. The board featured drag-and-drop cards, swimlanes by sprint, color-coded priority indicators, and integration with SharePoint task lists. It was a solid piece of engineering. It took five months to build and represented a meaningful investment in developer time.
At the time of development, AppSource offered at least three commercially supported Kanban-style web parts that would have addressed the core requirement. The team did not evaluate them. The institutional assumption was that custom builds were more capable and more secure than third-party products — an assumption that was never tested against the actual marketplace offerings.
Two years later, Microsoft shipped native board views in Microsoft Lists and significantly improved Planner's integration with Teams and SharePoint. The custom board was suddenly competing with free, integrated, automatically-updated native functionality. The custom solution still worked — but maintaining it now required justifying ongoing developer hours for a capability the platform provided natively.
The agency did not decommission the custom board immediately. Sunk cost and internal politics kept it alive for another year. When it was finally retired, the total investment — build, maintain, retire — significantly exceeded what a marketplace product would have cost over the same period, and the marketplace product would have eventually been retired gracefully when OOTB caught up.
Measuring the Decision
The Solution Hierarchy does not end at the initial decision. The choice must be measured over time to validate whether it delivered the expected value — and to trigger re-evaluation when conditions change.
TCO Tracking at 1, 3, and 5 Years
At year one, compare actual costs against the projected TCO from the initial evaluation. Custom builds should track: developer hours for maintenance, hours spent on SharePoint compatibility testing, and any unplanned rework. Marketplace products should track: actual license renewals, configuration change requests, and any customization or integration work beyond the original deployment. OOTB configurations should track: Power Automate flow maintenance, governance overhead, and any workaround labor that compensates for OOTB limitations.
At year three and year five, re-run the comparison. Has the marketplace product raised prices significantly? Has the custom build required more maintenance than projected? Has Microsoft shipped native functionality that makes the original decision moot?
Time to First Productive Use
How long after the decision was the solution in the hands of actual users? This metric penalizes over-scoped custom builds and rewards marketplace products and OOTB configurations that deliver value quickly. It also surfaces a common anti-pattern: the "perfect solution" build that takes so long to deliver that users have already found workarounds, reducing adoption when the solution finally ships.
Maintenance Hours Per Quarter
Track the ongoing labor cost of keeping the solution operational. This is the metric that most reliably distinguishes well-made decisions from expensive mistakes. Marketplace products and OOTB configurations should generate near-zero maintenance hours. Custom builds should be tracked honestly — including the hours that developers spend on compatibility fixes, user-reported bugs, and feature requests that were not in the original scope.
Upgrade Survivability
Did the solution survive the last major SharePoint update without intervention? Custom builds that require emergency patching after platform updates are signaling that maintenance burden is higher than projected. Track these events and factor them into future TCO estimates for similar decisions.
Spotting Red Flags in Proposals and Teams
The Solution Hierarchy also functions as a diagnostic tool for evaluating consulting proposals and internal team recommendations. Several patterns reliably predict that the decision process has been short-circuited:
The InfoPath cult. A team or consultant whose default recommendation is InfoPath (or its spiritual successor, a complex Power Apps form that replicates InfoPath behavior). InfoPath has been deprecated. Recommending it signals that the advisor is working from a mental model that expired years ago. Any proposal that leads with InfoPath should be treated as a red flag for broader decision-making currency.
The SPFx cult. A consulting firm whose answer to every SharePoint gap is a custom SPFx web part. SPFx is a powerful framework, and custom builds are sometimes the right answer. But when every proposal from a firm is a build proposal, the incentive structure — not the requirement — is driving the recommendation. Ask whether marketplace alternatives were evaluated. If the answer is vague or dismissive, the proposal is optimizing for billable hours, not for the client's outcome.
The PowerApps cult. An internal team or consultant that routes every requirement through Power Apps and Power Automate, regardless of complexity. Power Platform is a configuration-tier tool. It is excellent for lightweight forms, simple workflows, and rapid prototyping. It is not a substitute for proper SPFx development when the requirement demands it, and it is not a substitute for a marketplace product when one already exists. The tell: a Power Apps solution that requires premium connectors, multiple custom connectors, and a complex Dataverse schema to approximate what a $5,000 annual marketplace product delivers natively.
The OOTB absolutist. The inverse failure. An IT team or policy that forbids all third-party products and all custom code, insisting that every requirement must be met with native M365 capabilities. This posture sounds fiscally responsible. In practice, it produces elaborate workarounds — complex Power Automate flows, SharePoint list configurations pushed past their design limits, user-facing compromises that reduce adoption — that cost more in labor and frustration than a targeted marketplace purchase or a modest custom build would have.
The healthy signal is a team or consultant who evaluates all three tiers honestly, documents why they recommend the tier they recommend, and can articulate the trade-offs of the alternatives. That is Solution Hierarchy thinking in practice.
Summary and Key Takeaways
The buy-vs-build decision in SharePoint is a three-option evaluation, not a binary choice. Organizations that skip the middle tier — marketplace products — consistently over-spend on either unnecessary licenses or unnecessary custom code.
The Solution Hierarchy provides the decision structure: Configure first (exhaust OOTB M365 capabilities), Buy second (evaluate AppSource and Azure Marketplace products), Build last (custom SPFx or Azure-backed development only when the first two tiers have been honestly evaluated and documented as insufficient).
Each tier transition has an explicit gate. The gate from Configure to Buy is a documented functional gap that OOTB cannot address. The gate from Buy to Build is a documented evaluation of marketplace products showing insufficient fit or unfavorable TCO at scale.
Total cost of ownership over 3–5 years is the correct lens — not initial license or development cost. Custom software maintenance typically consumes 60% to 90% of total lifecycle cost. Marketplace products externalize that maintenance to the vendor. OOTB configurations externalize it to Microsoft.
Hybrid approaches — a marketplace product covering 70–80% of the requirement plus a targeted custom integration for the rest — frequently deliver the best balance of cost, speed, and maintainability.
Re-evaluate the decision at regular intervals. Platform evolution, vendor pricing changes, and shifting organizational requirements can all invalidate the original choice. The Solution Hierarchy is not a one-time exercise. It is an ongoing discipline.