Jane McKay

I'm Jane McKay, Founder and Principal Engineer of Forgeyard Digital. Twenty-five years in systems where being wrong costs money: financial systems, connected systems, data warehousing at scale. I've architected the software, built the CI pipelines that ship it and the quality systems that keep it shippable, and led the engineering teams running them. Latterly I've designed and now operate an AI software factory — the discipline is the same, the leverage is new.

Forgeyard is that experience aimed at a category most of the industry builds badly: health software. Apps people trust with medication schedules have to be engineered like safety-critical systems, and mostly they aren't. Mine are.

I don't use AI as a copilot. I designed and operate an autonomous software delivery pipeline: specialised agents for research, specification, architecture, test design, implementation, adversarial review and QA, coordinated by deterministic orchestration with enforced quality gates between every stage. Work is decomposed into dependency-graphed units, built in parallel waves planned for zero file conflicts, and nothing progresses past a gate without a machine-verified artifact.

That factory runs daily across a commercial multi-product portfolio. Designing it required distributed-systems thinking, evaluation engineering, failure-mode analysis and cost-model optimisation across model tiers — it is the hardest engineering problem I've worked on in 25 years, and it sits at the bleeding edge of how software will be built for the next decade.

For the engineering itself, start here: Modelling concurrent cyclical medication regimens as a deterministic engine →

Because the best apps go to the biggest markets, and that leaves a lot of people behind. Women on HRT. People managing parosmia. Parents tracking a child's sensory needs. These aren't small problems — they're just not venture-scale problems, so nobody builds properly for them.

I'd rather solve a hard problem completely for 5,000 people than ship a shallow one to millions. Concretely: exhaustive edge-case analysis, clinical review cycles with practising NHS clinicians, and terminology held to prescribing-standard precision. Harder work. Better software.

With a scheduling problem ordinary reminder apps can't even represent. A real HRT regimen is cyclical and concurrent: oestrogen as either a daily gel — dosed in pumps that change through titration, each of which must be recorded — or patches replaced twice a week on rotating days — one hormone, two delivery routes with different scheduling rules — progesterone for a set number of days in each cycle — and occasionally, on a clinician's advice, a window anchored to the actual period, so next month's schedule depends on an event that hasn't happened yet — and sometimes testosterone alongside. Different clocks, running simultaneously, every pattern modelled exactly as prescribed. Model that naively and it collapses at the first missed dose, regimen change or timezone shift.

HRTMe is built around a deterministic regimen engine: schedules are data, every transition is computed, and every rule is tested against the edge cases real prescriptions generate — missed doses, dose changes mid-cycle, travel across timezones, watchOS staying in lockstep with the phone. I could specify the domain precisely because I knew it first-hand, and I validated terminology and prescribing patterns with practising NHS clinicians. Domain knowledge wrote the spec; engineering made it hold.

It's now trusted by thousands of women, found entirely by word of mouth — retention earned by an engine that doesn't get their medication wrong.

Native first on Apple platforms — SwiftUI, properly architected, fully tested — and the same discipline on the web when the product calls for it. I don't ship prototypes; I ship software I'd bet my own data on, because I do.

Quality is a system, not a mood: the scheduling core is deterministic and covered by unit suites that enumerate the nasty cases; the UI is pinned by snapshot tests so regressions are caught by machines, not users; CI runs the lot on every change; and anything touching doses is treated as safety-critical — because for the person relying on it, it is.

That means clean architecture with clear layers. It means unit tests and snapshot tests that actually catch regressions. It means performance budgets, accessibility from day one, and privacy by default — no tracking, no accounts, nothing leaves the device unless the user explicitly chooses.

The interface layer is built on Apple's Liquid Glass design language, applied with discipline: minimal surface area, strict information hierarchy, zero engagement mechanics. A health app is an instrument — it should behave like one.

Because the UK is one of the world's leading HRT nations — around 14% of UK women take HRT, with prescriptions past thirteen million items a year, national NICE guidance, and one of the strongest clinical menopause communities anywhere. Building from inside that means the engine was specified against some of the most sophisticated prescribing patterns in the world, validated with practising NHS clinicians.

But the app isn't built only for the UK — it's used by women across the English-speaking world, from the US and Canada to Australia. Custom medications put the full power of the scheduling engine at any woman's fingertips: whatever her country's brands, formats or prescribing conventions, complex regimens that break ordinary reminder apps are straightforward to set up. UK depth, without UK-only assumptions.

I only take on projects I believe in. If you're building something genuinely useful for an underserved group — something privacy-respecting, something careful — we'll probably work well together.

I'm not interested in growth-hacking, addictive design, or shipping fast and fixing later. I'm interested in building software that earns trust, does what it says, and respects the people using it.

If that sounds like your project, get in touch.

The blood-pressure log already shipped: CuffLog is live on the App Store. Next down the line: Breaket, evidence-based support for breaking a vaping habit; a parosmia tracker for people whose sense of smell has been distorted — often after COVID; and a developmental needs tracker for parents of children with SEN.

The pattern is the same each time: an ignored population, a genuinely hard modelling problem underneath their need, and an engineering standard that treats their data as safety-critical. Same pipeline, same gates, same bar.

Everything stays on-device. No cloud sync unless the user explicitly turns it on, and even then it's iCloud — Apple-to-Apple, encrypted, never touched by me. No analytics on health data. No accounts. No third-party SDKs phoning home.

I test obsessively. Unit tests for logic, snapshot tests for UI, manual testing on real devices. If it's handling medication doses or health symptoms, I treat it like safety-critical software — because for the person using it, it is.

And I write documentation that assumes the next developer will be angry and in a hurry. Clear architecture, obvious naming, no magic. If I wouldn't want to debug it at 2am, I don't ship it.

Every function a strong engineering organisation has — architecture review, adversarial code review, test engineering, QA, release discipline — exists here too. The difference is how it's staffed: I architected an AI software factory that executes those functions as enforced, gated stages, with specialist human reviewers and practising clinicians wherever human judgment is decisive.

Twenty-five years of leading engineering teams taught me exactly what those gates are for. Now I direct the discipline rather than performing every step by hand: I set the standard, the factory enforces it, and nothing ships around it. The rigour of a large organisation, the focus of a small one, and none of the coordination tax.

Getting the language right. One wrong term — "menstruation" instead of "bleeding", "patient" instead of "person" — and you've just told someone this app isn't for them.

Medical language is precise for a reason, but precision that alienates the user is a failed interface. Getting both requires clinical review as part of the build cycle — clinicians validate terminology and prescribing patterns the same way tests validate the scheduling engine. Language is a correctness problem here, not a copywriting one.

Building apps people trust with their most personal information. Not because we're tracking less — because we're not tracking at all. Not because we're good at privacy theatre — because privacy is the architecture, not a feature.

The standard is simple: software you'd trust your own family and friends to use, engineered by someone who has spent 25 years learning exactly what it takes to earn that trust — and who automated the discipline so it never slips.