Experience that predates the company
Data XL is built by engineers and analysts who have spent years living with data systems — building them, maintaining them, and fixing them when they slowly went wrong.
Most system failures we encountered were not outages, but slow data decay: poorly architectured, followed by inconsistent definitions, reused fields, missing provenance, and transformations no one could explain.
We learned early that data problems rarely announce themselves. Numbers drift. Definitions change quietly. Pipelines keep running, but produce results that no longer mean what people think they mean. By the time this is noticed, trust is already damaged.
That experience shaped how we work. We learned to treat data as something that needs care and protection. Not as exhaust from applications, but as the core asset systems are accountable for. Systems, in our experience, must be built around data that can be understood, questioned, and defended over time.
The experience outlined below reflects work led and delivered by members of the Data XL team prior to, and alongside, the founding of the company. Much of it took place in large, multi-partner programmes, including collaborations with the University of California, San Francisco (UCSF), ministries of health, international donors, and implementing organisations.
Systems delivered
Over the years, we have designed, built, and operated production systems where data accuracy, continuity, and confidentiality were not optional extras, but baseline requirements.
- National and multi-country data warehouses designed for stable indicators and longitudinal analysis
- Case-based and longitudinal surveillance systems tracking individual-level outcomes over time
- Electronic medical record platforms and reporting layers, including large-scale OpenMRS deployments and custom-built systems
- Client and patient registry services focused on identity resolution and cross-system linkage
- Interoperability layers connecting clinical systems, laboratories, and reporting platforms without silent data loss
- Decision-support dashboards built on explicitly modelled and versioned datasets
- Financial and operational dashboards used for management, oversight, and accountability
- Secure data platforms for organisations handling highly sensitive member and workforce data, including labour and professional associations
These systems had to keep working while programmes evolved, partners changed, and regulatory expectations tightened. Designing for that reality became part of the job.
How we approach data engineering
Data engineering, as we practice it, is not primarily about tools or throughput. It is about understanding what data represents, how it is produced, and how it will be used months or years later.
In practice, this means spending time on things that are often rushed or skipped:
- Thinking carefully about what each data point actually represents in the real world
- Making assumptions explicit in data models, rather than hiding them in code
- Treating ETL processes as first-class, versioned artefacts
- Building pipelines that can be inspected, explained, and repaired when something goes wrong
Automation and artificial intelligence are used where they genuinely help. We are careful not to use them as a shortcut around unclear data or weak foundations.
DevOps, security, and confidentiality
Over time, we learned that correct logic alone does not make a reliable system.
Data platforms only stay trustworthy if they are operated with discipline. Pipelines need to be deployed predictably, monitored continuously, and secured properly. Failures should be visible, recoverable, and explainable.
Much of our work took place in environments where:
- Data sensitivity and confidentiality were critical
- Access needed to be tightly controlled and auditable
- Systems were subject to governance, privacy, and compliance requirements
As a result, security, access control, and operational hygiene are not add-ons for us. They are part of how data engineering is done.
Domain knowledge as an engineering advantage
Working deeply in public health, epidemiology, and large operational programmes changed how we read data.
We learned to recognise when trends do not make sense, when indicators are being misused, and when data looks precise but is not reliable. We learned to work with bias, uncertainty, and incomplete information without pretending they do not exist.
That experience informs practical decisions every day: how data models are shaped, how dashboards are interpreted, and how conclusions should be presented.
Applying this experience today
Data XL exists to continue this work with focus.
We work with organisations that care about doing data work properly — organisations that want systems they can trust, explain, and rely on over time. Our role is to bring the experience we have accumulated into a setting where it can be applied deliberately, carefully, and without compromise.