Bandits Inc.

Som det fremgår af forrige sektion, har jeg gennem årene beskæftiget mig med en bred vifte af opgaver og indtaget mange forskellige jobroller, lige fra lydtekniker til fotograf, grafiker, webudvikler og CTO. Gennemgående for dem alle har været min passion for at skabe meningsfulde oplevelser og min drivkraft for at skabe noget unikt.

I min tilgang har jeg altid været åben over for at udforske nye løsninger til eksisterende udfordringer og har aldrig været bange for at tilegne mig ny viden. Dette har resulteret i en bred vifte af kompetencer, som jeg har sammensat over tid.

Jeg har her forsøgt at liste de væsentligste.

Jeg er født og opvokset i København. Men efter nogle år med børn i lejlighed på Østerbro, valgte min kæreste og jeg at flytte i hus. Vi bor i Hellerup på 11. år, men ikke længere væk fra København end man kan hoppe op på cyklen og så er man tilbage.

Sidstnævnte gør jeg ofte - det handler om inspiration og nye designindtryk. Jeg forsøger af samme grund stadig at finde tid til fototure. Men da mit arbejde altid har været min hobby, har det været en udfordring at finde balance mellem tid til både fritidsprojekter og arbejdsprojekter.

Når jeg ikke arbejder bruger jeg en del tid med at spiller og lytte til musik. Desværre er det med tiden mest blevet til lytning, hvilket har været en meget dyr, men også givtig passion.

Fælles for alle mine passioner er ønsket om af skabe noget - jeg håber at dette kan komme jer til gode.

Se TT38 profil

Behovet for ESG-rapportering voksede markant i takt med nye EU-krav og stigende fokus på dokumentation af virksomheders miljømæssige, sociale og ledelsesmæssige forhold. Mange virksomheder stod pludselig overfor omfattende rapporteringskrav uden nødvendigvis at have interne ressourcer eller specialister til at håndtere opgaven.

I forsommeren 2024 blev jeg kontaktet af tre personer, som arbejdede med idéen bag ESGRapporter. De manglede det tekniske fundament og en profil med erfaring indenfor digitale platforme, UX og produktudvikling. Jeg blev anbefalet til rollen af en tidligere investor fra Lifeguard Health ApS, og den 29. juli 2024 stiftede vi ESGRapporter ApS.

Kravene

Kravene kom med CSRD-direktivet og den tilhørende ESRS-standard. Først ramte kravene de store børsnoterede selskaber, men effekten forplantede sig hurtigt nedad: en stor virksomhed skal rapportere på hele sin værdikæde, og pludselig fik dens underleverandører et spørgeskema i indbakken, de ikke kunne svare på. En mindre produktionsvirksomhed med tredive ansatte havde hverken en bæredygtighedsafdeling eller budget til et konsulenthus – men den havde en kunde, der forlangte tallene.

Hullet i markedet

Markedet var allerede præget af løsninger med fokus på dataindsamling, compliance og enterprise-segmentet. Men vi så et hul i markedet: Der fandtes næsten ingen brugervenlige løsninger, hvor almindelige virksomheder og lægfolk selv kunne udarbejde en ESG-rapport uden at være eksperter i ESG, lovgivning eller rapportstruktur.

Visionen bag ESGRapporter var derfor at skabe en slags “ESG for dummies” — en platform hvor brugeren trin-for-trin kunne opbygge sin rapport gennem en mere intuitiv proces og samtidig få mulighed for at præsentere indholdet i et visuelt mere professionelt og præsentabelt format. Målet var at gøre ESG-rapportering forståeligt og tilgængeligt for virksomheder uden specialiseret ESG-viden.

Projektet trak på mange af de erfaringer jeg tidligere havde opbygget gennem arbejdet med komplekse platforme, onboarding-forløb og brugercentreret digital produktudvikling.

Mine opgaver

Jeg havde det overordnede tekniske ansvar for retningen: hvilken vej platformen skulle gå, og hvad der skulle bygges hvornår.

Konkret stod jeg for det grafiske design, rapportdelen og alt det visuelle – bygget i Laravel, med informationsstruktur og brugerflows. Admin-modulet blev bygget af min kollega Samuel – dels for at aflaste mig, dels fordi han havde mange års erfaring med Laravel.

En stor del af arbejdet handlede om at omsætte komplekse rapporteringskrav og abstrakte ESG-begreber til konkrete og brugervenlige workflows. Dette omfattede blandt andet onboarding, dynamiske formularforløb, rapportstruktur, eksportfunktioner og præsentationsdesign.

Vi brugte AI til at hjælpe brugeren med at formulere og forbedre beskrivende tekst i rapporten på baggrund af brugerens egne input. Formålet var ikke at automatisere ESG-rapporteringen fuldt ud, men at gøre skriveprocessen mere tilgængelig for brugere, der ikke selv var vant til at formulere rapporttekst.

Projektet krævede både teknisk forståelse, produktforståelse og evnen til at balancere compliance, design, brugervenlighed og forretningsmæssige hensyn.

Jeg startede hos Revolvo ApS medio 2024 som Senior Developer med ansvar for udvikling, UI/UX og grafisk identitet. Omkring 60% af tiden gik til BmyGuest og IDoMeetings – to selskaber, Revolvo var medejer af – mens resten lå hos bureauets egne kunder.

Rollen lå på tværs af de discipliner, der normalt er delt mellem flere hoveder: grafisk identitet og design i den ene ende, frontend og backend i den anden, med UX, teknisk analyse og fejlfinding imellem. En stor del af arbejdet lå oven på etablerede systemer, hvor både den eksisterende kodebase, kundens forretning og behovet for løbende forbedringer skulle gå op i en højere enhed.

Hos Revolvo arbejdede jeg blandt andet med digitale løsninger for kunder som Egon, IDoMeetings, BmyGuest, ebillet samt Formula Auto (Demo). Opgaverne krævede en pragmatisk tilgang, hvor jeg ofte skulle kombinere teknisk eksekvering med hurtig forståelse for brugeroplevelse, drift og kommercielle hensyn.

Stakken skiftede fra kunde til kunde – WordPress det ene sted, Umbraco eller Magento det næste – så en del af jobbet var at kunne skifte kontekst uden at tabe fart. Det trak på erfaringer med SEO, performance, designsystemer og API-integrationer.

Ingen greenfield

Det er et vilkår i bureaubranchen, som sjældent bliver sagt højt: man arver kode, man ikke har skrevet, til systemer, man ikke har valgt, for kunder, hvis forretning man skal forstå på en uge. Der er ingen greenfield. Der er en kodebase, en historik og en deadline.

Det passede mig fint. Efter tyve år er den interessante del sjældent at bygge noget nyt fra bunden, men at finde ud af, hvorfor det eksisterende ikke virker, og hvad der skal til for at rette det uden at vælte noget andet. Det kræver, at man kan læse fremmed kode hurtigt, og at man tør sige fra, når kunden beder om noget, der teknisk set er en dårlig idé.

C#, .NET og Umbraco

Egon.no kørte på Umbraco, og det betød C# og .NET – en stak, jeg ikke havde arbejdet i før. Efter mere end tyve år i PHP var det en påmindelse om, at et sprog er til at lære; det er domænet og kodebasen, der tager tid. Jeg tog opgaven, fordi kunden lå der, og fordi et statisk typet sprog og en anden måde at tænke arkitektur på er værd at have prøvet.

AI som værktøj

Det var også her, jeg begyndte at bruge AI i det daglige arbejde – først ChatGPT, siden Claude, integreret direkte i VS Code og i mit git-flow. Ikke til at skrive kode, jeg ikke forstår, men til det, som en ny stak koster mest tid på: at læse fremmed kode, komme hurtigt ind i et ukendt framework og få et modspil, når en fejl ikke vil vise sig. Det er blevet en fast del af værktøjskassen på linje med en debugger.

Rollen passede godt til min profil, fordi den krævede både bred teknisk erfaring og evnen til hurtigt at sætte sig ind i forskellige kunders løsninger, arbejdsgange og tekniske begrænsninger.

Mine opgaver

Opgaverne var kundeopdelte, og hver kunde havde sin egen stak og sit eget efterslæb. Her er nogle af dem, jeg brugte mest tid på.

Egon

Implementerede nyt design og var med til at bygge medlemsportalen og bestillingsflowet, som dækker kædens 45 restauranter i Norge. Skrev frontend-filerne og ryddede op i CSS og UX undervejs – sitet kører på Umbraco, så det foregik i C# og .NET.

IDoMeetings

Byggede deres hjemmeside og ryddede op i frontend-stakken. IDoMeetings sælger en platform videre til deres egne kunder, så templaten skal kunne bære mange forskellige identiteter uden at blive gaflet i én version per kunde. Jeg udviklede nye templates og funktioner – blandt andet et dashboard, hvor personalet ser alle rum og deres status på ét kort.

BmyGuest

Den bredeste opgave: grafisk identitet, design, UX og kode – frontend såvel som backend. Som hos IDoMeetings er slutproduktet en template, hver kunde får sin version af, så designet skulle være fleksibelt nok til at rumme dem alle og stramt nok til stadig at ligne noget.

ebillet

Designede og kodede de views og partials til de portaler, ebillet stiller til rådighed for deres kunder. 90 biografer kører deres billetsalg på systemet. Umbraco igen.

Formula Auto

Startede som en ren designopgave – design og UX til den europæiske afdeling af Spares.net – og blev til en fuld Magento 2-template med opsatte sider. Samme opgave fulgte for sparesusa.net. Det site er ikke i luften endnu, så linket peger på mit demosite.

To maskiner, to verdener

Den største omvæltning var ikke sproget, men konteksten. Egon og ebillet krævede .NET, altså PC og Visual Studio; resten kørte på min sædvanlige stak – Mac med LAMP/LEMP.

At skifte mellem de to maskiner flere gange om dagen kostede mere opmærksomhed end selve C#-koden. Hver har sine genveje, sine værktøjer og sin egen måde at gøre tingene på.

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.

Seks uger efter at vi havde stiftet Lifeguard, oprettede vi et joint venture-selskab sammen med Dansk Sundhedssikring. Aftalen var altså på plads, nærmest før vores eget selskab var kørt i gang. Formålet var at levere Lifeguards ydelser og platform til Dansk Sundhedssikrings kunder som en white label-løsning, vi kaldte Vitalityguard.

Teknisk set var Vitalityguard den samme platform som Lifeguard. Samme kodebase, samme LifeScore-beregning, samme coach-flow – men et helt andet grafisk udtryk ovenpå. Det er en billig måde at ramme et nyt marked på, men det kræver, at platformen er bygget, så identiteten kan skiftes ud uden at koden forgrener sig i to. Det var også dét, der senere gjorde det muligt at dele kildekoden, da samarbejdet blev opløst.

Dansk Sundhedssikring var på daværende tidspunkt den nye i markedet og havde vokset hurtigt gennem en aggressiv salgsstrategi. Vi vækstede sammen og jeg oplevede at få tilført flere ressourcer til udvikling. Samtidig fik vi stillet Back Office til rådighed – med alt hvad dette gav af muligheder for at fokusere på kerneopgaver.

I praksis betød dette, at Lifeguards udvikling og roadmap blev overført til Vitalityguard. Det er værd at stå ved: vi flyttede vores eget produkts retning ind i et selskab, vi kun ejede halvdelen af.

Det er den skjulte pris ved et joint venture. Man får adgang til et salgsapparat, man ikke selv kunne bygge, og til ressourcer, en bootstrappet startup ikke har råd til – men man betaler med kontrollen over, hvad der bliver bygget hvornår. Så længe begge parter vil det samme, mærker man det ikke. Det er først, når de ikke gør, at prisen bliver synlig.

My Energy

Der gik ikke længe, før vi fik Mærsk ombord. Med en kunde af den størrelse fulgte krav til sikkerhed og dokumentation, som løftede platformen – og en helt anden skala i onboardingen.

Til at bære det udad udarbejdede vi en fælles kommunikationsstrategi, vi kaldte MyEnergy.

Navnet holdt længere end vi gjorde. Mærsk kørte MyEnergy videre som paraply for hele deres sundhedsindsats – stadig sammen med Danica Pension – og fik senere bygget et selvstændigt intranet på brandet. Det er tilfredsstillende på en stille måde: platformen er væk, men konceptet holdt.

Modellen på prøve

Zonesystemet og den todelte samtykkemodel var arvet fra Lifeguard, men det var her, de blev sat på prøve. Danicas healthcare managers var dem, der handlede på det frivillige samtykke: de kunne se personlige data på de medarbejdere, der havde givet lov, og tage fat i dem, der var på vej mod rød zone. Mærsk fik kun de anonymiserede tal for medarbejderstanden som helhed.

Det var en model, der kun holder, hvis alle tre parter respekterer den. En arbejdsgiver, der presser på for at se den enkeltes tal, ville have væltet hele konstruktionen. Det skete ikke – og det var, ærligt talt, den vigtigste forudsætning for, at nogen overhovedet turde melde sig til.

Opsplitning

Det gik godt i to år. Så begyndte vi at trække i hver sin retning.

Dansk Sundhedssikring ville bygge bredt og langsomt: flere features, større kunder, en platform der kunne bære hele deres portefølje. Vi ville sælge det, vi allerede havde, til dem der ville købe det nu. Hver gang roadmappet skulle prioriteres, stod de to ønsker over for hinanden – og roadmappet lå i det fælles selskab.

Uenigheden handlede om salgsstrategi, men bag den lå to forskellige økonomiske virkeligheder. Dansk Sundhedssikring havde kapital i ryggen og kunne tåle at bygge langsomt mod et større marked. Lifeguard var bootstrappet og skulle tjene penge nu – ikke om to år. Ingen af os havde uret; vi havde bare ikke råd til det samme.

I 2018 blev Vitalityguard splittet op. Der blev lavet en aftale om delt kildekode, og vi forlod samarbejdet med en pose penge til at køre Lifeguard videre. Det var en ordentlig afslutning – ingen retssag, ingen låst kodebase – og det var kun muligt, fordi platformen fra begyndelsen var bygget, så identiteten kunne skilles fra logikken.

To år senere lukkede corona det marked, vi havde skændtes om.

Mine opgaver

Rollen var den samme som i Lifeguard: jeg kodede i Laravel, tegnede UX og design, og ledede udviklerteamet. Platformen var jo den samme. Det, der ændrede sig, var hvem der stillede kravene.

VitalitySync

Appen fulgte samme white label-logik som platformen: hos Lifeguard hed den Lifeguard-appen, her hed den VitalitySync. Opgaven var den samme – at bygge bro. Kæden var lang: armbåndet snakkede kun med producentens egen app, Mi Fit, og derfra skulle skridt og søvndata videre ind i vores platform. VitalitySync sad i midten og oversatte.

Mærsk

Med Mærsk fulgte et sikkerhedsregime, vi ikke havde mødt før. Vi fik omkring en måned til at leve op til – og dokumentere – en række krav, der lå langt over, hvad vi selv havde stillet os. Det var ubehageligt, men det var også dét, der løftede platformen: kravene fra en kunde af den størrelse er en gratis sikkerhedsrevision, hvis man tager dem alvorligt.

Samtidig skulle vi onboarde store medarbejdergrupper på én gang. Det stiller andre krav end at tage én bruger ad gangen: både til teknikken og til den digitale support, der skal fange dem, der går i stå.

GDPR

Forordning (EU) 2016/679 blev vedtaget nærmest samtidig med, at vi stiftede selskabet, og vi havde to år til at blive compliant. Det arbejde foregik her, i Vitalityguard-regi, hvor vi havde råd til at have advokatfirmaet Bech-Bruun med om bordet.

Vi tænkte persondatabeskyttelse og privatliv ind i forretningsprocesser, værdikæde og produktlivscyklus, og byggede et teknisk setup, der understøttede det. Det var grundigt, det var dyrt, og det var pengene værd – ikke mindst fordi Mærsk kom ind kort efter og stillede krav, vi ellers ikke havde kunnet svare på.

Ressourcer

Til gengæld fik vi noget, en bootstrappet startup sjældent har: flere udviklerressourcer og en back office, der tog administrationen. Det er svært at overvurdere, hvad det betyder ikke selv at skulle stå for bogføring og fakturering, når man er den, der også skal skrive koden.

ContentCPH var et kreativt bureau. Men lidt af en bastard. En hybrid mellem et reklame-, media-, digital- og aktiverings-bureau.

ContentCPH havde, siden 2006, prædiket, at kunderne burde fokusere mere på at skabe forbruger-involvering via relevant indhold. Det handlede om at levere nye kanaler til målgrupper og begivenheder.

Jeg blev i 2008 hentet ind som ekstern flash-programmør og grafiker. I 2009 intensiverede vi samarbejdet, og efter et år havnede jeg som fastansat digital udvikler med ansvar for udvikling af digitalt indhold.

Sociale medier

Tilbage i 2010 var brugen af sociale medier voksende. Vi havde tidligere (2008) benyttet MySpace til aktivering af Tiger Beer iPod Battle.

Men i 2010 var Facebook den store i klassen. Dette betød at vi i stor grad havde fokus på aktivering på Facebook. Når tv-seeren havde set det seneste afsnit af ”Herre i eget Hus” eller ”Masterchef”, blev de inviteret over på Facebook, hvor de kunne interagere med programmets indhold eller tilmelde sig roadshow med henholdsvis IKEA eller Kvik-køkkener m.fl. eller konkurrere om deltagelsen til næste års Masterchef.

I denne periode fik vi også Hennes & Mauritz ombord og sammen afviklede vi i 2011-2013 Reboot Camp på Roskilde Festivalen.

Samsung og Nik & Jay

Vi havde et fortløbende og succesfyldt samarbejde med Samsung Danmark. Blandt andet lancerede vi en Nik & Jay-udgivelse via Facebook. Lanceringen var en større succes, end jeg først havde antaget, og dette betød at jeg måtte forlade et familiearrangement i Tivoli for at supervisere Nik & Jays albumrelease - 26 timer før først antaget.

Kampagnen – aktiveringen af Nik & Jay som ambassadører for Galaxy S4 – vandt Danish Internet Awards 2014 i kategorien Social Media. Vi lavede den sammen med Starcom og Universal Music. Juryens motivation var, at projektet viste ”en enestående koordineret indsats på tværs af multiple sociale kanaler” – at aktivere Nik & Jays fanbase og samtidig koble den til Samsungs produkter.

Vi drev Facebook-sider for en række højtprofilerede virksomheder, og da aktiviteterne var på deres højeste, havde vi berøring med næsten 800.000 danske Facebook-brugere gennem 100+ Facebook-apps.

Mine opgaver

Titlen var ”Senior Digital Wizard”, hvilket er den slags, et bureau finder på, når rollen ikke passer i en kasse. I praksis var jeg den, der byggede det, de andre havde solgt.

100+ Facebook-apps

Kernen i arbejdet var Facebook-apps i PHP. De ser simple ud udefra – tilmeld dig, upload et billede, deltag i konkurrencen – men de skulle bygges igen og igen, for hver kampagne, med nye regler, nye datafelter og en ny deadline. Over de fem år blev det til over hundrede.

Det tvang en form for disciplin frem. Man kan ikke bygge hundrede apps fra bunden og overleve; man er nødt til at finde ud af, hvad der går igen, og bygge dét én gang. Det er samme lærestykke, jeg senere brugte i Lifeguard, da platformen skulle kunne bære to identiteter.

Alt det andet

Ved siden af kom flash- og HTML-bannere til de konventionelle medier, statiske bannere til Facebook, fotodokumentation af de live-events, kampagnerne mundede ud i, videoredigering og rådgivning, når kunden ville have noget, der ikke kunne lade sig gøre.

Og en enkelt gang: livestreaming. Min fortid som radioafvikler viste sig pludselig at være en kompetence, da Nik & Jays albumrelease skulle sendes live fra Medley Studios på Vesterbro. Det er den slags, der sker i et bureau – opgaven kommer, og så finder man ud af, om nogen kan.

En af BOCCA’s helt store styrker var evnen til at fortælle historier. Men i 2009 var historierne rykket over på nettet. Løsningen på dette blev BOCCA // WIRED.

WIRED var et kreativt bureau med en digital kant. I de to år, de eksisterede, var de en markant bidragsyder til BOCCA Gruppens økonomiske fremgang.

WIRED tog priser hjem fra Creative Circle, Danish Internet Awards og Webby Awards.

Overraskende hurtig

Den kampagne, der endte med at give WIRED – og mig – den første Creative Circle, var ”Overraskende hurtig” for Trafikselskabet Movia.

Opgaven var at få flere passagerer ind i busserne ved at fortælle, hvor tit A-busserne faktisk kører – ca. hvert femte minut. Konceptet blev bygget op om linjen ”A-bus. Alt godt kommer igen” og løb fra sidste del af april 2009 hen over flere uger på outdoor, bannere, busreklamer og et dedikeret kampagnesite, der viste, hvad man kunne nå frem til med de seks A-buslinjer.

Ifølge Markedsføring havde de foregående års kampagner skaffet 400.000 flere passagerer, og det var den effekt, kampagnen skulle bygge videre på.

Kampagnesitet var min del af opgaven. Jeg byggede det sammen med en grafiker og en AD’er – de stod for det visuelle og det konceptuelle, jeg for udviklingen. Det blev belønnet med bronze i kategorien Digital – Microsites ved Creative Circle Award 2010.

Efter blot to år blev WIRED fusioneret med BOCCA Advertising Agency ud fra et ønske om at skabe et nyt bureau med stærkere vægt på owned media og digitale kampagner.

Jeg havde i mellemtiden intensiveret mit samarbejde med en række andre reklamebureauer herunder BBDO, Verk og ContentCPH.

Samtidig sad jeg med en større opgave for GN Netcom // Jabra som jeg havde overtaget gennem EuroRSCG, og som krævede en del af min tid.

Mine opgaver

Jeg blev hentet ind af Mikkel Hyldenbrandt og Mikkel Würtz som ekstern flash- og PHP-udvikler. Teamet var skarpt sat og bestod blandt andet af et par fyre, jeg kendte fra kontorfællesskabet Republikken.

Fra Photoshop til Flash

Arbejdsgangen var den samme hver gang: tage de grafiske elementer, klippe dem op i Photoshop, importere dem i Flash og få det hele til at bevæge sig. Det lyder mekanisk, men det er det ikke – en AD’er tegner det, der ser bedst ud, ikke det, der kan animeres, og forskellen mellem de to er dét, en flash-udvikler får betalt for at lukke.

SEO i Flash

Den umulige del var SEO. Et flash-site er én fil, som Google ikke kan læse: ingen tekst, ingen links, ingen struktur. Kunden ville have både den visuelle oplevelse og synligheden i søgemaskinerne, og de to ting udelukkede hinanden.

Løsningen var at bygge sitet to gange – en HTML-version med teksten under flash-laget, så indholdet fandtes, selv om ingen kunne se det. Det er den slags kompromis, man kun indgår, fordi teknologien ikke kan andet. Da HTML5 kom, forsvandt problemet, og med det forsvandt Flash. Det var en teknologi, jeg brugte år på at mestre, og som var død fem år senere.

Det var lange arbejdsdage, men der var en stærk kultur.

Med over 300 kontorer fordelt på 75 lande var Euro RSCG et af verdens fem største reklamebureauer. Alligevel levede de i Danmark et relativt stille og tilbagetrukket liv, placeret diskret tæt på Vibenshus Runddel. Som netværksbureau havde de en række internationale kunder, der fulgte med fra det franske moderselskab, herunder Citroën, Vichy og L’Oréal. Derudover arbejdede bureauet også med en solid portefølje af danske brands, blandt andet GN/Jabra, TV3, Vattenfall og Longovital.

Euro RSCG stod særligt stærkt på den kreative disciplin og leverede gennemarbejdede løsninger inden for klassiske medier som annoncer, billboards og outdoor-kampagner. Men i takt med markedets udvikling begyndte både kunder og samarbejdspartnere i stigende grad at efterspørge digitale formater og mere fleksible, teknologibaserede løsninger.

Springet var større, end det umiddelbart lød til. En annonce er færdig, når den går i tryk; et website er først begyndt. Det skal virke i browsere, der fortolker den samme kode forskelligt, det skal kunne rettes og udvides efter lancering, og det leverer tal tilbage på, om det rent faktisk virker – tal, som en billboard-kampagne aldrig blev målt på. Uden nogen in-house til at oversætte mellem det kreative oplæg og det, der lod sig bygge, endte de digitale dele af opgaverne hos konkurrenterne, selv når Euro RSCG havde vundet resten.

Jeg havde allerede løbende hjulpet bureauet med eksekvering af mindre digitale opgaver og løsninger. Men efterhånden som behovet voksede, og opgaverne blev både flere og mere komplekse, begyndte jeg at se en klar mulighed for at styrke min egen pipeline og position. Derfor valgte jeg at forlade mit kontorfællesskab og fik i stedet mit eget bord som in-house freelancer hos Euro RSCG. Det gav mig en plads tæt på både kreative og kundeansvarlige, og dermed mulighed for at komme ind i opgaverne, mens de stadig kunne formes – frem for at få dem afleveret som en færdig idé, der bagefter skulle presses ned i en teknisk virkelighed.

Mine opgaver

Jeg sad som bureauets digitale stemme – både udadtil over for kunderne og indadtil, når et kreativt oplæg skulle vurderes for, om det kunne bygges. Den daglige produktion var online-adaptioner af det, bureauet i forvejen lavede: flash-bannere, online-magasiner i Flash, eCards og HTML-mails. Bureauets eget website lå også hos mig.

Jabra

GN/Jabra var den kunde, jeg brugte mest tid på. Jeg byggede et selvstændigt iPhone-site – det lå før responsivt design vandt frem, så mobilversionen var en separat kodebase med sit eget indhold.

Dertil kom SoundLab og ComputeSpectrum, to interaktive værktøjer bygget i Flash. Et headset sælges på lyd, men lyd er svær at sælge på tryk, og en specifikation i hertz siger ingenting til den, der skal købe. Værktøjerne lod brugeren høre forskellen og samtidig se den som en kurve – produktets egenskab demonstreret frem for beskrevet.

Dertil kom HTML-mails og bannerserier i flere sprogversioner. De tilbagevendende elementer samlede jeg i en genbrugelig værktøjskasse med tilhørende designmanual, så udtrykket holdt på tværs af markeder, og produktionstiden faldt.

Bandits Inc. er min egen enkeltmandsvirksomhed.

Virksomheden blev stiftet under navnet Audiotracking v/Paul Nybo Andersen – et navn, der reelt blev valgt på må og få. Jeg stiftede på samme tid Audio Management ApS sammen med nogle andre, og da der skulle stå noget på cvr-registreringen, blev det et ord fra den verden, jeg dengang troede jeg skulle leve af: at levere og producere lyd som freelancer.

Men ingen virksomhed uden markedsføring – og jeg fandt hurtigt ud af, at det jeg kunne udvikle i en browser for at fange kunder ind, havde større efterspørgsel end det, jeg kunne lave foran en pult eller et DAW-program. Navnet blev aldrig ændret. Det står der stadig, som en slags kvittering på, hvor jeg var på vej hen, dengang jeg fik nummeret.

Jeg har primært benyttet mit CVR-nummer til at sælge ydelser ind til reklamebureauer og virksomheder, som besad grafiske og kommunikative kompetencer in-house, men manglede en webudvikler. Det er den rolle, der går igen: at være den, der kunne bygge det, de andre havde tegnet. I praksis har nummeret fulgt mig gennem hele karrieren og ligget parallelt med de fastansættelser og partnerskaber, jeg har haft undervejs – det er kontinuiteten, resten er kapitler.

Derudover har nummeret lagt navn til en del gratis arbejde for non-profit-organisationer, herunder Ombold og Red Barnet.

Curriculum Vitae ↓

Paul Nybo Andersen

Profil_

8 år med Lifeguard

Mine erfaringer

2024-2026, CTO & Co-founder

ESGRapporter

2024-2026, Senior Developer • UI/UX • Design

Revolvo

2015-2023, CTO & Co-founder

Lifeguard

2016-2018, CTO & Co-founder

Vitalityguard

2010-2015, Senior Digital Wizard

ContentCPH

2009-2010, Freelance udvikler

BOCCA WIRED

2008-2010, Inhouse Freelance udvikler

EuroRSCG

2001-2026, Enkeltmandsvirksomhed

Mine kompetencer

Rating

Adobe

Adobe Flash (EOL)

Alpine JS

Amazon AWS

Android Studio

Angular

Apache/ NGINX

Apple iWork

Apple Xcode

App Store

Axure RP

Bitbucket

Bootstrap

C#

CSS/ CSS3

Data compliance (GDPR)

Digital Ocean

DPO

Drupal

Figma

Final Cut Pro

Forge

Foto (DSLR) + Billed behandling (RAW)

Github

Google Play Console

InDesign

Hubspot

HTML/ HTML DOM/ HTML5

Ionic

Jira

Joomla

jQuery

JSON

Laravel

LinkedIn Marketing Solution

Magento 2

Mailchimp

Liquid (Ruby)

Meta Business Suite + Manager

MySQL

Microsoft Azure

Microsoft 365

Illustrator

Photoshop

React

React Native

PHP

REST API

SEM+SEO

Scrum

Sass/SCSS

Shopify

Slack

Trello

Tailwind CSS

Umbraco

Vimeo