The setting
Health data is not a playground. In statutory health insurance there is no room for sloppy work: the bar for security, privacy, and accessibility is set externally and is non-negotiable. Nothing can be left to chance when it comes to customer health. Even more: In a regulated app the paper trail is part of the product.
My role
I co-owned the section around the bonus programme: technical design, implementation, and review. The work happened inside processes where security guidelines, accessibility requirements, and strict QA gates are baked into every step.
The calls that mattered
- Rewriring the central navigation component without affecting 3 other teams.
- Keeping personal health information strictly partitioned, in a way that is defensible in writing.
- Treating accessibility as a hard requirement from the first design conversation.
- Working with the QA and release processes instead of around them.
How it ended
The bonus programme section shipped inside the app’s regular release cadence and passed the gates it had to pass, including external security reviews. Without objections.
Why it matters here
Most scale-up iOS engineers have never shipped under compliance constraints. For any team in fintech, healthtech, or anything touching regulated data, knowing what “grown-up” practice looks like up close is the difference between a clean audit and a painful one.
