My tasks
As CTO I was responsible for conceiving and building the platform. The audience was broad and fitness trackers were in their infancy – that, combined with the technical limitations of parts of the audience, forced us to be creative with the solution.
Code, design and team
I wrote the Laravel code myself, did all the UX and design, and owned the technical architecture. Alongside that I ran a small, scalable team of Romanian and Armenian developers, where my job was to scope the work, brief the developers and review and assess their commits.
In practice it came to roughly 40% development and design, 40% operations and management, and 20% marketing – including social and email. That is startup life: the role is not what the business card says, it is whatever is left undone.
Wristbands and data
The technical core was the integration with the fitness wristbands. Every user got one, and the Lifeguard app pulled steps and sleep data out of the wristband's own ecosystem and passed them on to the platform. That sounds simple, but hardware is unreliable: bands go unworn, Bluetooth drops, batteries die. The calculation had to survive gaps in the data without handing the user a score that was obviously wrong.
The audience was broad, too. We sold to companies, not to technology enthusiasts, and a fair number of users had limited experience with apps. The onboarding had to carry someone who did not particularly want to be there.
The shop
We also sold hardware and subscriptions: Mi Band wristbands, body-composition scales and health packages running three, six or twelve months. It ran on Shopify, which I built and operated – first under Lifeguard, later under Reload – with the themes written in Liquid.
The trick was making it feel like one product. The shop sat inside the platform behind the same login and the same navigation, so the user never experienced leaving Lifeguard, even though two systems were technically in play. A purchase in Shopify had to become access in Laravel: order a health package and the subscription had to be activated, a coach assigned and the wristband shipped.
It looks trivial in a diagram. It never is in practice – least of all when a payment fails halfway and a user is left with a wristband but no login.
White label from day one
Six weeks after founding the company, the platform had to be able to carry a brand other than our own. That forced a separation of content, logic and identity I would otherwise have deferred – and which turned out to be the right call when the partnership with Dansk Sundhedssikring was dissolved and the source code had to be split.
GDPR
Regulation (EU) 2016/679 was adopted at almost the same moment we founded the company. We handled health data – the most sensitive category there is – and it is not an area where you can patch things up afterwards. It set the constraints for everything from the data model to who could see what.
The answer was to split access in two. The first consent was required to use the platform at all: it gave the company anonymised, pooled figures for the workforce as a whole – never for the individual. The second was optional and let the clinical advisers see personal data, so they could reach out to an employee heading for the red zone.
You could use the system without giving your employer any insight into your health, and you could decide for yourself whether you wanted help. That line was not a detail – it was the precondition for anyone daring to use the system at all.
The work was formalised. Lifeguard was among the very first companies to complete the full process and earn the D-seal – Denmark's certification for IT security and responsible data use, backed by the Danish Industry Foundation, the Confederation of Danish Industry and the Danish Business Authority. We were also selected for the Danish Design Centre's programme on the Digital Ethics Compass, on thinking about data and digital design responsibly.
Technically it rested on Laravel, where the framework supplies part of the security itself: hashed passwords, CSRF tokens, XSS protection. All data was encrypted – TLS in transit, AES-256 at rest – and access followed the Principle of Least Privilege, so no employee could see more than their role required. We ran SIEM monitoring around the clock and static code analysis on everything we deployed.
The GDPR documentation itself was produced under Vitalityguard, where we could afford to have the law firm Bech-Bruun at the table. When the partnership dissolved in 2018, the material did not come with us.
I rebuilt it from the ground up together with Thomas Bonefeld Jørgensen and Jan Lindquist from Unikk.me: data processing agreements, DPIA, master policy, IT operations policy, privacy and security policy. Without a lawyer this time – there was no budget. It forced me to understand the regulation rather than nod along to someone who had read it. A hard way to learn GDPR, but it sticks.
The chat was the worst of it. User and coach messaged each other inside the platform, and people tell someone they trust all sorts of things – divorces, illness, sleepless nights, things they have not told their employer. Structured data you can categorise and bound; free text you cannot. The messages had to be treated as the most sensitive part of the system regardless of what was actually in them.
