Jane McKay

I'm Jane McKay, an iOS developer and the founder of Forgeyard Digital. I spent eight years at Dyson — the vacuum company — building software for everything from connected appliances to internal tools. By the end I was a Senior Software Engineering Manager, leading teams and shipping products at scale.

I left to build apps for people who've been overlooked. The kind of work where getting it right genuinely matters.

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 build something genuinely useful for 5,000 people than build something mediocre that scales to millions. That means going deep on edge cases, consulting clinicians, caring about terminology. It's slower, but it's the work that matters.

I built it for myself. I was on HRT — oestrogen gel daily, progesterone capsules cyclically — and every reminder app I tried fell apart the moment the schedule got complicated. So I built one that understood cyclical regimens, doses at different times, patches vs gels vs pills.

I consulted practising NHS clinicians while building it to make sure the language was medically sound and the flows matched real prescribing patterns. It wasn't a side project that got lucky — it was deliberate, careful work, born from a real need.

It's now used by over 1,400 women, found entirely by word of mouth. That tells me it's solving a problem that was genuinely unmet.

Native first. SwiftUI, properly architected, fully tested. I don't ship prototypes — I ship software I'd bet my own data on.

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.

I call the aesthetic "Liquid Glass" — interfaces that feel calm, minimal, and trustworthy. No clutter, no dark patterns, nothing trying to trick you into engagement. Health apps should feel like a tool you trust, not a product managing you.

Because HRT in the UK is different from HRT in the US. Medications, dosing conventions, prescribing patterns — it's all different. An app built in California will use American terminology, American dose formats, and assume American healthcare norms.

I build here, for here. That means working with NHS clinicians, understanding NICE guidelines, using the language women actually hear in their GP surgery. It's not about nationalism — it's about shipping software that fits the reality people live in.

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.

I'm building a pipeline of health apps for overlooked groups. A parosmia tracker for people whose sense of smell has been distorted — often after COVID. A blood pressure log designed for people managing hypertension long-term. A developmental needs tracker for parents of children with SEN.

These are all in development, not launched yet. But the pattern is the same: find a group that's been ignored, understand their actual needs, and build something calm and trustworthy that solves the problem properly.

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.

The standards haven't dropped; the team size has. I still do architecture reviews — I just do them with myself, or with contracted reviewers. I still write comprehensive test suites — unit tests, snapshot tests, CI/CD pipelines. I still care about performance budgets, accessibility, and shipping software that won't embarrass me in a year.

The difference is I'm no longer managing competing priorities across multiple stakeholders. I can go deep on one problem, consult the right clinicians, test with real users, and ship when it's actually ready. The rigour is the same. The distractions are gone.

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 it's also alienating. Finding the line between clinically sound and actually human is hard. That's why I work with clinicians — not just for validation, but to learn how they talk to people, what metaphors land, what words build trust.

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.

I want people to look at a Forgeyard app and know: this was built carefully, by someone who understood the problem, for people who deserved better than what already existed.