Lifeguard – CTO og Co-founder 2015-2023
Kort fortalt
Jeg byggede LifeScore-platformen i Laravel med samtykkestyret adgang til sundhedsdata, en app til armbåndet og stod for alt UX og design.
Beskrivelse
Jeg var Co-founder og CTO hos Lifeguard Health ApS. Virksomheden nåede at holde 7 års fødselsdag.
Idéen
Min partner og hovedinvestor Mikkel Nybo Andersen havde forladt ledelsen i ContentCPH og solgt sin ejerandel. Han havde en idé om at gøre folk sundere, og han manglede en, der kunne løfte det digitale og bygge den. Vi havde arbejdet sammen i bureauet, så han vidste, hvad han fik.
I 2015 brugte Mikkel over et halvt år på at researche markedet. Derefter begyndte vi at arbejde med konceptet, og den 23. maj 2016 stiftede vi LifeGuard Health ApS.
Ønsket var at skabe et forebyggende sundhedskoncept, udviklet til virksomheder, med henblik på at skabe sammenhæng mellem sundhed, trivsel og performance.
Der var en stigende fokus på medarbejder-trivsel og -sundhed og mange virksomheder tilbød allerede fitness-abonnementer til deres medarbejdere.
Men livsstilsændringer tager tid, og man havde ikke knækket koden i forhold til at motivere og fastholde medarbejderne i et sundhedsforløb.
De gode resultater kom først med personlige coaches, der udover sparring også kunne motivere og fastholde medarbejderne. Men prispunktet var ofte for højt og for store, og mellemstore, virksomheder var løsningen ikke skalerbar.
Strøm på coachen
Derfor så vi muligheden for at kombinere det bedste for to verdener. Den digitale verden med den fysiske coach. Hvis vi kunne ”sætte strøm på coachen”, kunne vi levere en mere skalerbar løsning, hvor mange af de klassiske coach-opgaver kunne flyttes over i det digitale domæne.
Derved kunne vi kombinere de gængse automatiseringsprincipper og gamification kendt fra eksisterende sundheds-apps med mennesker. Værdien af den personlige relation skaber resultater.
Samtidig kunne vi, gennem digital dialog og sundheds-IOT’s, måle effekten, tilpasse handlingsforløbet og afrapportere udviklingen tilbage til virksomheden alt imens vi fastholdt en personlig, motiverende relation til brugeren gennem coachen.
LifeScore
I samarbejde med Morten Zacho, som på daværende tidspunkt sad med Bente Klarlund på Center for Aktiv Sundhed, udviklede vi den sundhedsberegning, der blev til LifeScore. Ud fra onboarding-data og løbende input fra brugeren og de tilkoblede devices beregnede den tre delscorer – FitScore, DietScore og MindScore – som tilsammen gav ét samlet tal for brugerens sundhed. LifeScore lagde grunden for alt sundhedsfagligt indhold på platformen: den fortalte både brugeren, hvor vedkommende stod, og coachen, hvor der skulle sættes ind.
Tallet blev oversat til tre zoner – grøn, gul og rød. I praksis var det et early warning-system: en medarbejder på vej mod rød blev fanget, mens der stadig kunne gøres noget, i stedet for at dukke op som en sygemelding et halvt år senere. Det er hele forskellen mellem forebyggelse og behandling, og det var dét, virksomhederne betalte for.
Med digital onboarding, løbende opfølgning på brugernes fremskridt, samt brug af intelligente anbefalinger fra platformen, skabtes grundlaget for effektiv dialog mellem bruger og coach.
Og med 2.500 unikke niveauinddelte træningspas indenfor styrketræning (hjemme eller i center), Yoga, gang/løb, svømning og cykling, videoguides og live fællestræning kunne vi sikre en høj grad af individualisering og et højt engagement.
LifeGuard var dog langt mere end træning. På den mentale side tilbød vi bl.a. søvn og stress-guidance med podcasts, videoer, øvelser og coachdialog.
Platformen og appen
Selve platformen var en webapplikation i Laravel med rollestyret adgang. Fem roller loggede ind i den samme løsning og så hver deres udgave af den: brugeren fik sine træningspas, sin sundhedsscore og sin dialog med coachen. Coachen fik overblik over sine brugere og kunne lægge forløb. Health care manageren – en sundhedsfaglig rådgiver fra forsikringsselskabet – kunne se personlige data på de brugere, der havde givet lov, og gribe ind. Company manageren fik afrapportering på medarbejdergruppen som helhed, aldrig på den enkelte. Og administratoren holdt sammen på det hele.
Én person kunne have flere roller og skifte mellem dem – en coach kunne selv være bruger. Det lyder trivielt, men det betyder, at rettigheder ikke kan hænge på brugeren, men skal hænge på den rolle, man er logget ind som. Med sundhedsdata i systemet er den skelnen ikke akademisk.
Dertil kom en mobilapp, udgivet i App Store og Google Play. Dens vigtigste opgave var ikke at være et andet interface, men at fungere som bro: den hentede data fra brugerens fitness-armbånd og sendte dem videre til platformen, hvor de indgik i sundhedsberegningen. Uden den bro var beregningen henvist til det, brugeren selv indtastede – og selvrapportering er notorisk optimistisk.
Testet af 5.000
Algoritmen og coach-konceptet blev betatestet på tværs af brugersegmenter, inden vi gik i luften. Mere end 5.000 danskere nåede at onboarde den første version og hjælpe os med at kalibrere modellen – og det var dét datagrundlag, der gjorde beregningen troværdig nok til at bygge et produkt på.
Vitalityguard
Seks uger efter stiftelsen lå der en genvej på bordet. Sammen med Dansk Sundhedssikring oprettede vi et joint venture, Vitalityguard, som solgte den samme platform videre til deres kunder under et andet navn og et andet grafisk udtryk. Samme kodebase, samme LifeScore – ny identitet ovenpå. Det tvang os til at bygge platformen white label-klar fra begyndelsen, længe før vi havde råd til at tænke i arkitektur for arkitekturens skyld.
Genvejen var deres salgsapparat: Dansk Sundhedssikring havde allerede kunderne og relationerne, hvor vi havde produktet og ingen sælgere. Det bragte Mærsk ind som kunde. Samarbejdet blev opløst i 2018 over uenighed om salgsstrategien, og vi gik hver til sit med delt kildekode.
Reload og Berlingske Media
Da corona lukkede B2B-salget ned, forsøgte vi at kompensere ved at gå direkte til privatmarkedet. Vi byggede en freemium-platform – gratis sundhedstest og sundhedsprofil som springbræt til salg af coaching – og indgik et affiliate-samarbejde med Berlingske Media under et ”no cure, no pay”-princip: vi lagde udviklingen, de lagde medietrykket, med BT som hovedkanal.
Trafikken kom. Over 100.000 besøgende på kort tid. Salget kom ikke. Efter to måneder satte vi projektet på pause.
Diagnosen var ubehagelig, men klar: målgruppen matchede ikke, og mediestrategien var forkert. Vi havde regnet med, at rækkevidde i sig selv ville sælge, og undervurderet hvor meget en anbefaling fra en person betyder frem for en annonce i et medie. Teknisk stod platformen dog tilbage, og store dele af den blev genbrugt i kerneforretningen – så arbejdet var ikke spildt, kun forretningsmodellen.
Virksomheden
Da vi var på det højeste, havde vi mere end 25 ansatte, og Facebook-siden står stadig som et arkiv over, hvad vi lavede. Vi var del af iværksættermiljøet Health Tech Hub Copenhagen og havde økonomisk opbakning fra Vækstfonden og en række investorer.
Det var corona, der knækkede forretningen. Markedet lukkede i, og det blev nærmest umuligt at konvertere kunder: budgetterne var usikre, investeringslysten væk, og HR-afdelingerne – dem vi solgte til – havde travlt med at holde sammen på en organisation, der pludselig sad hjemme. Vi havde perioder på fire-fem måneder uden salg af betydning.
Og da virksomhederne kom tilbage, var de et andet sted. Hjemmearbejde var blevet normalt, budgetterne var lagt om, og trivsel var noget, man talte om på Teams frem for noget, man investerede i.
Vi holdt den kørende i tre år efter nedlukningen, men fandt aldrig tilbage til væksten. I december 2023 måtte vi erklære Lifeguard konkurs.
Mine opgaver
Jeg havde, i rollen som CTO, ansvaret for at udtænke og bygge platformen. Målgruppen var bred, og fitness-trackere var i deres tidlige barndom – det, kombineret med de tekniske begrænsninger hos dele af målgruppen, tvang os til at være kreative med løsningen.
Kode, design og team
Jeg kodede selv i Laravel, tegnede alt UX og design, og stod for den tekniske arkitektur. Sideløbende havde jeg et lille, skalerbart team af rumænske og armenske udviklere, hvor min opgave var at scope opgaverne, briefe udviklerne og løbende gennemgå og evaluere deres commits.
I praksis blev det til omkring 40% udvikling og design, 40% drift og ledelse, og 20% marketing – herunder SoMe og e-mail marketing. Det er vilkårene i en startup: rollen er ikke det, der står på visitkortet, men det, der mangler at blive gjort.
Armbånd og data
Den tekniske kerne var integrationen med fitness-armbåndene. Vi udleverede et armbånd til hver bruger, og Lifeguard-appen hentede skridt og søvndata fra armbåndets eget økosystem og sendte dem videre til platformen. Det lyder enkelt, men hardware er upålideligt: armbånd bliver ikke båret, Bluetooth mister forbindelsen, batterier løber tør. Beregningen skulle kunne stå imod huller i data uden at give brugeren en score, der var åbenlyst forkert.
Samtidig var målgruppen bred. Vi solgte til virksomheder, ikke til teknologientusiaster, og en del af brugerne havde begrænset erfaring med apps. Onboardingen måtte kunne bæres af nogen, der ikke havde lyst til at være der.
Webshoppen
Vi solgte også hardware og abonnementer: Mi Band-armbånd, kropsanalysevægte og sundhedspakker på tre, seks eller tolv måneder. Det kørte på Shopify, som jeg byggede og drev – først i Lifeguard-regi, senere under Reload – med temaerne skrevet i Liquid.
Kunsten var at få det til at føles som ét produkt. Shoppen lå inde i platformen bag samme login og samme navigation, så brugeren aldrig oplevede at forlade Lifeguard, selv om der teknisk set var to systemer i spil. Et køb i Shopify skulle blive til adgang i Laravel: bestilte man en sundhedspakke, skulle abonnementet aktiveres, en coach tildeles og armbåndet sendes.
Det ser trivielt ud i et diagram. Det er det aldrig i praksis – især ikke når en betaling fejler halvvejs, og en bruger sidder med et armbånd, men ingen adgang.
White label fra dag ét
Seks uger efter stiftelsen skulle platformen kunne bære et andet brand end vores eget. Det tvang en adskillelse mellem indhold, logik og identitet, som jeg ellers ville have udskudt – og som viste sig at være det rigtige valg, da samarbejdet med Dansk Sundhedssikring blev opløst, og kildekoden skulle deles.
GDPR
Forordning (EU) 2016/679 blev vedtaget stort set samtidig med, at vi stiftede selskabet. Vi håndterede sundhedsdata – den følsomste kategori der findes – og det er ikke et område, hvor man kan rette op bagefter. Det satte rammer for alt fra datamodel til hvem der kunne se hvad.
Løsningen var at dele adgangen i to. Det første samtykke var påkrævet for overhovedet at bruge platformen: det gav virksomheden adgang til anonymiserede, poolede tal for medarbejderstanden som helhed – aldrig til den enkelte. Det andet var frivilligt og gav de sundhedsfaglige rådgivere lov til at se personlige data, så de kunne tage fat i en medarbejder på vej mod rød zone.
Man kunne altså bruge systemet uden at give sin arbejdsgiver indsigt i sit helbred, og man kunne selv vælge, om man ville have hjælp. Den grænse var ikke en detalje – den var forudsætningen for, at nogen turde bruge systemet overhovedet.
Arbejdet blev formaliseret. Lifeguard var blandt de allerførste virksomheder, der gennemgik hele forløbet og blev D-mærket – Danmarks mærkningsordning for it-sikkerhed og ansvarlig dataanvendelse, som Industriens Fond, DI, Dansk Erhverv og Erhvervsstyrelsen står bag. Vi blev desuden udvalgt til Danish Design Centers læringsforløb om Det Digitale Etikkompas, som handlede om at tænke data og digitalt design ansvarligt.
Teknisk hvilede det på Laravel, hvor rammeværket selv leverer en del af sikkerheden: hashede kodeord, CSRF-tokens, XSS-beskyttelse. Al data blev krypteret – TLS i transit, AES-256 i hvile – og adgangen var styret efter Principle of Least Privilege, så ingen medarbejder kunne se mere, end deres funktion krævede. Vi kørte SIEM-overvågning døgnet rundt og statisk kodeanalyse på alt, der blev deployet.
Selve GDPR-dokumentationen blev udarbejdet i Vitalityguard-regi, hvor vi havde råd til at have advokatfirmaet Bech-Bruun med om bordet. Da samarbejdet blev opløst i 2018, fulgte materialet ikke med.
Jeg byggede det op igen fra bunden sammen med Thomas Bonefeld Jørgensen og Jan Lindquist fra Unikk.me: databehandleraftaler, DPIA, master policy, IT-driftspolitik, privatlivs- og sikkerhedspolitik. Uden advokat denne gang – der var ikke råd. Det tvang mig til at forstå forordningen frem for at nikke til en, der havde læst den. En hård måde at lære GDPR på, men den sidder.
Værst var chatten. Bruger og coach skrev sammen i platformen, og folk skriver om alt muligt til en, de har tillid til – skilsmisser, sygdom, søvnløshed, ting de ikke har fortalt deres arbejdsgiver. Struktureret data kan man kategorisere og afgrænse; fri tekst kan man ikke. Beskederne skulle behandles som den mest følsomme del af systemet, uanset hvad der stod i dem.
Video
Galleri
Website
Kompetencer benyttet
- Adobe
- Android Studio
- Apache/ NGINX
- Apple iWork
- Apple Xcode
- App Store
- 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
- 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
