This is a portfolio case study by Forgeyard Digital. For product details and to download HRTMe, visit hrt-me.com.
The challenge
Building a regimen engine that ordinary reminder apps can't
HRT regimens are genuinely complex: oestrogen gel daily, plus micronised progesterone capsules on alternating weeks, or a combined patch that changes strength mid-cycle. These are cyclical and phased schedules that ordinary reminder apps — built for "once daily" or "every 12 hours" medications — simply can't model.
The technical challenge: design a domain model that represents regimens as first-class entities (not just repeating alarms), calculates due times for multi-phase schedules, tracks cycle position, and remains fully testable independent of the UI layer.
With around 2.8 million women in England prescribed HRT and 14.7 million items dispensed in 2024/25, the scale of need was clear — but no existing app solved the underlying modelling problem.
What we built
Domain-driven architecture for a testable regimen engine
Regimen as a domain entity
We modelled HRT regimens as first-class domain entities — not just repeating timers. Each regimen encapsulates medication details (brand, strength, form), phase schedules (daily/cyclical/sequential), and due-time calculation logic. The domain layer is pure Swift: no UIKit, no SwiftUI, no framework dependencies. This meant we could write comprehensive unit tests for regimen logic independent of the UI.
Guided setup wizard with 72 UK brands
We mapped 72 UK HRT brands (Evorel patches, Oestrogel, Utrogestan capsules, etc.) into a structured medication catalogue. The setup wizard guides users through brand selection, strength configuration, and schedule building in plain language. Behind the scenes, the wizard constructs a regimen domain object that's validated before persistence.
Privacy-first architecture decision
We made an early architectural choice: all data stays on-device. iCloud backup is opt-in and syncs only to the user's own account. This ruled out cloud-based features (collaborative care plans, server-side analytics) but aligned with our privacy-first stance. No user accounts, no server-side storage, zero health data sent via analytics. The trade-off: simpler security model, higher user trust, lower infrastructure cost.
Apple Watch companion via CloudKit sync
The Watch app syncs via CloudKit (not a custom backend). Quick logging from the wrist: mark a dose as taken, log a symptom, see what's due today. The sync layer handles conflicts (last-write-wins for events, merge-by-union for symptom logs) and ensures consistency across devices without a server.
How we built it
Clean Architecture, Domain-Driven Design, and comprehensive testing
Architecture: Domain → Application → Presentation → Infrastructure
We structured the codebase using Clean Architecture principles. The domain layer (pure Swift, no UIKit/SwiftUI) contains regimen entities, value objects, and business rules. The application layer holds services and repositories. The presentation layer is SwiftUI views and view models. Infrastructure handles external integrations (notifications, CloudKit). This separation meant the core regimen logic could be tested in isolation and evolved without breaking the UI.
Why Domain-Driven Design?
HRT regimens are complex domain concepts with rich business rules (phase transitions, cycle position tracking, due-time calculation). DDD gave us a vocabulary (regimen, phase, schedule, dose event) that matched how clinicians and users think about HRT. The domain model is the source of truth; the UI is a projection. This made the codebase easier to reason about and safer to refactor.
Comprehensive test coverage: unit + snapshot
Every screen is covered by snapshot tests — when we refactor or add features, the tests catch visual regressions before they ship. Unit tests cover the domain model (regimen calculations, phase logic, due-time rules). We run the full suite before every commit. The test-first approach meant we caught edge cases (leap years, time zone changes, cycle boundary overlaps) during development, not in production.
Validated with NHS clinician input
We consulted practising NHS clinicians during development to ensure the app's language, dosing patterns, and medical framing were accurate and appropriate. Forgeyard Digital is not NHS-affiliated; the clinical input shaped terminology and guidance to match real-world prescribing patterns and NICE NG23 recommendations for menopause management.
Challenges & decisions
Key architectural decisions and trade-offs
Modelling cyclical regimens as a testable domain model
The hardest engineering problem: representing "oestrogen daily, progesterone days 15–28, repeat" as a domain model that could calculate due times, track cycle position, and handle edge cases (leap years, DST transitions, mid-cycle edits). We rejected a calendar-based approach (too fragile) and alarm-based approach (couldn't represent phase logic). Instead, we built a regimen entity with embedded phase rules and a due-time calculator that derives the schedule from first principles. This meant more upfront design work, but the result was fully testable and correct-by-construction.
Privacy-first vs cloud sync trade-off
Early decision: on-device storage only, with opt-in iCloud sync (not a custom backend). This ruled out features like server-side analytics, collaborative care plans, or web dashboards. The trade-off: simpler security model, no server costs, higher user trust, and compliance with health data privacy expectations. We chose trust over features.
Why SwiftUI for a health-critical app?
SwiftUI was still maturing when we started (iOS 16 minimum). We chose it anyway: faster iteration cycles, declarative UI, and snapshot testing support. The risk: occasional framework bugs and workarounds. The payoff: we shipped UI updates in hours, not days, and snapshot tests caught regressions that manual QA would have missed.
What we achieved
Real outcomes: 1,400+ users, 81 App Store ratings, 100% organic
HRTMe launched with no marketing budget and no paid advertising. Every user found it organically — through the App Store, word of mouth, or online menopause communities. The 81 App Store ratings reflect the engineering quality: we handled real-world complexity (cyclical regimens, edge cases, cross-device sync) with calm, trustworthy design.
User feedback highlights the architecture paying off: "the only reminder app that actually works for my HRT", "exactly what I needed". We solved a problem other apps ignored — and the domain model made it possible.
Visit the HRTMe website to learn more, or read the HRTMe FAQ for common questions about using the app.