For years, the non-profit sector has operated under an unspoken assumption. Technology should be free, or at least heavily subsidised. We relied on the generous free and charity discount tiers from giants like Microsoft and Google, treating their platforms as the default infrastructure for our work.
But the landscape is shifting rapidly. We are seeing a quiet but significant exodus of EU organisations moving away from these Silicon Valley monopolies and towards EU-based tech startups.
The catalyst is a growing unease with extractive data practices, most recently highlighted by the pervasive, often hidden integration of AI tools into our daily workflows. When a platform's updated terms of service allow it to ingest your sensitive communications or donor records to train a large language model, "free" suddenly feels far too expensive. It is time to bring technology choices back into our own hands.
In the charity sector, we apply rigorous ethical frameworks to almost everything we do. We protect staff welfare, we conduct due diligence on our external relationships, and we anchor our missions in human rights. Yet, for too long, we have treated software procurement as a purely administrative task. A box to check rather than a moral decision to weigh. We must start evaluating our technology with the same exact scrutiny we apply to the rest of our operations.
When I started building tools at Jura Labs, I kept coming back to the same question: what do your technology choices actually say about your values? Not in a manifesto sense. In a practical, "where does the data sleep at night" sense.
Here is how I approached this subject. Some of it is specific to software development. Most of it applies to any organisation choosing tools.
The Problem with "Free" Tools
Most small organisations default to free-tier SaaS: Google Workspace, Trello, HubSpot, Mailchimp. These tools work, and for many organisations they are the right choice. But "free" has a cost, and it is usually paid in data.
When you use a free CRM, your donor list, your beneficiary records, and your internal communications sit on someone else's servers, governed by someone else's terms. That data can be used for ad targeting, training AI models, or sold to third parties. The privacy policy might allow it today. A future acquisition might change the rules entirely.
For a charity working with vulnerable communities, this is not hypothetical. It is a governance failure waiting to happen. Before adopting any tool, ask three questions: where is the data stored, who can access it, and what happens to it if you stop paying or the company is acquired? If the answers are unclear, that is your answer.
Data Sovereignty in Practice
Data sovereignty means your data stays under your legal and physical control. For UK and EU organisations, GDPR gives this regulatory protection. But sovereignty is really about power. If your donor database lives on a US platform, a change in American data policy could put that data beyond your reach.
I chose a local-first architecture for both ROOTED and Jura Trace. All processing happens on the user's own device. Nothing is uploaded to our servers because we do not have data servers. There is no privacy policy to breach because there is no data to breach.
For our own infrastructure, we self-host on a Hetzner VPS in Germany that uses green energy: and hosts our analytics, CRM, task management, automation workflows and files. It costs roughly the same as a mid-tier SaaS bundle, but we own the data outright and it stays within EU jurisdiction.
I have written more about this in a separate post on data sovereignty, including the GDPR specifics and what local-first architecture means in practice. If your organisation handles personal data, it is worth a read.
Energy Is a Design Decision
This one surprised me early on. The programming language you build software in directly affects how much energy it consumes. A 2017 study from the University of Minho found that "Python uses roughly 76 times the energy of C or Rust for equivalent tasks." For a script that runs once a day, nobody notices. For software running continuously on thousands of devices, it adds up fast.
We built Jura Trace's core in Rust for this reason. It compiles to native code, runs efficiently on older hardware, and through the Tauri framework produces desktop applications that are a fraction of the size of Electron-based alternatives. That last point matters when you are distributing software to organisations with limited bandwidth.
You do not need to rewrite everything in Rust. But when commissioning new software, it is reasonable to ask your developers about the energy profile of their chosen stack. The Green Software Foundation publishes practical guidance on this.
The Nuances of Open Source
"Use open source" is common advice for non-profits. It is good advice, but incomplete.
An open source project with no funding and a single maintainer is a risk, no matter how good the code is. If that maintainer steps away, your tool stops receiving security updates. Before adopting an open source tool, check the project's health: contributor count, commit frequency, funding model, governance structure.
Licence matters too. The MIT licence lets anyone do anything, including large corporations incorporating your work into proprietary products without giving back. The AGPL requires that modifications to server-side software are shared. At Jura Labs, we shifted from traditional open source to a source-available model using the PolyForm Noncommercial licence. Anyone can use our tools for free for non-commercial purposes. Organisations reselling the software pay a licence fee. This protects the social mission whilst keeping the tools accessible.
The real value of open source is often the community, not just the code. When we chose Grav for our website and Tauri for our desktop framework, community responsiveness mattered as much as the technical merits. A smaller, focused community building something with clear principles tends to outlast a large project that has lost direction.
So do not just ask "is it open source?" Ask: who maintains it, how is it funded, what licence does it use, and what happens if the project is abandoned? Those questions matter more than the label.
Local AI and the Energy Trade-off
If your organisation is considering AI-powered features, the ethical questions multiply. Cloud-based large language models are powerful, but every query sends your data to a third-party server and carries an energy cost that is largely invisible to you.
For ROOTED, we run a quantised version of Llama 3.1 locally through Ollama. The AI runs on the user's own hardware. It is slower than a cloud API call and needs a reasonably modern machine. But no data is transmitted, there are no ongoing API costs, and there is no dependency on a third party's willingness to keep offering an affordable service.
This is a trade-off, not a clear win. Local AI is not viable for every use case. The point is to make a deliberate choice rather than defaulting to the most convenient option.
Starting from Where You Are
None of this requires tearing up your existing setup. A good starting point is simply auditing what you have. List every tool your organisation uses, note where data is stored and who controls it, then focus your attention on whichever tools handle your most sensitive information. You do not need to change everything at once.
Technology choices are governance choices. After twenty-five years of working in technology, I have found that the organisations that take their tech decisions as seriously as their financial decisions and safeguarding policies tend to be the ones still standing when the landscape shifts. If any of this resonates and you want to talk it through, get in touch.
References
- Pereira, R. et al., Energy Efficiency across Programming Languages, SLE 2017. doi.org/10.1145/3136014.3136031
- Green Software Foundation, Software Carbon Intensity Specification. grnsft.org/sci
- PolyForm Project, Noncommercial License 1.0.0. polyformproject.org
- C2PA, Content Provenance and Authenticity Technical Specification. c2pa.org