About
Senior Frontend Developer · Horsefly Analytics · Manchester
I build production interfaces for a labour-market analytics platform, and I fix the tools that build them. Most of what I know about software I learned from the second half of that sentence: from tracing a hung build back to two overlapping edits, or a lint run that died on an unsaved file, and then proving the fix rather than asserting it.
What I Do Now
I am a Senior Frontend Developer at Horsefly Analytics in Manchester, a labour-market and workforce analytics SaaS, reporting to the CTO. I build and ship the production React, Next.js and TypeScript front end, and work across AWS, Terraform and PostgreSQL behind it.
- Built the Horsefly Workspace product and a public Chrome extension beyond the scope of a frontend role, opening a new revenue stream.
- Work on the AI-agent infrastructure behind the platform, integrating model calls and tool use into existing product surfaces rather than standing up a separate demo alongside them.
- Work on streaming correctness at the LLM-UI boundary: token streaming, partial-render correctness, cancellation and recovery under real input.
- Led the Next.js 13 → 14 upgrade across the main application.
- Replaced public-facing nginx ingress with a private AWS VPC Link architecture, removing the public attack surface, and contributed to the platform’s annual penetration-test pass.
Before Horsefly I shipped product across payments fintech, enterprise operations software and an AI SaaS: Open Banking and a Microsoft Dynamics 365 integration for a London payments company, React and Next.js product engineering at an AI SaaS, and the Terminal Management System for Toptech Systems, operational software running real-world terminal workflows.
How I Work Upstream
My open-source record is in the packages almost every JavaScript project depends on
without ever naming: magic-string, the source-manipulation layer inside
Vite and Rollup; recast, the printer behind jscodeshift;
eslint-plugin-import; postcss-selector-parser;
knip. Nine fixes merged, six of them shipped in a published release.
The method matters more to me than the count, and it is the same every time:
- Find it myself. Most of these I traced from a symptom in my own work rather than picking off a tracker. Where the diagnosis was someone else’s, I say so. On the FlashList scroll-position bug the diagnosis was the reporter’s, and the deterministic test that pins the measurement race was the harder half.
- Reproduce against the published build, not against my reasoning. Every claimed output gets checked against the stock release before I file anything.
-
Verify differentially. Where a correct reference exists, I run the
fix against it at scale: 136,000 comparisons against
String.prototype.replacefor the most recent magic-string fix, 32,902 disagreeing before and zero after; 20,880 generated operation sequences for ahasChanged()regression; 5,076 generated inputs for recast’s print-parse identity. - Disclose what the fix costs. If a change alters an existing test expectation, or leaves a related problem untouched, that goes in the pull request body rather than waiting for a reviewer to find it.
- State release status exactly. Merged on GitHub is not shipped to users. I check the merge commit is contained in a real tag and that the version is published, and I cite that version.
A bug report is a claim. A reproduction is evidence. A differential run against a reference implementation is a proof, and it is usually cheaper to build than the argument you would otherwise have in review.
Peer Review & Appointments
Reviewing other people’s artifacts is the same discipline pointed outwards: does the thing actually run, and does it produce what the paper says it produces?
Writing & Teaching
I write and make videos about software engineering, AI agents and cloud infrastructure on dev.to, Medium and YouTube. The material I care most about is the unglamorous half: how to reproduce a bug you cannot see, how to tell a real fix from a plausible one, and what it takes to move an AI feature from demo to dependable inside a real operational workflow.
Background
- MSc Computer Science, Manchester Metropolitan University
- BE Mechatronics Engineering, SZABIST
- AWS Certified Solutions Architect
- Cyber Runway Launch, cohort alumnus of the DSIT-funded UK cyber accelerator delivered by Plexal
The route here was not a straight line, and I think that is worth saying plainly rather than smoothing over. Mechatronics to software, Karachi to Manchester, client work to product. What carried across was the engineering habit of not trusting a system until you have measured it.