The technology function
for large programmes.
From the requirement to the running system, one accountable partner across the whole technology surface — for humanitarian, civic, and financial programmes that need the estate held.
- 01 Define
- 02 Architect
- 03 Deliver
- 04 Run
Selected partners
Institutions and programmes we have worked with on the technology estate.
UK FCDOForeign, Commonwealth & Development Office
UN IOMInternational Organization for Migration
GFFOGerman Federal Foreign Office
DKHDiakonie Katastrophenhilfe
NIDAASudanese Development Call Organization
Gisa Group
MASCMutual Aid Sudan Coalition
LoHubLocalization Hub
P2HProximity2Humanity International
MCVMercy Corps Venture Lab
CFGCollaborative Futures Group
VTBVTB Bank
AmazonAmazon.com
ConvexityConvexity Technologies Nigeria
SiriInfoSiri Info Solutions
Capabilities
Four capabilities. One accountable partner.
- 01 Define
A requirement a board can fund
Programme objectives exist. The technology requirement usually does not. We turn those objectives into what is needed, what already exists, what should be bought rather than built, and what should not exist at all — costed and phased so a donor can fund it and a board can approve it.
- 02 Architect
Someone holds the whole estate
When the estate has no shape, every new tool becomes another seam. We set the systems, data model, integration points, access tiers, hosting, security posture, and how it will be governed — so there is one picture, and someone is accountable for it.
- 03 Deliver
The systems the programme runs
This is the part everyone else leads with. We build and integrate coordination platforms, field collection, case and aid flows, data pipelines, reporting, storefronts, and the connections to whatever already exists. Every figure in a report walks back to the input that produced it.
- 04 Run & transfer
The programme holds it before we leave
We operate what we build: support hours across UK and India time zones, incident response, data quality monitoring, change requests handled as a programme rather than a ticket queue. Documentation, runbooks, named owners and trained engineers are deliverables with dates. The engagement has an end, designed from the start.
Work
Constraint, then the system.
01
Privyra
Constraint. People cannot see or stop personal data being sold across broker networks in India.
Approach. Scan exposure, automate deletion requests, and keep risk visible after the first cleanup.
Ownership. Intellogi holds and runs Privyra.
02
Mutual Aid Portal
Constraint. Aid has to move under emergency pressure, with many actors and no shared picture of who is doing what.
Approach. Case and aid flows, shared operational picture, and a system communities can actually staff.
Ownership. Community operators can staff and run the live system.
03
45-60
Constraint. Trading decisions, rules and results lived in separate tools, so the operation could not be seen as one picture.
Approach. A live trading cockpit — Confluence Core — so signals, rules, and paper-forward results stay visible after the trade.
Ownership. Operators run the live platform.
Approach
Small teams. Tight loops. A handoff you can keep.
01
Define the requirement
What should exist, what should not, and what the estate will look like — before the constraint becomes a build.
02
Understand the constraint
Outcomes, risks, and what “done” means — before anyone writes code.
03
Ship in thin slices
Vertical increments so stakeholders see the real system early, not a slide about it.
04
Leave the runway clear
Runbooks, ownership, and defaults your engineers can extend without us in the room.
Contact
Tell us the constraint. We will reply with a next step.
Share the problem, the timeline, and who will own the system after launch. We typically respond within two business days.
Offices
London and Hyderabad — overlapping hours for UK and India time zones. That overlap is what makes Run credible: support that covers both working days.