Helium Health operates across Sub-Saharan Africa, East Africa, and the GCC. Each market has its own payment infrastructure, its own preferred providers, its own failure patterns, and its own regulatory requirements. When I joined the Payments squad, the problem was clear: the business could not reliably collect money at scale across those markets.

The situation

Payment failures were creating friction at exactly the wrong moment. The failure rates varied widely by market and by provider, and nobody had a clear picture of why. The data existed in fragments across systems that did not talk to each other.

Each market also had different KYC requirements, different rules around how money could move, and different expectations from regulators. A solution that worked cleanly in Nigeria would not simply port to Kenya.

What we did

The first step was getting visibility. Working with the engineering and data teams, we built reconciliation tooling that tracked payment success rates by market, by provider, and by transaction type in close to real time. Before that work, issues surfaced through customer complaints rather than data.

With that visibility in place, we ran a structured process to evaluate and bring in the right payment providers for each market. This was not about picking one global provider and hoping for the best. It was about understanding the local infrastructure: which providers had the strongest success rates in each corridor, which had the compliance posture we needed, and which could handle the transaction volumes we were heading toward.

What changed

Payment reliability improved across the markets we focused on. The business could process transactions at the scale the growth required without the failure rate undermining customer trust. The work also fed into a broader platform that supported the company through a significant fundraising round.

What I learned

Payments infrastructure in emerging markets is not a problem you solve once. It is a set of relationships and tradeoffs you actively manage. The providers that work in one market are often wrong for another. Staying close to the ground in each market matters more than designing from a distance.

Healthcare providers across Africa operate in a cash-constrained environment. Clinics and hospitals that want to grow cannot access financing from traditional banks. The paperwork requirements are steep, the collateral expectations are unrealistic, and the approval timelines do not match the pace at which healthcare decisions need to be made.

Helium Health had visibility into how clinics operated through HeliumOS, its provider digitisation platform. Patient volumes, billing patterns, payment histories — that data was an asset nobody had yet put to work in a credit context.

The opportunity

The opportunity was to use operational data to inform part of the lending eligibility process. Rather than asking a clinic owner to produce years of audited accounts, we could look at signals already flowing through HeliumOS: how many patients they were seeing, whether their billing was consistent, how reliably they paid their Helium subscription.

What we built

Working with engineering, risk, finance, and legal teams, we designed and launched HeliumCredit, which allowed businesses to check their eligibility, apply for loans, and have funds disbursed quickly.

The eligibility model was developed in close collaboration with the finance and risk teams. We had to be deliberate about which signals carried real weight and which were misleading. A clinic that billed a lot but collected inconsistently was a different risk profile to one that billed less but collected reliably.

What changed

HeliumCredit opened up financing for healthcare providers who had no practical route to it before. Providers used it to expand services, buy equipment, and manage the cash flow gaps that are common in healthcare billing cycles.

The product contributed to the company's growth story and was part of the evidence base for its Series B fundraise.

What I learned

Credit is one of the highest-stakes product categories there is. When it goes wrong, it goes wrong for real people and real businesses. Product rigour and ethical rigour end up being the same thing in that context.

Dals provides interpreting and translation services to public sector organisations across the UK. NHS and Police were among the clients, but the public sector made up close to 90% of the total client base. The data needed to produce accurate reporting was spread across four separate interpreting systems, none of which were designed to work together.

The result was reporting that was slow and inconsistent. Different teams inside Dals were working from different numbers. Public sector clients regularly questioned the figures they received, and without a reliable system of their own to cross-reference, the disputes were hard to resolve.

The situation

Each system had its own data model and its own definitions for what counted as a completed booking, a cancellation, or a late attendance. Pulling those together required manual processes that were time-consuming and prone to error. There was no single source of truth and no clear way to explain discrepancies when clients pushed back.

What we built

Working with the engineering team, we delivered a Databricks lakehouse on AWS that consolidated data from all four source systems into a single governed platform. The architecture handled volume and variety while keeping processing efficient.

The more important work was getting the definitions right. Before any dashboard could be trusted, the business needed to agree on what its key metrics actually meant.

What changed

Teams across the organisation were, for the first time, working from the same numbers. The internal debates about whose figures were right largely stopped.

For public sector clients, the improvement in reporting quality changed the nature of contract conversations. Instead of spending time disputing figures, account managers could focus on service performance and planning.

What I learned

Data platform work is often framed as a technical problem. The harder work is getting people to agree on what the numbers mean in the first place. Once that is settled, the technology follows fairly naturally.

Relate is one of the UK's largest providers of relationship counselling, operating through Family Action. Until recently, counsellors, supervisors, and operations staff had no single system to manage their work. Intake was handled in one place. Scheduling in another. Clinical notes in a third. Frontline teams spent a significant portion of their time on administrative work that the right technology should have been handling for them.

Starting with discovery

Before any decisions were made about what to build, the team spent time understanding how work actually happened in practice. That meant conversations with counsellors, supervisors, operations leads, contracts managers, and data colleagues, following the journey of a case from the moment a client made contact to the point where their file was closed.

Counsellors were spending time on paperwork that should have been automated. Supervisors had no easy way to see caseload status. Safeguarding obligations were being met through discipline and good luck rather than system design.

What we are building

The platform covers the full lifecycle of a counselling case: intake and referral, scheduling, consent and forms, clinical notes, supervision records, payments, vouchers, and audit. The design principle throughout has been to make the right thing the easy thing.

What we are learning

Building for social care is different from building for commercial healthcare. Every design decision gets stress-tested against whether it serves the person sitting across from a client in a difficult session, or whether it is serving the system at their expense.

This is a work in progress. The case study will be updated as the platform reaches fuller deployment.