Going Digital? The Build-or-Buy Decision in 2026

Jun 11

What educational curriculum publishers need to know before they decide…

At some point in the process of going digital, nearly every educational curriculum publisher faces the same question: should we own the code ourselves? Build or buy.

This article is written for curriculum companies — publishers who have built their value in content, pedagogy, and learning design, and are now building or expanding a digital product. Not infrastructure companies. Not LMS providers. If your asset is curriculum and your question is whether to own the pipes that deliver it, read on.

It's usually not really about code. It's about risk — the risk of dependency, of being locked in, of losing control of something you've spent years building. But here's the distinction that matters: your content is your asset. The platform infrastructure underneath it is just the pipes. Pursuing ownership of the pipes is expensive in engineering resources, operational overhead, and strategic focus. And it's a distraction — because you already own the thing that actually matters.

Reason 1: "If we want to be acquired, we need to own the code."

The concern underneath: valuation. Acquirers will discount us — or walk away — if our product runs on someone else's platform.

Why it doesn't hold: Acquirers of educational publishers are buying curriculum, brand, specific product lines, customer relationships, and recurring revenue. There are acquisitions where the technology itself is the asset — but those are infrastructure and platform deals. Recent edtech M&A bears this out: Leeds Equity Partners acquired TouchMath for its K-8 math curriculum; IXL Learning acquired Carson Dellosa for its classroom materials; Archer Review acquired OnlineMedEd for its medical education curriculum. In each case, the asset was the content and the customer base, not the codebase. For curriculum publishers, the codebase is not the prize. A well-structured platform relationship often looks better in due diligence than a homegrown system — lower technical debt, documented compliance, predictable costs, and a team that hasn't been consumed by engineering overhead. What sophisticated acquirers flag isn't platform dependency; it's undocumented dependency. If a curriculum company is being acquired, it's typically because someone sees growth potential — which means the platform it runs on will need to scale. Acquirers will look hard at whether the infrastructure can handle that. A purpose-built platform with an established track record answers that question.

What actually protects you: Clear content ownership language. Data portability. Clear exit terms. An acquirer's counsel will ask exactly these questions — and a well-structured platform agreement answers all of them. What you want going into a sale isn't a codebase. It's a clean cap table for your content and your customer relationships, with no surprises buried in your vendor contracts.

Reason 2: "If we own it, we control our destiny — and we can never be locked in."

The concern underneath: dependency. We don't want our future in someone else's hands, and once we commit, we can't get out.

Why it doesn't hold: Owning the code doesn't free you from dependency — it just changes who you depend on. Your custom platform still runs on cloud providers, browsers, LMS APIs, identity systems, and standards frameworks you don't control. You'd own the layer in the middle while remaining dependent on everything above and below it — and carrying the full cost of keeping pace with all of it, forever. Lock-in works the same way. Publishers who build their own platforms get locked into the architectural decisions their team made five years ago, the developers who know how it works, and the cost of replacing it once it's embedded in every workflow. Owning code doesn't prevent lock-in. The constraints just look different.

What actually protects you: Ownership of the asset — your content, your brand, your customer relationships, your outcomes data — combined with a platform relationship structured so you're never trapped. Contractual data portability. Clear exit terms. Control of your destiny comes from those provisions, not from a codebase you'd have to maintain.

Reason 3: "But we may need specific features that aren't on the platform."

The concern underneath: being stuck on someone else's roadmap. Our curriculum has specific needs that a generic platform may never prioritize.

Why it doesn't hold: Building your own platform to solve a feature gap trades one constraint for another. You gain flexibility — and take on the full responsibility that comes with it. Authentication flows, accessibility compliance, standards updates, browser compatibility, mobile optimization — all yours, forever. Publishers who go down this road consistently find that engineering overhead consumed the resources they were trying to free up for curriculum. The choice also isn't binary. The best platforms aren't monoliths — they're enterprise-grade systems that cover the vast majority of what you need and are designed to accommodate the rest.

What actually protects you: Look for purpose-built software designed specifically for your use case — not a platform repurposed from another industry and adapted to fit education. A platform built for educational publishers puts your needs at the center, not as edge cases competing with larger enterprise customers. Standards alignment, tiered content delivery, teacher and student role separation, outcomes reporting should be core, not afterthoughts. And for what's specific to your curriculum or workflows, the right vendor offers two paths: the platform team can build it with you, or your own developers can build on the platform. It should be designed to facilitate customization either way — not lock you out.

Reason 4: "Our content — and our student data — can't live on someone else's infrastructure."

The concern underneath: two distinct issues. Content exposure: if our IP sits on someone else's servers, what stops them from using or sharing it? And regulatory risk: student data is sensitive, FERPA and COPPA exposure is real, and if something goes wrong, our name is on it.

Why it doesn't hold: Neither is resolved by owning the infrastructure. Your content already traverses systems you don't own — CDNs, browsers, cloud networks. What protects it is who has access, what they're contractually prohibited from doing, and how it's structured technically. The same logic applies to student data.

What actually protects you: For content: a vendor agreement that explicitly restricts the platform from using, analyzing, or sublicensing your IP, combined with architecture that keeps your content isolated and audit rights to verify it. For student data: the platform should practice strict data minimization — collecting only what's necessary to authenticate a session. No behavioral profiles, no ad targeting, no PII beyond what a login requires. Less data held is less data exposed. Documented FERPA and COPPA compliance and clear data processing agreements provide structural protection, not just policy promises.

Reason 5: "Building it ourselves will be cheaper in the long run."

The concern underneath: cost. Platform fees compound. If we own it, we stop paying forever.

Why it doesn't hold: The total cost of ownership for a custom platform is almost always underestimated. The build is expensive. Maintenance is expensive. Compliance — FERPA, COPPA, WCAG, state privacy laws, standards updates — is expensive and never stops. By 2026, regulatory compliance in edtech is no longer a differentiator — it's a baseline requirement, and the landscape keeps shifting. COPPA was significantly updated in 2025, adding new consent requirements and data retention limits. State privacy laws now number over 120. Security audits are expensive. The talent to keep it current is expensive and hard to retain. The platform fees publishers try to escape represent real, ongoing work — compliance updates, security maintenance, infrastructure management, standards changes. That work doesn't disappear; it simply moves in-house, often at greater cost and complexity than anticipated.

What actually protects you: Transparent, predictable pricing that doesn't punish your growth. A platform that absorbs the compliance and maintenance burden so your team can focus on content. The ongoing cost of someone else staying current with a fast-moving technical landscape so you don't have to.

What actually protects you — the full list.

Here's what to ask for instead of ownership:

Content ownership language: explicit contractual statement that your IP remains yours and the platform has no right to use it
Data portability: your outcomes data, exportable when you need it
Clear exit terms: defined operational terms for what happens if you leave — timelines, handoff processes
Compliance documentation: SOC 2, FERPA, COPPA, WCAG, state privacy laws — current certifications, not promises
Data minimization: a platform that takes only what it needs to run a session and nothing more
Pricing transparency: no opaque tiers, no surprise fees at renewal, predictable cost as you scale
Customization access: the ability to build what's specific to you — with platform support, not a wall

Content2Classroom is built on the belief that platform protection, not platform ownership, is what publishers actually need — and that a platform earns its place by making these guarantees, not by making you dependent. The goal isn't to lock you in. It's to be the partner you keep choosing, because leaving is always possible and staying is always worth it.

Own your content. Own your results. Own your relationships. Let the infrastructure be something you're protected by — not something you're burdened with.

Sources

Jackim Woods & Co., Acquisitions in the Education and EdTech Sectors in 2024 (November 2024)
Jackim Woods & Co., Education & EdTech Sector Acquisitions: Latest M&A Trends (2025)
The SOC 2, EdTech Compliance 2026: FERPA, COPPA, and SOC 2 Requirements Explained (April 2026)
Secure Privacy, Privacy Software for Schools: Student Data Compliance (January 2026)
Hireplicity, FERPA, COPPA & SOC 2 for EdTech: Compliance Guide for EdTech CTOs (February 2026)
Binary Marvels, Custom SaaS vs Off-the-Shelf Software: Pros and Cons (2026)
APIPilot, Total Cost of Ownership for Custom Software: The 2026 Strategic Guide (2026)