Case study
The same habit, with donor data in the room.
SwiftCause turns an Android phone into a Gift Aid kiosk for UK charities. The team was pasting code into ChatGPT. Declarations, donor records and HMRC files meant the rollout needed guardrails before anyone turned it on.
- Client
- SwiftCause
- Product
- Gift Aid for UK charities
- Engagement
- Audit, sprint, measure
- Website
- swiftcause.com
SwiftCause is a Gift Aid platform for UK charities. An Android phone or tablet becomes a donation kiosk. Gift Aid and the Gift Aid Small Donations Scheme are recorded at the point of giving, and the HMRC claim file is prepared from what was collected.
Development looked like EaziCore at the start. AI meant pasting code into ChatGPT and copying the answer back. There was no agent infrastructure, no shared skills, and no automation. The difference is the data. Gift Aid declarations, donor records and HMRC claim files meant any rollout had to be built with guardrails on the first day, not bolted on after.
Copy, paste, and keep it away from the data
- 01A feature starts in a chat window
- 02The answer is copied back by hand
- 03Most of the org stays away from AI, because the data is sensitive
Agents in the repo, answers inside a fence
- 01Agents work inside the codebase
- 02Tests and an AI reviewer run before a person
- 03An internal assistant answers only what that person is allowed to see
Audit, then a sprint, then the same questions again
We baselined where AI actually sat before changing anything. It was manual copy-paste. There was no agent infrastructure, no automated testing, no internal AI tooling, and no control on how a model could touch donor or Gift Aid data.
The sprint then landed in five places. Developers got agents in the repo, plus automated tests and a first-pass review. Senior engineers got a closed loop in front of the pull request. Managers and owners got dashboards. The rest of the organisation got one internal assistant, built so it could be pointed at real questions without being pointed at everything.
- 01
Audit
A baseline of prompting, testing, tooling, and the absence of any control around donor and Gift Aid data.
- 02
Sprint
Agents, a review loop, dashboards, and a secure assistant for the people who are not writing the code.
- 03
Measure
How much of testing and review AI could safely own, and whether the assistant stayed inside its guardrails.
What changed at each level
Developers stopped beginning a feature in a chat window. Agents sit in the codebase, with managed context and reusable skills. Routine test coverage and a first pass of review run through Playwright-based tooling before a person looks.
Senior engineers kept the sign-off. Automated tests and an AI reviewer take the obvious issues first, so the manual pass is for the pull requests that actually need judgment.
Engineering managers stopped tracking delivery and adoption by asking around. Dashboards show testing coverage, delivery status and AI usage without a chase.
Owners got one view of adoption, output and cost. The wider organisation got something else: a secure internal assistant. It is a wrapper around the model, with retrieval over SwiftCause’s own documentation, user authentication, and a limit on who is asking and how much it is allowed to answer.
- 01An agent drafts the change
- 02Tests and an AI reviewer check it
- 03A person signs it off
A miss goes back before the human queue
- 01
Ask
Someone outside the engineering queue asks a question about the product, a donor record, or a Gift Aid rule.
- 02
Check
Authentication decides who is asking, and how much that person is allowed to be told.
- 03
Answer
Retrieval runs over SwiftCause’s own documentation. The reply stays inside those guardrails.
A day in each role
Composite scenes from the engagement, not transcripts.
Developer
Before
Every feature started by pasting code into ChatGPT and copying the output back by hand.
After
Agents work inside the codebase. Routine test coverage and a first-pass review run through Playwright-based automation before a person looks.
Senior engineer
Before
Every pull request, however small, needed a full manual pass. There was no automated safety net under it.
After
Automated tests and an AI reviewer catch the obvious issues first. Manual review time goes to the pull requests that need judgment.
Engineering manager
Before
Delivery and AI adoption were tracked by asking around.
After
Dashboards show testing coverage, delivery status and AI usage, without chasing updates.
Owner
Before
There was no way to confirm that AI was safe to point at real donor and Gift Aid data, so most people outside engineering did not use it.
After
A secure internal assistant, with retrieval, guardrails and sign-in, gives the wider organisation a way to ask. Answers are scoped to who is asking.
What moved
These are estimates, read after the rollout. The assistant was checked against real questions about donor and Gift Aid data. It stayed inside its guardrails.
33–40%
QA and testing time
Estimate. Share of what it used to take
−84%
PR and review cycle
Estimate
0–5%
Failed deployments
Estimate. Closed-loop review, then a person
0–5%
Defect rate
Estimate. Same loop
60–68%
Efficiency for assistant users
Estimate. Fast uptake across the organisation
2–3 wk → 1–1.5 wk
Feature delivery time
Estimate