Build vs Buy Integration Infrastructure in EdTech

Why EdTech teams are making high-stakes integration decisions right now

The build-vs-buy decision on integration infrastructure is not an engineering question. It is a business question with a compounding cost structure, and EdTech teams that treat it as the former consistently arrive at the wrong answer. For most teams, buying managed integration infrastructure and layering custom logic on top is the faster, lower-risk path to shipping integrations at the speed the market now demands.

EdTech is no longer speculative. System leaders stopped evaluating novelty some time ago; they are now evaluating durable operational value, and that shift changes what they expect from the vendors they procure. The integration question has become a prerequisite to the sales conversation, not a post-signature implementation detail.

U.S. EdTech revenue sits at roughly $187 billion in 2025, projected toward $348 billion by 2030. The more telling signal is the procurement dynamic those numbers reflect: more platforms, more institutions, more systems administrators who will ask whether your product connects to their existing stack before they let you past the pilot stage. Every new customer brings its own SIS, its own LMS, its own authentication model. The decision compounds. It is not made once.

How many systems EdTech products actually need to connect to

Most product teams underestimate the integration surface area the first time they sit down to scope it. Not by a small margin.

Data from the 2024-2025 school year suggests the average U.S. K-12 district was running around 2,500 distinct EdTech products; typical higher education institutions maintained upward of 900 active software applications. Every institution a vendor sells into brings its own SIS, whether PowerSchool, Infinite Campus, Skyward, or any number of smaller regional platforms, along with its own LMS and its own approach to identity and authentication. These are not interchangeable. Each has its own data schema, its own update cadence, its own failure signature, and its own set of behaviors that don't appear in any documentation until something breaks in production.

SIS platforms relying on outdated batch syncs routinely produce delays in user updates, grade reporting, and student engagement visibility. The downstream effects are concrete: rosters that don't reflect current enrollment, grade passback that lags actual assessments, authentication states that won't resolve cleanly. This is the norm, not the exception.

Teams that commit to a build approach and then discover, two or three integrations in, that the total number of systems their customers actually use is far larger than anyone mapped in the planning phase: that is where the cost structure of the decision begins to expose itself. The integration surface is not two or three systems. It is potentially dozens, each demanding ongoing attention, and each carrying the kind of behavior that only surfaces under production load.

The standards layer that governs what EdTech integrations must do

EdTech integrations don't operate in a permissionless environment, and the compliance surface is meaningfully more complex than it was even five years ago.

The 1EdTech Consortium, formerly IMS Global, maintains the dominant interoperability standards: LTI and LTI Advantage, OneRoster, and Caliper Analytics. LTI 1.3 handles secure tool-to-LMS connections using OpenID Connect, built on OAuth 2.0 and JSON Web Tokens. OneRoster defines how roster data moves between SIS, LMS, and EdTech platforms in a common format. The Ed-Fi Data Standard has been adopted by more than 25 U.S. states and is not optional for vendors operating in those markets.

LTI Advantage and OneRoster certifications have become prerequisites for enterprise sales to large school districts and universities. A team cannot ship a connector and declare compliance. Certification requires 1EdTech membership and a formal conformance process involving scheduled testing, documentation, and renewal obligations that run on the consortium's timeline, not the vendor's sprint cycle.

FERPA constrains which student data fields can be shared and with whom, making interoperability a compliance obligation rather than a purely technical matter. More than 121 state student privacy laws now layer on top of FERPA. K-12 vendors face disqualification from district procurement in 2026 if they cannot demonstrate code-level compliance controls. Self-attestation no longer passes scrutiny in most state procurement processes; auditors are asking to see the controls themselves.

Any team building custom integration infrastructure must implement, maintain, and certify against this entire standards stack. Standards evolve, states add requirements, and certification processes carry their own renewal cycles. The compliance surface does not hold still, and it does not wait for the next sprint.

What building custom integration infrastructure actually costs EdTech engineering teams

Building a custom enterprise integration platform typically costs between $400,000 and $1,200,000 in year one, accounting for developer salaries, infrastructure, security, testing, and documentation. Annual maintenance runs between $150,000 and $400,000 per year thereafter. Initial development represents roughly 30 to 40 percent of total cost of ownership; maintenance, updates, and adaptations account for the remaining 60 to 70 percent, consistent with Forrester's analysis of software development TCO. McKinsey's research on large IT projects found that they run approximately 45 percent over budget and 7 percent over schedule, delivering 56 percent less value than predicted.

The maintenance burden is where cost accumulates most insidiously. Every third-party API change, every LTI version update, every SIS a new customer brings requires engineering time that compounds against every previous commitment. Security review cycles add further cost: a new connector may trigger an internal review, a customer-side security review, or both before it can reach production. That time is rarely budgeted. It comes out of capacity that was supposed to be building the product.

Most enterprise IT leaders who run a full three-year TCO comparison find the build option is five to ten times more expensive than managed alternatives over that period. The problem is that the ratio only becomes visible once you do the full accounting, and most teams skip it. That is precisely why so many of them hit the infrastructure ceiling.

Building is correct when the integration itself is the core differentiator. A proprietary adaptive scoring model, a custom competency progression system, a tutor-matching algorithm that no existing connector touches: these justify the cost because the integration is the product. The argument against building applies specifically to commodity connectivity.

The infrastructure ceiling that appears after early traction

There is a consistent pattern here, consistent enough to treat as predictable. A product gains traction. Infrastructure limitations become visible. The team faces a choice between growing slowly under constraints or undertaking an expensive, disruptive rebuild.

The ceiling doesn't appear at founding. It appears after the product has demonstrated market fit, which is the worst possible moment to redirect engineering capacity away from the product itself. An internal API designed to serve the product's own frontend is not built for external consumption; it requires significant redesign when the business model starts demanding marketplace distribution or district-level enterprise deals. As integration requirements accumulate, the maintenance backlog compounds while the sales team waits months for new connectors. Institutions that have migrated to cloud interoperability platforms have reported roughly 40 percent improvements in time-to-integration for new EdTech applications. A vendor that cannot connect in weeks gets passed over for one that can. The backlog becomes a sales problem faster than most engineering teams expect, and by the time it registers as one, pipeline has already walked.

The security dimension is not theoretical. More than 1.8 million students have been affected by data breaches since 2020, and educational institutions face a relentless volume of cyberattack attempts each week. A homegrown connector with deferred security maintenance is exposure the vendor owns outright. When a breach occurs through a poorly maintained integration point, the vendor is accountable to the district, to FERPA, and to the state privacy laws that now require code-level controls. That accountability has materialized for vendors repeatedly, and it will continue to.

What managed integration infrastructure actually offloads and where it falls short

Managed integration infrastructure, delivered through iPaaS platforms, offloads API update maintenance, security patching, infrastructure monitoring, and connector upkeep. The education iPaaS segment was estimated at roughly $1.21 billion in 2025, projected to reach $15.5 billion by 2034. What that trajectory reflects is a broad recognition that maintaining integration infrastructure is expensive, grinding work that almost never differentiates a product.

The cost comparison is direct. A managed iPaaS platform typically costs between $15,000 and $60,000 annually for coverage that would cost $400,000 to $1,200,000 to build in year one. Modern platforms fall into three broad categories: embedded iPaaS, which offers visual workflow builders for business users; unified APIs, which provide normalized schemas and broad connector coverage; and deep integration infrastructure, which supports declarative frameworks, custom field mapping, and enterprise-scale operations.

The limitations deserve equal attention. Embedded iPaaS works for workflow automation but lacks the depth required for complex product integrations. Unified APIs accelerate development but impose standardized schemas that will not accommodate custom field requirements. Vendor lock-in is a genuine risk: integration logic trapped in a proprietary visual domain-specific language cannot be version-controlled in Git, run locally, or migrated without rewriting every workflow. Before committing to a managed platform, a team needs to verify whether the platform actually supports the specific SIS connectors, LTI flows, and OneRoster schemas their customers use, not whether it claims broad coverage. Many teams discover that gap only after signing a contract.

Why most EdTech teams end up combining managed infrastructure with custom logic

Pure build and pure buy each leave gaps. In practice, most EdTech teams arrive at a hybrid: buying commercial integration infrastructure for the commodity connectivity work and building custom logic on top of the platform's scripting or extension layer for the parts that actually differentiate the product.

Low-code integration now represents approximately 42 percent of new platform adoptions, a figure that reflects how broadly developers have accepted managed infrastructure as a base layer rather than treating it as a compromise. Roughly 80 percent of enterprises still build integrations internally to some degree, while 29 percent have adopted embedded iPaaS and 24 percent rely on unified APIs. The overlap in those figures reflects genuine multi-strategy adoption.

For EdTech specifically, the allocation logic becomes clear once you have worked through it. Standards-mandated connectors, OneRoster, LTI Advantage, Ed-Fi, are strong candidates for managed infrastructure because they are commodity connectivity that every customer needs and that must be maintained against evolving certification requirements. Nobody's sales cycle is won because the OneRoster connector is homegrown. Proprietary curriculum logic, adaptive scoring, custom data models: those are where custom development earns its cost, because those integrations are the product's actual value proposition.

The consolidation wave in EdTech confirms which direction institutional buyers and capital allocators are moving. Bain Capital's $5.6 billion acquisition of PowerSchool and KKR's $4.8 billion purchase of Instructure signal that tightly integrated, operationally unified stacks are what the market rewards. Features alone stopped being sufficient some time ago.

How to apply the build-vs-buy test to a specific EdTech integration decision

The core question is whether this integration logic differentiates the product or merely connects it to something every customer already has.

Build when the workflow, algorithm, or data model is the product's core value proposition and no existing platform supports it. A proprietary competency-based progression model, an adaptive item response scoring engine, a custom tutor-matching system: these warrant the cost and commitment of custom development. They are what the product is.

Buy when the integration is commodity connectivity. Syncing enrollments via OneRoster, launching tools via LTI 1.3, passing grades back to a SIS: these are solved problems. Treating them as engineering opportunities carries a cost the market will not reward.

Two observable conditions should drive the decision. First, the time-to-market signal: if a district or university sales cycle is moving faster than the connector backlog, the build path is costing pipeline. That is measurable. Second, the compliance signal: if the team cannot demonstrate code-level FERPA and state privacy compliance controls on every connector, not policy documents but actual controls, managed infrastructure with built-in compliance maintenance directly reduces that exposure.

Before committing either way, run the three-year TCO calculation: year-one build cost plus annual maintenance set against the managed platform cost. The gap is typically large enough to change the decision. Skipping that calculation is how teams arrive at the infrastructure ceiling.

Teams that start with managed infrastructure to ship quickly can build custom connectors later when a specific integration genuinely requires it. Rebuilding after hitting a custom ceiling is more expensive, more disruptive, and it almost always arrives at precisely the wrong moment in the company's growth. Start with managed, build where it matters, and revisit deliberately rather than reactively.