A video about replacing streaming subscriptions with a home server recently crossed my feed, and I haven’t been able to stop thinking about how cleanly its argument maps onto educational technology. The creator, Jeff from the channel Dammit Jeff, spent a year documenting his process of detaching from cloud services by building his own home server. His core thesis is straightforward: convenience became dependence, and dependence became leverage. Companies offered generous free tiers to get users invested, then gradually raised prices, removed features, and changed terms of service once leaving felt harder than staying. If you work in education, that pattern should sound familiar.

The Bait-and-Switch We Already Know

Jeff’s examples are consumer-facing. Google Photos offered unlimited storage, built years of user investment, then capped it and started charging. Disney Plus launched at seven dollars a month, and now the ad-free version costs nearly three times that. The playbook is consistent: make adoption easy, let dependency build, then monetize.

In EdTech, the mechanics are similar but the stakes are different. When a streaming service raises prices, a consumer loses access to entertainment. When an educational platform changes its terms, entire instructional programs can be disrupted. And unlike a personal photo library, school data lives under FERPA, IDEA, and state privacy laws, which means the cost of a bad transition isn’t just inconvenience but compliance risk.

I watched this play out with a friend’s organization a few years ago. They had adopted Canvas LMS and invested significant time getting their instructors trained, their course shells built, and their workflows established. After a few years, they realized the platform was more than they actually needed, and that a simpler, less expensive tool would have served them better. But by that point, the switching costs were steep. Canvas is fully open source under the AGPLv3 license, and you can export course content, access the entire codebase, and even self-host the platform if you have the technical capacity. That part wasn’t the problem so much as everything else: retraining users, rebuilding workflows, and accepting that exported course content would still need heavy editing to fit into a different system. The technical and legal exit was available, but the organizational one was painful.

I want to be clear that I’m a genuine advocate for Canvas over most comparable LMS platforms at its price point. I administer it statewide and I think it does a lot of things well. But even with a product I believe in, it’s worth being honest about the fact that the company’s business model depends on retention. They want to keep you around, paying hosting fees year after year. That isn’t a criticism unique to Instructure; it’s simply how subscription software works. The question is whether we account for that reality when we adopt these tools, or whether we discover it only when we try to leave.

Where does the homelab analogy hold?

Jeff’s response to the dependency problem is to self-host: run your own server at home, store your own files, manage your own media library. He isn’t suggesting that everyone abandon cloud services overnight. His framing is incremental: 1) start with an old laptop, 2) add storage when you can, and 3) replace one service at a time. The goal isn’t total independence but reducing the leverage that any single company holds over your digital life.

That incremental framing translates well to education, even if the specific technology doesn’t. Most schools aren’t going to run their own LMS on a server in the IT closet. But the underlying principle of reducing single-vendor dependency, building portable skills and content, and understanding where your data actually lives is something every education professional can apply regardless of their technical comfort level.

One thing Jeff says toward the end of the video stuck with me. He argues that showing people how to modify and reuse their devices on their own terms, rather than a company’s terms, is a political stance. He’s right, and the same is true in education. When we choose platforms, configure tools, and design data workflows for students and teachers, those aren’t neutral technical decisions. They carry embedded assumptions about who controls the learning environment, who has access to the data, and whose interests the system ultimately serves. Whether we acknowledge those assumptions or not, they shape the experience.

Where It Gets Complicated

The analogy between consumer self-hosting and educational technology has real limits, and it would be irresponsible to gloss over them.

Schools aren’t individual consumers making choices about their own data. They’re institutions responsible for other people’s children, operating under legal frameworks that dictate how student information is handled. A teacher can’t just spin up an open-source alternative to a district-approved platform without navigating compliance, security review, and institutional buy-in. The barrier to “doing it yourself” in education isn’t just technical skill; it’s governance.

There’s also a resource reality that deserves honest acknowledgment. Jeff’s audience has the time and inclination to tinker with hardware and software as a hobby. Teachers and administrators are already stretched thin. The suggestion that educators should build their own tools can land as tone-deaf if it isn’t framed carefully. The districts I work with across the Great Plains often have one person filling multiple technology roles, limited bandwidth (both literal and figurative), and budgets that leave little room for experimentation.

That said, there’s a meaningful middle ground between full vendor dependency and building everything from scratch. Lightweight, open-source tools that run within existing ecosystems (like Google Workspace) can provide real alternatives without requiring a server rack in the closet. Designing course content in portable formats, maintaining local backups of critical resources, and choosing tools with clear export pathways are all practical steps that reduce dependency without demanding a complete infrastructure overhaul.

What Education Professionals Can Take from This

The most valuable takeaway from Jeff’s video isn’t a technical one but a habit of mind: before adopting any tool or platform, ask what leaving looks like. What does the export process involve? Who owns the content we create inside this system? What happens to our data if the company changes direction, raises prices, or shuts down? These aren’t paranoid questions but basic due diligence that too often gets skipped in the excitement of a new adoption.

For technology coordinators and administrators, this means building exit awareness into the evaluation process. When a vendor presents their platform, ask about data portability alongside features. When a tool is offered for free, consider what the business model actually is and what changes when the free period ends.

For instructional designers and curriculum leads, it means thinking about content portability from the start. If the lessons, assessments, and media you create are deeply entwined with a single platform’s proprietary features, you’re building on rented land. That might be an acceptable trade-off for the functionality you gain, but it should be a conscious choice, not an accidental one.

For classroom teachers, the immediate takeaway is smaller but still meaningful. Understanding where your materials live, keeping local copies of important resources, and building familiarity with open formats gives you options that a purely cloud-dependent workflow doesn’t. You don’t need to become a systems administrator, only to know that the question “what if this goes away?” has an answer.

Asking it of my own work

Jeff ends his video by acknowledging that completely removing all external services from your life isn’t realistic. The point isn’t total self-sufficiency but having choices, and making those choices deliberately rather than discovering your dependencies only when someone else decides to change the terms.

In education, we’re often so focused on adoption that we underinvest in thinking about what happens after adoption. The conversations about which LMS to choose, which assessment platform to implement, which communication tool to standardize tend to center on features, cost, and ease of onboarding. Those are important considerations. But they’re incomplete without a parallel conversation about what the long-term relationship with that vendor actually looks like, and what our options are if that relationship needs to change.

I should put the same question to the platform I run. If the statewide Canvas instance I administer had to go away, the content would come out and the code is open, so the part I’m least sure we could carry is everything else: the trained instructors, the workflows, and the habits that have grown up around one platform’s way of doing things. That’s the same organizational exit my friend’s team ran into, and I’ve spent a fair amount of my own time building exactly that kind of attachment. I don’t think that makes the adoption a mistake, but it’s an answer the people who depend on the instance should hear before they need it rather than after.

If any of this resonates, or if you have your own story about navigating platform dependency in your school or organization, I would love to hear about it. You can reach me at licht.education@gmail.com or find more articles and resources at bradylicht.com.