How we compare

We're not trying to win every comparison. We're trying to be the right answer for the cases where production AI is genuinely a different engineering problem than the alternatives can handle. For the other cases, the alternatives are right - and where we think so, we say so.

vs. a ChatGPT subscription

A ChatGPT subscription for your team is cheap, fast to deploy, and genuinely useful for some work. For drafting first cuts of internal documents, answering questions about your own organisation, summarising meetings, exploring an idea - chat is great. We use it ourselves.

The argument isn't against chat. It's against using chat as the operational layer for the work charities actually do.

The capability leaves with the person. When a fundraiser writes a great appeal email by prompting ChatGPT well, the appeal lives on but the prompt-craft walks out the door when they leave. The next fundraiser starts from zero. A system embeds the capability in the organisation - three years in, the work is better than it was on day one because every reviewer correction has improved the system.

There's no audit trail. When a funder asks "how did you arrive at the impact number you reported?", you need a system of record. ChatGPT conversations live in the user's account, in a format you can't query and that doesn't link back to source data. A Loop deployment writes every action to an immutable audit log you can query and export.

The data discipline doesn't survive contact with reality. The ICO is clear that charities can't paste beneficiary data into a tool that wasn't built for it. In practice, well-intentioned staff under time pressure paste data they shouldn't. The DPIA you'd write is essentially "we trust people not to do this". A Loop deployment runs in a dedicated, isolated deployment, with PII redaction before any model call - the DPIA writes itself.

Chat isn't a system of work. The work your team does has a shape - a queue, a review chain, a log of what went out and when. Chat is an open-ended conversation. It doesn't queue, route, sign off, or log. A Loop deployment has the shape of the work built in.

Nothing compounds. Each ChatGPT conversation starts fresh. There's no eval surface, no drift detection, no per-Loop accuracy that you can watch improve over a quarter. A Loop deployment has an eval surface - you can see whether the system is better than it was last month. If it isn't, you can fix it. If it is, you have evidence to take to the trustees.

vs. the AI features your platform vendor is selling you

Salesforce Einstein. Microsoft Copilot Studio + Power Platform. The AI add-on your fundraising CRM or your case-management system is now offering. The big platform vendors all have AI features now, and their account execs all have quotas.

These platforms can be operational. The question isn't whether they're capable. It's whether they're shaped for what charities actually need.

They're optimised for cross-customer reuse. Their value to the vendor comes from selling the same capability to thousands of customers. Your customisation lives inside their ecosystem; the more bespoke your work, the more you're swimming against the current of the product. The opposite of what a Loop deployment is for.

They charge per seat. Five staff at £40 a seat a month is £200 a month forever. Loop deployments charge for the build and ongoing care, not per head. Over five years on a small team the difference is real money; over a large team it's substantial.

They own your data architecturally. The AI capability sits on top of their data layer. If you switch CRM in three years, the AI capability built on top moves with the CRM. You don't take your operational layer with you.

Their feature roadmap is theirs, not yours. When they deprecate, repackage, or move features behind a higher pricing tier, your operational capability moves with their commercial strategy. A Loop deployment is your code in your repo - we can't change the deal even if we wanted to.

When the platform AI is right: if you're already running the platform, your team is using it, and the operational job is straightforward enough that the platform's generic flow fits. Use the platform. Genuinely.

When Loop is the better fit: where the operational job has specific governance, audit, or cross-system integration needs that don't fit the platform's standard mould. Where the work spans systems the platform doesn't own. Where you need the AI to be a system you can defend to your trustees, not a feature you rent from a vendor.

vs. building it in-house

This is the most respectable alternative, and the one we say "go for it" to most often. With Claude or GPT and a competent engineer, you can build basic Loops. We've sometimes been the people advising charities to do exactly this.

The API calls aren't the hard part. The hard parts are:

Getting from 90% accuracy to 99%. The last 10% is an order of magnitude more work than the first 90% - the BCN case study walks through why. If 90% accuracy is fine for your use case, in-house is genuinely a good answer. If you need 99%, the engineering looks different.

Designing the HITL chain so trustees and DP leads sign off. Most production AI failures aren't the model getting it wrong. They're nobody noticing for three weeks because the gate wasn't there.

Integrating with the existing stack. CRM, MEAL system, finance, comms tooling. The model is the easy bit; the integration is the long tail.

Building the eval surface that survives a model upgrade. Models change every six months. Without an eval surface that lets you measure before/after, you don't know whether the swap helped or hurt.

Three years of doing this is what we bring. We've made every mistake worth making.

When to do it in-house: if you have an engineer with ML production experience AND charity-sector experience AND the time to spend on the long tail of edge cases. Or if you only need basic capability and can live with 90% accuracy. Both are real cases.

When to work with us: most other cases.

How we'd put it plainly

The three comparisons are different shapes of trade-off, not different versions of the same one.

Chat is a capability argument - it can't be the operational layer no matter how well prompted. Platform AI is a fit argument - it can be operational, but the shape rarely matches charity work. In-house is a resources argument - it's the right answer if you have the people, the time, and an acceptable accuracy bar.

We'd rather lose a comparison honestly than win one by pretending the alternative is worse than it is.