In a recent article, I wrote about the ethics of building automation tools for educators, using Mary Doria Russell’s concept of the “vulture,” a freelance analyst who maps a worker’s expertise so machines can take over parts of it. That piece ended with what I still think is the right distinction: the best version of this story is the one where educators automate their own work, on their own terms, rather than having it done to them by someone else. Self-elected automation, where the person doing the work decides what to encode and what to keep, is fundamentally different from imposed automation, even when the tools are identical.

What I didn’t address in that piece is the question that’s been pressing on me since: who pays for it?

A colleague and I have been going out of our way to share some of the small automation tools we’ve been building with Google Apps Script and AI assistance. The tools are simple by commercial software standards: chatbots that answer frequently asked questions from a curated knowledge base, scripts that generate documents from spreadsheet data, automations that handle repetitive scheduling and communication tasks. The kind of thing that saves someone a few hours a week on work they were doing by hand.

Interest has been growing, and I’ve noticed a pattern in how people respond.

Administrators tend to get excited quickly. They see efficiency, cost savings, the ability to do more with existing staff. They want to know how fast the tools can be deployed and what else might be possible. The energy in those conversations is forward-leaning, optimistic, ready to scale.

The people whose work the tools actually touch react differently. When I’ve talked with administrative staff, instructional coaches, and other support roles about these kinds of automations, the initial response is often cautious. Sometimes openly guarded. And when I pay attention to what’s underneath that caution, it usually isn’t resistance to technology or fear of change in some abstract sense. It’s a very specific concern: if someone else builds a tool that does part of my job, what happens to my job?

I had a conversation recently that crystallized this for me. I was explaining one of the tools to someone in an administrative support role, someone whose daily work involves a lot of the exact tasks these tools are designed to handle. The more I talked about what the tool could do, the quieter she got. It wasn’t until I shifted the conversation, explaining not what the tool could do for her but how she could learn to build and maintain something like it herself, that her posture changed entirely. She went from guarded to genuinely interested the moment the framing moved from “here’s a tool someone made for you” to “here’s something you could learn to make yourself.”

The distinction mattered to her for a reason I should have anticipated but almost missed: if she builds and maintains the tool, she’s the person who understands it. She’s more valuable to the organization, not less. Someone can’t walk in the next day, hand the tool to a replacement, and expect it to run on its own. Her knowledge is still in the loop. But if someone else builds it and hands it to her supervisor, the tool exists independent of her, and that changes her position entirely.

This is the same dynamic I explored in the vultures piece, showing up in a new form. There, the question was who controls the automation process. Here, it’s the next question in the sequence: when you figure out how to build something useful, how do you sustain that work financially without recreating the power imbalances you set out to avoid?

The Uncomfortable Part

I need to be honest about something before going further. Right now, I give these tools away. They’re published on my website under Creative Commons licensing, with setup guides, documentation, and the full source code. Anyone can copy them, modify them, and use them however they want. I believe in that approach, and it’s consistent with how I think educational technology should work.

It’s also not sustainable. The tools take real time and effort to build, test, document, and support. The knowledge required to identify the right problems to solve and to architect tools that are simple enough for non-technical users to maintain, that didn’t appear overnight. It came from years of working in schools, building things that didn’t work, and iterating toward things that did. The AI assistance that speeds up the coding doesn’t replace any of that. It just means the bottleneck has shifted from writing the code to knowing what to build and why.

At some point, if this work is going to continue and grow, someone has to pay for it. And the way that payment gets structured isn’t a neutral, technical decision. It’s an ethical one that determines who benefits, who depends on whom, and whether the people on the ground end up more empowered or more vulnerable.

A Spectrum of Models

There are more ways to monetize educational technology than most people realize, and they distribute power very differently. It’s worth walking through the ones most relevant to what I’m wrestling with, because the choice between them isn’t just about revenue. It’s about what kind of relationship you’re building with the people who use what you make.

Giving it away is the model I know best, and the one I’m most philosophically comfortable with. Robin Wall Kimmerer’s writing on gift economies has influenced how I think about professional development, and there’s a version of this that works: you lead with value, you build trust and community, and the relationships that form around the work create opportunities down the line. The problem is that “opportunities down the line” is not a budget line item. The tools still take time to build and maintain, and good will doesn’t pay for the labor involved. The gift economy model works as a starting point and as a value commitment, but as a primary business model, it asks the builder to subsidize everyone else’s benefit with their own time indefinitely.

Open-source tools with paid services is the model I keep coming back to. The idea is straightforward: the tool itself stays free. The code is open, the documentation is public, anyone can set it up on their own. But if a school district wants someone to handle the initial setup, customize the tool for their specific context, provide training, or maintain and expand it over time, they pay for that labor. This is essentially what companies like Red Hat proved could work in the broader software world, though at a vastly different scale. What I find ethically appealing about this model is that the district is never locked in. If they decide to stop paying for support and maintain the tool themselves, or hire someone else to do it, they can. The tool doesn’t disappear. Their data doesn’t become inaccessible. The power stays distributed.

This model also has a natural alignment with what service cooperatives already do. Cooperatives exist to provide expertise and support to their member organizations, not to sell products back to them. Framing the revenue as payment for professional services rather than product licensing keeps the relationship in familiar territory for everyone involved.

Selling a configured product is a middle ground that I think deserves more consideration than it usually gets. In this version, the core tool is still open-source, but you also offer a “ready to go” version that’s been customized, tested, and configured for a specific district’s needs. The district pays once for the labor that went into making it work for them. They own their version outright. There’s no subscription, no ongoing dependency. They can optionally pay for continued support, but nothing breaks if they don’t.

The tension here is subtle but real. The moment you sell something, even if the underlying code is freely available, you’ve created an expectation of a product relationship. The district starts thinking of you as a vendor. And vendor relationships in education come with baggage: procurement processes, support tickets, the assumption that updates will keep coming. You can structure the agreement to be clear about what’s included and what isn’t, but the relational shift is harder to manage than the contractual one.

The subscription model is what dominates the EdTech landscape, and it’s worth naming why, even though it’s not a model I’d choose. Subscriptions create predictable revenue, which is attractive for obvious reasons. But they also create dependency by design. When the tool lives on someone else’s servers, when the data is stored in their systems, when the features you rely on can change or disappear with a pricing tier update, the power sits entirely with the provider. Districts pay not for a product they own but for continued access to a product someone else controls. I’ve written about the costs of this approach elsewhere, but the short version is that it treats schools as recurring revenue sources rather than as partners, and it makes the switching costs high enough that districts stay even when the tool stops serving them well.

The consulting extraction model is the dystopian scenario from the vultures piece, applied directly to monetization. An outside firm comes in, maps processes, builds automation, and charges the district for the resulting efficiency gains. This is Sofia Mendes arriving at Arecibo, except now the institution is also paying for the privilege of having its workers’ knowledge extracted. The workers whose knowledge informed the tools don’t own anything. The firm walks away with the intellectual property and the revenue. The district gets a tool it may not fully understand, maintained by people who don’t work there. And the ground-level staff are left wondering if the tool that was built from their expertise will eventually be used to argue that their positions are redundant. It’s the most profitable approach for the builder and the one that leaves the least power with the people doing the work.

The Test That Matters

What I keep returning to is the reaction I described at the beginning. The person on the ground who went from guarded to interested the moment ownership shifted from “built for you” to “built by you.” That reaction is, I think, the most honest signal available for evaluating whether a monetization model is actually ethical or just convenient.

Each of the models above answers a simple question differently: does the person whose work this tool touches end up feeling more secure or less secure in their role? If the model creates a situation where someone’s expertise has been encoded into a tool they don’t control, understand, or have the ability to maintain, they’re right to feel less secure. If the model preserves or expands their understanding of both their own work and the technology involved, they’re on firmer ground.

That test doesn’t always point in a comfortable direction. The gift economy model is ethically clean for the user but unsustainable for the builder. The service model is sustainable and preserves user autonomy, but it’s labor-intensive and doesn’t scale without more people. The configured product model is efficient but risks creating vendor expectations. There’s no option that resolves every tension simultaneously.

What I’m Actually Selling

There’s one more thread worth pulling here, and it has to do with transparency about what these tools actually are and how they get built. I use AI to help write the code for these tools. That’s not a secret; I’ve written about the process in detail. But it means the thing I’m selling, in whatever model I choose, is not hundreds of hours of hand-coded development. It’s the domain expertise to know what problems are worth solving, the design judgment to build tools that non-technical people can actually use and maintain, and the willingness to sit with someone and understand their work well enough to automate the right parts of it.

That distinction matters because it changes what honest pricing looks like. If I pretend the value is in the code itself, I’m misrepresenting the labor involved. If I’m upfront that the code is the easy part and that what costs real time and effort is the problem identification, the architecture decisions, the documentation, the training, and the ongoing support, then the pricing reflects what the district is actually getting. It also, not incidentally, makes it clearer why the person on the ground should learn to build these things themselves. If the code is the easy part, the barrier to entry is lower than they think.

Where I’m Sitting

I don’t have a final answer on this yet, which is part of why I’m writing about it rather than announcing a pricing page. What I do know is that whatever model I land on needs to pass the test I keep coming back to. The person on the ground, the administrative assistant, the instructional coach, the support staff member whose daily work these tools are designed to touch, should come away from the experience feeling more capable and more secure, not less.

That rules out some approaches entirely. It makes others more complicated than they might look on paper. And it means the easiest path (build the tools, sell them to administrators, collect the check) is probably the wrong one, because it skips the people whose trust matters most.

In the Vultures piece, I argued that the best version of automation is the one where educators become their own vultures, on their own terms. The monetization question is an extension of the same principle. The best version of paid EdTech work might be one where you’re not selling the tool at all. You’re selling the knowledge and support that help people build it themselves. The tool is the byproduct. The capability is the product.

I’m still working out what that looks like in practice. If you’re thinking through similar questions, I’d welcome the conversation at licht.education@gmail.com. You can find the tools I’ve built so far, all still free and open-source, at bradylicht.com.