Lifeguard – CTO and Co-founder 2015-2023

Summary

I built the LifeScore platform in Laravel with consent-based access to health data and an app for the wristband, and handled all UX and design.

Description

I was the Co-founder and CTO at Lifeguard Health ApS. The company made it to its seventh birthday.

The idea

My partner and lead investor Mikkel Nybo Andersen had stepped down from the management of ContentCPH and sold his stake. He had an idea about making people healthier, and he needed someone who could carry the digital side and actually build it. We had worked together at the agency, so he knew what he was getting.

In 2015 Mikkel spent more than six months researching the market. We then began working on the concept, and on 23 May 2016 we founded LifeGuard Health ApS with the aim of creating a comprehensive and preventive B2B health concept with a holistic focusing on health, well-being, and performance. Our research showed that companies were already offering fitness subscriptions to their employees, but they had not been successful in motivating and retaining employees in a health program.

Digitising the coach

We recognized the opportunity to combine the best of both worlds: the digital world with the physical coach. By "digitizing the coach", we could deliver a scalable solution where many of the classic coach tasks could be moved into the digital domain.

This allowed us to combine automation principles and gamification known from existing health apps with people, creating results through a personal relationship. In collaboration with Morten Zacho, we developed a "Health Calculator" that could issue a numerical overall value for users' health with the help of onboarding data and ongoing input from both users and digital devices. This health calculation laid the foundation for all healthcare content.

LifeScore

Working with Morten Zacho, at the time working alongside Bente Klarlund at the Centre for Active Health, we developed the health calculation that became LifeScore. From onboarding data and continuous input from the user and their connected devices it computed three sub-scores – FitScore, DietScore and MindScore – which together produced a single figure for the user's health. LifeScore underpinned every piece of health content on the platform: it told the user where they stood, and the coach where to intervene.

The figure translated into three zones – green, amber and red. In practice it was an early-warning system: an employee heading for red was caught while something could still be done, rather than surfacing as sick leave six months later. That is the whole difference between prevention and treatment, and it was what the companies were paying for.

The platform and the app

The platform itself was a Laravel web application with role-based access. Five roles logged into the same solution and each saw a different version of it: the user got their training sessions, their health score and their dialogue with the coach. The coach got an overview of their users and could set up programmes. The health care manager – a clinical adviser from the insurer – could see personal data on the users who had consented, and intervene. The company manager got reporting on the workforce as a whole, never on the individual. And the administrator held it all together.

One person could hold several roles and switch between them – a coach could also be a user. That sounds trivial, but it means permissions cannot hang on the user; they have to hang on the role you are logged in as. With health data in the system, that distinction is not academic.

Alongside it ran a mobile app, published on the App Store and Google Play. Its main job was not to be a second interface but to act as a bridge: it pulled data from the user's fitness tracker and passed it on to the platform, where it fed into the health calculation. Without that bridge the calculation was left with whatever the user typed in themselves – and self-reporting is notoriously optimistic.

Tested by 5,000

The algorithm and the coaching concept were beta-tested across user segments before launch. More than 5,000 Danes onboarded the first version and helped us calibrate the model – and it was that body of data that made the calculation credible enough to build a product on.

Vitalityguard

Six weeks after founding the company, a shortcut appeared. Together with Dansk Sundhedssikring we set up a joint venture, Vitalityguard, which resold the same platform to their customers under a different name and a different visual identity. The same codebase, the same LifeScore – a new identity on top. It forced us to build the platform white-label ready from the start, long before we could afford to think about architecture for its own sake.

The shortcut was their sales operation: Dansk Sundhedssikring already had the customers and the relationships, where we had the product and no sales force. It brought Maersk in as a client. The partnership was dissolved in 2018 over a disagreement about sales strategy, and we went our separate ways with a shared source code.

Reload and Berlingske Media

With covid having shut down B2B sales, we tried to compensate by going straight to the consumer market. We built a freemium platform – a free health test and health profile as a springboard for selling coaching – and struck an affiliate deal with Berlingske Media on a ”no cure, no pay” basis: we carried the development cost, they carried the media cost, with the tabloid BT as the main channel.

The traffic arrived. Over 100,000 visitors in a short space of time. The sales did not. After two months we put the project on hold.

The diagnosis was uncomfortable but clear: the audience did not match, and the media strategy was wrong. We had assumed reach alone would sell, and underestimated how much a recommendation from a person is worth against an advert in a publication. The platform itself survived, though, and large parts of it were reused in the core product – so the work was not wasted, only the business model.

The company

LifeGuard was far more than training; we also offered sleep and stress guidance with podcasts, videos, exercises, and coach dialog. At our peak, we had more than 25 employees – the Facebook page still stands as an archive of what we built. We had financial backing from the Growth Foundation and several investors, and were a part of the entrepreneurial environment of Health Tech Hub Copenhagen.

It was covid that broke the business. The market shut, and converting customers became close to impossible: budgets were uncertain, appetite for investment had gone, and the HR departments we sold to were busy holding together an organisation that had suddenly gone home. We had stretches of four to five months with no sales worth the name.

And when companies came back, they were somewhere else. Working from home had become normal, budgets had been rewritten, and wellbeing was something you discussed on Teams rather than something you invested in.

We kept it running for three years after the lockdown but never found our way back to growth. In December 2023 we had to declare Lifeguard bankrupt.

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.

Video

Gallery

Website

thehub.io/startups/lifeguard-health

Skills used

• Adobe
• Android Studio
• Apache/ NGINX
• Apple iWork
• Apple Xcode
• AppStore
• BitBucket
• Bootstrap
• CSS/ CSS3
• Data compliance (GDPR) + DPO
• Digital Ocean
• Final Cut Pro
• Forge
• Foto (DSLR) + Billed behandling (RAW)
• Google Play Console
• HTML/ HTML DOM/ HTML5
• Hubspot
• Illustrator
• Ionic
• Jira
• jQuery/ Javascript
• JSon
• Laravel
• LinkedIn Marketing Solution
• Liquid (Ruby)
• Mailchimp
• Meta Business Suite + Manager
• Microsoft 365
• Microsoft Azure
• MySQL
• Photoshop
• React Native
• Rest API
• Sass/SCSS
• SEM+SEO
• Shopify
• Slack
• Trello
• Vimeo
• XML
• Youtube

Customers