What 84 AI recipes taught us about the DIY boundary

We've been building our AI Recipes for Charities since we started working with charities on AI. Each recipe is a step-by-step guide for a specific task, with instructions clear enough that someone who's never used AI before can follow them. At 84 entries, they cover everything from fundraising and service delivery to data, operations, and governance.

The recipes are self-service by design. That's the point. A charity shouldn't need to hire us to summarise board papers or review a grant application before submission. Those are tasks where a well-written prompt and a free AI tool get you 80% of the way there. We'd rather charities could do that themselves and spend their money on the problems that actually need building.

We knew going in that there'd be a boundary between what a recipe can cover and what needs custom work. Several of the recipes deliberately push into territory where you'd benefit from external support. But writing 84 of them made the shape of that boundary very clear.

The recipes we hear most about

The recipes charities tell us about most are all about processing information that already exists: feedback analysis at scale, bid review before submission, and board paper summarisation. Not content generation. Not chatbots. Processing backlogs. Charities have more data and documents than they can read, and AI is good at reading for you.

These recipes work well as self-service because the task is contained. You have a document. You want something done with it. You follow the steps. You get a useful result. The data stays in one place, the output is easy to check, and if the AI gets something wrong you'll probably notice.

The recipes we hear less about are the more ambitious ones: donor churn prediction, grant matching, programme outcome tracking across multiple data sources. These require better data quality and more technical confidence. They're also where the biggest long-term value sits.

Where self-service hits a wall

The pattern we keep seeing: the recipes charities get most excited about are the ones that need more than a recipe.

Donor churn prediction sounds straightforward. The recipe explains the concept and walks through a basic version using a spreadsheet export and an AI chat. You can do it as a recipe, but it's the Heston Blumenthal version of baking a chocolate cake. It'll take a long while for most people to get their heads around it, and making it actually useful means connecting to your CRM, handling your specific data quirks, running it regularly, and integrating the results into your fundraising workflow. At that point, it might be better to bring in some external support.

Grant matching is similar. A recipe can help you manually compare your charity's profile against a set of grants. Doing it automatically across hundreds of opportunities, with results that update as new grants are published, requires connecting to data sources, building matching logic that understands your programmes, and creating an interface your team will actually use.

The boundary isn't about AI capability. The models are good enough for all of these use cases. The boundary is about everything around the AI: the data connections, the workflow integration, the reliability at scale, the interface that makes it usable by someone who isn't thinking about AI at all.

Start with the recipes, then decide

Browse the recipes at airecipesforcharities.com. Start with a problem you actually have, and send the relevant recipes directly to the people who'll use them. For the information-processing use cases, self-service works well and you don't need anyone's help.

For the use cases where you look at a recipe and think "yes, but we'd need this to run automatically" or "we'd need this connected to our CRM" or "we'd need this to work with our specific data," that's the boundary. Those are build problems. And the economics of building have changed enough that they're worth exploring, even for smaller charities. Recipes get you started. Custom development gets you there.