A TechFreedom startup stack?

A lot of what TechFreedom is about is helping people and organisations who already have some tech, assessing risks through the lenses and then doing the difficult work of actually doing something about it.

Organisations will already have some tech. Usually quite a lot of it, and often a bit of a jumbled mess.

Microsoft or Google, a CRM or two (seriously this happens), Slack or Teams (or both), mailchimp, a website, some spreadsheets and various things joined together with linked sheets or Zapier. Probably at least one system everyone hates but nobody dares turn off and more than likely systems that you've not even sure how it got there.

TechFreedom isn't about tech evangelism and the work is more than just what is the perfect alternative. It's what have we got, where are the risks, which of those risks actually matter, and then the difficult bit... what are we going to do about them?

One of our premises with TechFreedom has always been that it's more than just a list of alternatives. There are already good lists of open-source, European, privacy-preserving and self-hosted tools. And yes we have a growing TechFreedom database too. But knowing an alternative exists isn't the same as migrating an organisation to it.

But I was recently asked a slightly different question:

What if you were starting from scratch? What would a TechFreedom tech stack look like?

And I thought that was an interesting question...

Freedom versus pain in the arse

If I was starting from scratch, with the whole world at my fingertips, I'd probably, alongside the TechFreedom lenses - jurisdiction, continuity, surveillance, lock-in and cost exposure - add a very simple sliding scale:

How far do I want to lean into TechFreedom?

versus

How much of a pain in the arse am I willing to put up with?

You could replace the second one technical capability, willingness to learn or administrative overhead. But pain in the arse is more accurate because much of what draws us to 'big tech' is that it is designed to be easy. Much like McDonalds spent years perfecting food mechanics and packaging systems to create a highly optimized, easy-to-eat structural experience... meaning it's easy to stuff it in your face even if you feel like shit after, Big Tech is designed to make it easy to use, and easy to lose you control.

Google Workspace is so convenient. Running and maintaining your own infrastructure isn't always.

So weirdly, the answer for me, isn't about purity. It's deliberate dependency.

Know what you're giving up and what you're getting in return. And, particularly for important things, knowing how you would leave.

I think you can sort of draw it like this

Top right is the truest of Sovereignty, but it's hard work. Bottom left is where most people are. Top left is quite a nice place to be, freedom without all the hassle. Bottom right, is exactly what it says.

Start with needs, not alternatives

So before we get to the actual stack, I think it's also important to think about how we think about the stack.

Don't start with what is the alternative to Microsoft Teams? Start with we need a way for people to talk to each other. Don't start with an Airtable alternative. Start with what information you need to hold and what people need to do with it.

This is something I've also been exploring through StackMap. In stackmap you can define you tech in two ways - function or delivery

For a small organisation I'd probably think about the functions: finance, governance, people, fundraising, communications, data etc. But you could break it down further into something like:

• identity, email and calendars
• files and collaborative documents
• communication and meetings
• tasks and projects
• operational data and CRM
• website and publishing
• newsletters
• finance
• analytics
• passwords and security
• AI

And I'd be asking questions for each like

• What data will live here? How sensitive is it?
• Can I get that data back out in a useful format?
• What happens if the company disappears, doubles its prices or changes direction?
• Am I depending on one provider for several critical things at once?
• Could somebody else run this?
• Does this need to exist at all?

Increasingly I think maybe you don't need a huge platform or product at all

My own website is mostly simple HTML, a language that is supported, and really really good! It's ridiculously fast, tiny compared with many modern websites, cheap to host, portable and doesn't need a database, a software update cycle or several megabytes of JavaScript to tell you what pastry I think is the best.

Sometimes the TechFreedom answer is less technology.

A static website rather than a platform, markdown rather than a complicated knowledge system, RSS rather than an algorithmic feed. Open standards as a basis for how you think about tech choices.

And maybe make your own

There's another option which I think has become much more plausible over the last year or two, Folk software as Doug likes to call it

Small tools made by and for the people actually using them, rather than products designed to capture an entire market. Doug has been doing loads of this at Dynamic Skillset.

• ProjectDial exists because he wanted a better way of seeing his consultancy projects.
• Markdeck 3D turns Markdown into presentations in the browser.
• CalAnywhere exists because moving away from Google exposed a gap around privacy-respecting calendar scheduling.

They're small, legible tools solving actual problems. And increasingly the question might be:

Do I need to find another platform, or could I make the thing I actually need?

AI-assisted development changes the economics of this quite significantly.

And maybe while you are at it, you can rethink about how you want to work, rather than what the economics dictate. My own tools take a different look at long standing approaches. Tending asks what relationship management might look like if you don't start from the assumption that what you need is a traditional CRM. Glade asks what governance software looks like if decisions and organisational memory are the spine rather than uploaded PDF board packs.

Now obviously, not everything should become bespoke software. Bespoke systems can create their own lock-in and maintenance problems remarkably quickly. But there's a useful middle ground between buy Salesforce and build Salesforce.

Build the tiny thing you actually need, sse open formats (all my tools are designed around API's, Open Knowledge formats, Markdown, export and connection).

So what might I actually use?

At the relatively painless end I'd look at something like:

• Workspace: Proton rather than Google or Microsoft where it fits. Proton is not perfect, but it's a balance between freedom and pain in the arse.
• Passwords: Bitwarden or Proton Pass.
• Projects: OpenProject, ProjectDial, or something small you've made yourself.
• Structured data: Baserow rather than automatically reaching for Airtable.
• Messaging: Signal
• Meetings: Whereby or whichever reasonably portable service works.
• Scheduling: CalAnywhere.
• Blog: Ghost.
• Website: plain HTML where possible; perhaps WordPress where a fuller CMS is actually needed.
• Analytics: Plausible or Matomo.
• Newsletter: something like Brevo.
• CRM: CiviCRM where it fits, Baserow for simpler needs, Tending for relationship-centred work or perhaps something purpose-built rather than assuming every organisation needs "a CRM".
• Governance: Glade, shared files and a decision log, or whatever matches how you actually govern.
• Finance: probably QuickFile (or FreeAgent, Xero or Sage because I have absolutely no desire to become my own accounting software company).

The important thing is that I wouldn't choose every product because it gets the highest TechFreedom score.

Going further

If I was willing to suffer more pain in the arse then next step would be leaning more into managed open-source infrastructure. Much of the same tools, but maybe self host them

Something like Nextcloud for files, documents and collaboration, OpenProject for projects, Baserow for data, and maybe Element/Matrix where persistent team chat matters.

And then there is AI

AI makes the whole thing particularly obvious because committing yourself to one provider right now seems slightly bonkers as I've written before about taking a local-first approach.

So my first layer would be Ollama and local models for anything they are comfortably good enough to do and flexibility for everything else. OpenRouter gives you another degree of separation between the tool you're using and the underlying models (although they've just been purchase by Stripe...) And something like GreenPT pushes further towards European infrastructure, privacy and open models.

For coding, I increasingly like the idea of OpenCode rather than making the coding environment itself dependent on Claude, OpenAI or anyone else.

But I recognise that this probably feels too far for some. So yeah, just use the best thing, Claude. ChatGPT. Gemini. Whatever works particularly well for what you're doing this month. But...the trick is to make the model the replaceable bit.

That's part of why we've been building Rack. Your instructions, methods, voice, boundaries and ways of working shouldn't belong to Claude or ChatGPT. Rack keeps those practices locally and can turn them into instructions for different AI environments.

And it's why I built MyMemory: your accumulated context about yourself shouldn't only exist in the memory of whichever AI service you've happened to use for the last two years. It can be held separately and selectively passed into different tools.

Own the things that make changing tools difficult.

Your context, your data, you approaches and ways of doing things, your domain (you'd be surprised how many start by getting a domain through a SAAS), your important files.

My actual starting point

So if I was starting tomorrow, I wouldn't probably wouldn't advise getting your own servers.

I'd choose some boring, portable foundations. I'd use managed open tools where they made sense and keep critical data exportable and backed up. I'd use simple HTML instead of a platform when HTML would do. I'd make a small tool rather than buy a giant one where that was genuinely easier.

I'd use local AI where it was good enough and frontier AI where it wasn't and I'd try quite hard not to add technology until I actually needed it.

Because every new tool is another account, another data store, another integration, another bill, another dependency and eventually another migration.

Maybe a TechFreedom startup stack isn't actually a particular stack.

It's building things so you retain the ability to make the next choice.