UK Grants Intermediary
Platform Modernisation

What the client does

The client sits between funders (energy companies, local authorities, housing associations) and vulnerable individuals — processing applications, managing schemes, and distributing financial support. Three revenue lines:

• Managed Funds — white-labelled grant schemes for utility companies and public bodies. End-to-end: application intake → eligibility → validation → award. Energy company welfare funds, local authority hardship schemes.
• Procurement Portal — self-service procurement for partner organisations. Partners load funds, purchase vouchers and goods on behalf of beneficiaries. Integrated with a digital voucher fulfilment provider.
• Partner Network — cross-sector information sharing across ~1,000 partner organisations.

Why this is urgent

PE acquisition changes the trajectory. The growth playbook for this sector is well-documented: start with a focused platform, add adjacent services through acquisition, use the technology stack as the integration layer that makes each bolt-on cheaper and faster than the last. The technology is the accelerant — but only if it's built to scale.

The market is expanding, not contracting: UK household support schemes extended to 2030, a £15B Warm Homes Plan, intensifying Ofgem scrutiny of how energy companies support vulnerable customers. Government-backed funding through intermediaries in this sector is growing.

A PE-backed buy-and-build strategy with a creaking Salesforce stack is a race against time. Each acquisition adds complexity. Without a platform that absorbs that complexity cleanly, integration costs compound and the growth thesis stalls.

The Salesforce problem

Salesforce is good at CRM. It is not good at running a grants intermediary at scale. Observable pain points from the current architecture:

• Processing speed: Multi-week processing times are consistent with Salesforce workflow engine limitations — configurable, but not fast at volume.
• Evidence handling: Manual upload processes with email fallback are classic signs of a brittle UI built on top of Salesforce custom objects.
• Siloed systems: Procurement portal and scheme management appear unconnected. No unified tenant context across the B2B2C model.
• Licensing cost: Per-seat Salesforce at ~1,000 partner users is significant annual spend vs a serverless platform that scales to zero.
• Extensibility: Every scheme rule change requires Apex triggers and custom objects. No clean DSL for eligibility logic means slow iteration.

Target architecture

TOGAF-lite layered approach — business architecture first, then data, then applications, then automation, then agentic. Each layer is weeks of focused work, not months of analysis.

Multi-tenant PostgreSQL with Row-Level Security — each partner org is a tenant. ~1,000 tenants rules out schema-per-tenant or DB-per-tenant. RLS at the database level, not in application code. The business logic lives in portable Python Lambda functions — not in Salesforce Apex, not in a workflow builder.

The agentic layer — AgentCore

Instead of predefined workflow diagrams, agents compose workflows organically at runtime. The system doesn't have a "workflow engine" — it has events (things that happen), agents (things that reason), functions (things that do stuff), and queues (things that decouple).

AgentCore Policy uses Cedar to enforce hard guardrails — agents cannot approve awards, cannot access applicant data outside their assigned scheme, cannot bypass the human decision step for special-category data (GDPR Article 9, DUA Act 2025).

Three-year delivery plan

Conservative in Year 1, aggressive in Years 2–3. You can't move fast on a foundation you don't understand. Once you understand it, you move very fast indeed.

Total build cost estimate: £700k–£1.2M over 15–23 months. Running costs post-migration: £180–720/month. Salesforce licensing at this scale: likely £50k–150k+/year. Break-even: 12–18 months post-launch.

What ticketyboo brings

Programme Engine — live demo

The Scheme Configuration Engine is built. The thesis: eligibility rules should be configuration, not code — so a policy change doesn't require a deployment cycle. Below is what that looks like in practice, and where the assumptions start to show.

Technical demo → Patricia's story →

Next steps

This analysis is based on publicly observable patterns. Before any build work begins:

• Validate assumptions with client stakeholders — does the pain point analysis match reality?
• Map the current Salesforce data model in detail (Q1 discovery work)
• Identify the quick wins that hurt most today
• Understand the PE investor's timeline and growth thesis
• Confirm Salesforce contract renewal dates (drives migration sequencing)
• Assess internal engineering capability (build vs buy vs partner)