Applied Data Analytics for Impact

How I taught myself practical machine learning and engineered a working prototype using Python, OCR, and rule based logic Why I started building and not just thinking After mapping the food safety problem, I reached a point where thinking wasn’t enough. Ideas can sound convincing in words. Diagrams can make them look coherent. But without a working prototype, everything stays hypothetical. I didn’t want this project to live as a concept or a case study. I wanted to know whether it could actually work. Building felt like the only honest way to validate the idea. So I decided to commit to a fixed window and treat it like an engineering challenge, not a side thought. Sixty days. One end to end prototype. No shortcuts. Starting point: theory heavy, practice light During my Master’s, I had studied machine learning, NLP, and Python. I understood models conceptually. I knew how algorithms worked on paper. I had written isolated scripts and notebooks. But I had never built a complete system wh...

A data driven reflection on why consumer food safety needs innovation and how my journey began Introduction: A quiet turning point When working in India and travelling every 6 or a year once I noticed loads of difference in one them was the negligence of the FOOD SAFETY. That’s when I began noticing something small but unsettling. Customers regularly asked questions about food that surprised me. They confused expiry dates. They didn’t understand allergens. Some assumed if food smelled fine, it was safe. Others thought expiry labels were optional suggestions. There was no malice. No carelessness. Just a complete lack of clarity. What struck me most was the contrast. In the UK, food labelling and allergen transparency are taken seriously. In India, even well meaning businesses and customers operate with guesswork. That gap stayed with me. What I learned studying in the UK: Natasha’s Law, simply explained While studying in the UK, I learned about Natasha’s Law. It exists because a...

Introduction Many analytics systems work well at small scale, then degrade quietly as usage grows. Dashboards take longer to load. Refreshes fail unpredictably. Simple queries become expensive. Analysts respond by adding workarounds rather than fixing root causes. The issue is rarely a single slow query or visual. It’s that performance was never treated as a design concern across the pipeline . Why optimisation is required Performance problems are not just technical inconveniences. They lead to: reduced trust in analytics stakeholders abandoning dashboards analysts spending time firefighting instead of improving insight hidden infrastructure and opportunity costs Optimising performance is not about squeezing milliseconds. It’s about designing analytics systems that remain usable, reliable, and scalable over time . Performance as a pipeline property At a programme level, performance must be considered end to end . Poor performance can originate from: ineff...