Når en side ikke bliver fundet på Google, er det fristende at begynde med teksten. Men før jeg ville ændre indholdet, ville jeg sikre mig, at Google faktisk kan finde siden, læse den og forstå, hvilken version der skal vises i søgeresultatet. Det er en stor del af det, teknisk SEO handler om - Tekniske problemer kan stå i vejen for selv godt indhold.
Teknisk SEO begynder før søgeordene
SEO bliver ofte blandet sammen med søgeord, tekster og links.
Den tekniske del ligger et andet sted. Her handler det blandt andet om, hvordan hjemmesiden er bygget, hvilke URL'er den bruger, hvad søgemaskinen får lov til at besøge, og hvordan siderne hænger sammen.
Kan Google finde siden?
Kan den crawles?
Må den indekseres?
Returnerer serveren den rigtige statuskode?
Peger siden på sig selv som den primære version, eller fortæller et canonical-tag Google, at en anden URL er vigtigere?
Findes det samme indhold på fem forskellige adresser?
Det er spørgsmål, den besøgende sjældent tænker over. Men de er en del af det tekniske grundlag, søgemaskinen møder.
Først skal siden findes. Derefter kan den indekseres
Google kan godt besøge en side uden at tage den med i sit indeks. Og en side kan eksistere på hjemmesiden uden at være nem for Google at finde.
Derfor ville jeg ikke konkludere ret meget ud fra sætningen:
"Siden ligger jo på hjemmesiden."
Jeg ville blandt andet kigge på interne links, sitemap, robots.txt, meta robots, HTTP-statuskoder og canonical-tags.
Og jeg ville se på, hvad Google selv rapporterer om URL'en. I Google Search Console kan URL Inspection blandt andet vise oplysninger om Googles indekserede version og teste en live-URL.
Det er typisk mere nyttigt end at installere endnu et SEO-plugin og håbe, at en grøn indikator løser problemet.
Websitearkitektur betyder også noget
En søgemaskine møder ikke hjemmesiden som et sitemap tegnet på en væg. Den bevæger sig blandt andet gennem links mellem siderne.
Derfor betyder strukturen noget.
Hvis en vigtig side kun kan findes gennem en søgefunktion eller ligger gemt fem-seks niveauer nede uden ordentlige interne links, gør man arbejdet vanskeligere.
Det samme gælder den anden vej.
Hvis næsten alle sider linker til alt, fortæller strukturen meget lidt om, hvad der hører sammen, og hvad der er vigtigt.
Jeg tænker derfor interne links som en del af selve hjemmesiden, ikke som noget der drysses på bagefter for SEO'ens skyld.
Navigation, kategorier, brødkrummer og links i indholdet hjælper både mennesker og søgemaskiner med at forstå sammenhængen.
Redirects er kedelige, indtil de mangler
Når en hjemmeside bliver bygget om, ændrer URL'erne sig ofte.
/om-os/ bliver måske til /virksomheden/.
Den gamle side findes ikke længere, og den nye fungerer fint. Men Google kan have kendt den gamle adresse i årevis. Andre hjemmesider kan linke til den. Brugere kan have gemt den.
Hvis den gamle URL bare forsvinder, ender de forbindelser på en 404-side.
Derfor kortlægger jeg normalt eksisterende URL'er, før et website bliver erstattet. De relevante gamle adresser kan derefter viderestilles til de nye.
Det er ikke den del af et nyt website, nogen står og beundrer ved lanceringen.
Men det er ofte noget af det arbejde, man bliver glad for blev gjort.
Canonicals skal pege det rigtige sted
En hjemmeside kan have flere URL'er, der viser det samme eller næsten det samme indhold.
Det sker blandt andet med filtrering, parametre, kategorier og forskellige tekniske måder at nå samme side på.
Her kan et canonical-tag fortælle søgemaskinen, hvilken URL man betragter som den primære.
Problemet kommer, når systemet peger forkert.
Jeg har set løsninger, hvor templates, plugins og egne tilpasninger alle har haft en mening om metadata. Resultatet kan være, at siden teknisk fortæller noget andet til Google, end man regner med.
Derfor er selve tilstedeværelsen af et canonical-tag mindre vigtig end, hvor det peger hen.
Hvad med hastighed og Core Web Vitals?
Performance og teknisk SEO overlapper.
En langsom hjemmeside er dårlig for brugeren, og performance er derfor også noget, jeg undersøger. PageSpeed Insights er et godt sted at begynde, fordi man både kan se målinger og få peget på konkrete områder, der bør undersøges.
Men jeg ville ikke starte et SEO-projekt med målet:
Vi skal have 100 i Lighthouse.
En Lighthouse-score kan være nyttig til at finde problemer. Den fortæller ikke alene, om hjemmesidens tekniske SEO er god, og den fortæller heller ikke, om indholdet fortjener en god placering.
Lighthouse er en diagnose, ikke en karakter.
Hvis siden allerede fungerer hurtigt for rigtige brugere, kan der være vigtigere ting at bruge tiden på end at flytte en score fra 96 til 100.
Strukturerede data gør det muligt at beskrive indhold i et format, som søgemaskiner kan fortolke maskinelt.
Det kan eksempelvis være information om en virksomhed, et produkt, en artikel eller et arrangement.
Schema markup giver mest mening, når det beskriver noget, der faktisk findes på siden, og implementeringen er korrekt.
Til det kan Google Rich Results Test bruges til at undersøge de rich-result-formater, Google understøtter, mens Schema.org Validator kan bruges til at validere Schema.org-markup mere generelt.
Mængden af markup siger i sig selv meget lidt. Det afgørende er, om den beskriver indholdet korrekt.
Hreflang, når der er flere sprog
På websites med flere sprog eller regionale versioner kommer hreflang ind i billedet.
Det hjælper søgemaskinen med at forstå forholdet mellem eksempelvis en dansk, svensk og engelsk version af samme indhold.
Har hjemmesiden kun dansk indhold, kan hreflang springes over.
Det er et meget enkelt eksempel på noget, jeg synes er vigtigt i teknisk SEO: Man behøver ikke implementere en funktion, bare fordi den står på en SEO-tjekliste.
En del af arbejdet er at afgøre, hvad der faktisk er relevant for den konkrete hjemmeside.
Hvad er teknisk SEO så ikke?
Teknisk SEO kan skabe gode tekniske betingelser for en side.
Det kan ikke gøre et irrelevant produkt relevant, skabe efterspørgsel efter noget ingen søger efter eller automatisk gøre en tynd artikel til det bedste svar på et spørgsmål.
Hvis ti virksomheder har teknisk velfungerende websites og alle vil findes på den samme søgning, skal søgemaskinen stadig vælge mellem dem.
Her spiller andre dele af SEO ind: indhold, relevans, links, autoritet og hvad brugeren faktisk leder efter.
Derfor ville jeg være skeptisk, hvis en teknisk gennemgang blev solgt som en sikker vej til bestemte placeringer.
Teknikken kan fjerne forhindringer.
Den kan ikke bestemme, hvem der skal ligge nummer ét.
Jeg ville begynde med at finde problemet
Hvis nogen siger til mig, at deres SEO ikke virker, ville jeg ikke begynde med en liste over 50 ting, der kan optimeres.
Jeg ville først prøve at finde ud af, hvad "ikke virker" betyder.
Er hele websitet svært at finde?
Er det enkelte sider?
Er siderne slet ikke indekseret?
Forsvandt trafikken efter en relancering?
Er der kommet nye URL'er?
Er hjemmesiden blevet langsommere?
Eller bliver siderne fint fundet og indekseret, men rangerer bare ikke på de søgninger, virksomheden gerne vil findes på?
Det er forskellige problemer og kræver forskellige løsninger.
Et website kan have perfekte redirects og stadig have dårligt indhold. Det kan have gode tekster og samtidig blokere vigtige sider fra indeksering.
Teknisk SEO handler derfor ikke om at optimere alt, man kan måle. Det handler om at finde de tekniske ting, der står i vejen – og lade resten være.
Gratis værktøjer til teknisk SEO
Jeg bruger værktøjer til at finde steder, der skal undersøges. De fortæller sjældent alene, hvad der bør prioriteres.
01_Google Search Consolemit naturlige udgangspunkt til indeksering, sitemaps, søgetrafik og enkelte URL'er. Links-rapporten viser interne links og finder vigtige sider med for lidt intern opmærksomhed.
02_PageSpeed Insightstil performance, Core Web Vitals og konkrete performanceproblemer på den enkelte side.
03_Chrome DevToolsbrowserens egne udviklerværktøjer. Jeg bruger blandt andet Network, Elements og Console til at undersøge HTML/DOM, JavaScript, redirects, response headers, ressourcer og rendering.
04_Google Rich Results Testtil at undersøge strukturerede data i forhold til de rich-result-formater, Google understøtter.
05_Schema.org Validatortil en bredere kontrol af Schema.org-markup, herunder JSON-LD, Microdata og RDFa.
06_AI-værktøj til interne linksanalyserer indhold på tværs af sider og foreslår relevante links og ankertekster. Fx LinkStorm (kun engelsk) og LinkSigma.
Et værktøj kan pege på et problem. Det afgør ikke, om problemet er vigtigt nok til, at man skal bruge tid på at løse det.
Performance & SEOJeg arbejder med performance fra måling og diagnose til billeder, caching, databaseforespørgsler, JavaScript og teknisk SEO. Målet er ikke 100 i Lighthouse. Målet er et hurtigt website, der fungerer godt for rigtige brugere.
49 år, CTO, grafisk designer og fullstack udvikler (LAMP/LEMP) med 26 års erfaring i udvikling af digitale løsninger til en bred målgruppe af virksomheder.
Fra 2015 til 2023 var jeg CTO og medstifter af Lifeguard Health ApS. Her arbejdede jeg med udviklingen af en digital sundhedsplatform, der kombinerede teknologi, data og personlig coaching. Rollen omfattede alt fra produktudvikling, UX og softwarearkitektur til ledelse af udviklingsteams, drift og forretningsudvikling. De otte år i Lifeguard kom til at præge min tilgang til både teknologi, produkter og mennesker og danner i dag fundamentet for meget af det, jeg arbejder med.
Læs mere
Se Lifeguard's Core-story
Lifeguard præsentation_1_4_
03_Ansættelseshistorik_
Mine erfaringer
I mine forskellige roller har jeg trukket på de erfaringer jeg har opbygget gennem 26 år. Jeg har i denne sektion forsøgt at beskrive de erfaringer jeg har tilegnet mig gennem de opgaver jeg løst og de faglige kompetencer jeg har benyttet.
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.
Rating
- " Der er jeg 100 meter mester i".
- " Det er jeg ret god til".
- " Det er jeg udemærket til".
- " Det er ikke det jeg er bedst til, men jeg kan til nøds".
- " Det er jeg ikke haj til - men jeg er villig til at lære".
Jeg kan åbne Figma og begynde at tegne en hjemmeside med det samme. Det er sjældent en god idé. For før jeg ved, hvordan siden skal se ud, vil jeg vide, hvad den skal få nogen til at gøre.
Når en side ikke bliver fundet på Google, er det fristende at begynde med teksten. Men før jeg ville ændre indholdet, ville jeg sikre mig, at Google faktisk kan finde siden, læse den og forstå, hvilken version der skal vises i søgeresultatet. Det er en stor del af det, teknisk SEO handler om - Tekniske problemer kan stå i vejen for selv godt indhold.
Jeg har set tilbud på hjemmesider, hvor det ene kostede 30.000 kroner og det andet 120.000. Det oplagte spørgsmål er, hvorfor den ene leverandør er fire gange så dyr. Det mindre oplagte spørgsmål er, om de overhovedet har tilbudt det samme.
En langsom hjemmeside kan skyldes et billede på 4 MB. Den kan også skyldes 10 andre ting. Det første spørgsmål er derfor ikke, hvad sitet er bygget i – det er, hvor tiden forsvinder hen.
En visuel identitet skal kunne fungere uden grafikeren
En visuel identitet er nem at få til at se godt ud på en skærm. Det bliver sværere, når den skal ud i virkeligheden – i en PowerPoint, på en faktura, på et skilt nogen selv retter i tre år senere.
AI-genereret grafik er rykket ud af computeren og ind i den virkelige verden. Spørgsmålet er ikke længere, om AI kan lave grafik. Det kan den. Spørgsmålet er, hvad der så er tilbage af grafikerens arbejde.
Da vi byggede ESGRapporter, havde konkurrenterne tungere beregningsmotorer end os. Vi satsede et andet sted: på at det, brugeren sad tilbage med, var værd at vise frem.
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.
TL;DR:Vi byggede ESG-rapporteringsplatformen i Laravel og havde det tekniske ansvar for retningen, rapportdelen og alt det visuelle.
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.
TL;DR:Jeg arbejdede med udvikling, UI/UX og grafisk identitet. 60% af tiden gik til BmyGuest og IDoMeetings, som Revolvo var medejer af.
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å.
TL;DR:Jeg byggede LifeScore-platformen i Laravel med samtykkestyret adgang til sundhedsdata, en app til armbåndet og stod for alt UX og design.
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 blev Lifeguard erklæret 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.
TL;DR:Vi drev Lifeguard-platformen i white label gennem et joint venture med Dansk Sundhedssikring. Mærsk var den største kunde.
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.
TL;DR:Jeg byggede 60+ Facebook-apps i PHP for Samsung, IKEA og H&M. Nik & Jay-kampagnen for Samsung vandt Danish Internet Awards 2014.
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 2008-2009 lavede jeg freelance-arbejde for dem, og i 2010 blev jeg fastansat med ansvar for udviklingen af det digitale indhold.
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 60+ Facebook-apps – heriblandt Samsung, Sony, IKEA, H&M og TV3.
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. Vi havde fokus på aktivering og på second screen – den skærm, seeren sad med foran fjernsynet. 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, tilmelde sig roadshow med IKEA eller Kvik Køkkener eller konkurrere om en plads i næste års Masterchef.
Samme greb lå bag DFDS’ reality-serie på TV3: seks afsnit fra Oslo-båden, hvor TV3 fulgte besætningen uden redaktionel kontrol fra rederiet, og hvor sociale medier tog dialogen videre bagefter.
Samsung og Nik & Jay
Vi havde et fortløbende og succesfyldt samarbejde med Samsung Danmark. Blandt andet byggede jeg en Facebook-app for Samsungs aktivering af Nik & Jay. Appen viste en nedtælling til premieren på deres nye album UNITED: hver gang nogen skrev #pæntjatak på Instagram eller Twitter, trak vi et minut fra tiden. Publikum kunne altså selv rykke releasen tættere på ved at larme for den.
Nedtællingen blev spist hurtigere end forudsat, og premieren rykkede 26 timer frem. Jeg måtte forlade et familiearrangement i Tivoli for at afvikle det. Det er den slags fejlskøn, man helst vil lave: vi havde regnet forsigtigt, og det havde publikum ikke.
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.
En festivallejr med varme bade
Sideløbende fik vi også Hennes & Mauritz ombord, og i 2011-2013 stod ContentCPH for planlægning og eksekvering af H&M Reboot Camp på Roskilde Festival.
Reboot Camp var en teltlejr til fordel for Fashion Against AIDS: man købte en pakke med opstillet telt og morgenmad, og på pladsen lå en pop-up shop med kollektionen. I 2011 var det 1.600 festivalgæster i 800 telte, og kollektionen var over 90 procent udsolgt allerede torsdag.
Pointen var, at lejren ikke lignede resten af festivalen. Cofoco stod for maden sammen med en sushirestaurant, og Joe & The Juice drev loungen med mad, drikkevarer og underholdning – alkohol inklusive, så baren en uge lang hed Joe & the Booze. I stylingsalonen ChaChaCha klippede professionelle frisører gæsterne, og overskuddet gik til Aidsfonden. Og der var varme bade.
Det åbnede op for et helt nyt publikum: dem, der gerne ville være en del af festivalen, men ikke af mudderpølen. Jeg har siden noteret mig, at Roskilde Festival i stigende grad har skabt tiltag rettet mod netop det segment.
På pladsen var jeg en del af den praktiske afvikling og fotodokumentationen.
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.
60+ 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 60+.
Det tvang en form for disciplin frem. Man kan ikke bygge 60+ 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.
TL;DR:Jeg byggede kampagnesites for Movia og Hjerteforeningen, heriblandt Overraskende hurtig, der vandt bronze ved Creative Circle Award.
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 indirekte mig – den første Creative Circle, var ”Overraskende hurtig” for Trafikselskabet Movia.
Opgaven var at få flere passagerer ind i busserne ved at gøre det håndgribeligt, hvor langt man faktisk kunne nå med S-busnettet. Kampagnen løb fra sidste del af april 2009 hen over flere uger på outdoor, bannere, busreklamer og et dedikeret kampagnesite, der viste rejsetider og korrespondancer på tværs af de otte S-buslinjer.
Jeg blev hentet ind af Mikkel Hyldenbrandt, Mikkel Würtz og Eskil Busck som ekstern flash- og PHP-udvikler. Eskil havde jeg delt kontor med på Republikken, og vi havde allerede bygget prelaunch-sitet til L.O.C.’s Melankolia/XxxCouture sammen – så de vidste, hvad de fik.
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 – et år, hvor færre end hvert tiende indsendte arbejde overhovedet fik metal.
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
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.
Indholdet lå i XML, ikke i timelinen
S-buskampagnen skulle vise otte buslinjer, begge retninger, hvert eneste stop med minuttal og korrespondancer til andre linjer. Standardmåden i Flash var at lægge den slags direkte i timelinen. Det ville have betydet flere hundrede stoppesteder hardkodet i en fil, som kun kunne rettes af en, der havde Flash installeret – og Movia retter køreplaner hvert halve år.
Så indholdet kom ud af filmen og over i XML. Ét skema pr. linje, spejlet i begge retninger, hvor hvert stop var et element med titel, minuttal og en liste af korrespondancer. Flash’en loadede filerne og byggede visningen ud fra dem. Menuteksterne lå for sig, og skabelonen til nye linjer lå som sin egen fil, klar til at blive fyldt ud.
SEO’en var 2009’s SEO
Prisen var synligheden. Et rent flash-site er én fil, Google ikke kan læse: ingen tekst, ingen links, ingen struktur. Al den pæne XML lå inde i afspilleren, hvor søgemaskinerne aldrig kom.
Løsningen dengang var metatags – nøgleord i subject og dc.keywords, den liste man skrev, fordi det var sådan, man gjorde. Google holdt op med at lytte til den kort efter.
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.
TL;DR:Jeg hentede bureauets digitale opgaver hjem fra konkurrenterne og byggede iPhone-site og interaktive produktværktøjer for GN/Jabra.
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 Longo Vital.
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.
TL;DR:Min egen enkeltmandsvirksomhed siden 2001. Gennem den har jeg solgt webudvikling til bureauer, der havde grafikken, men manglede udvikleren.
Bandits Inc. er min egen personlige legeplads.
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.
Jeg kan åbne Figma og begynde at tegne en hjemmeside med det samme. Det er sjældent en god idé. For før jeg ved, hvordan siden skal se ud, vil jeg vide, hvad den skal få nogen til at gøre.
Jeg kan åbne Figma og begynde at tegne en hjemmeside med det samme.
Det er sjældent en god idé.
For før jeg ved, hvordan siden skal se ud, vil jeg vide, hvad den skal få nogen til at gøre. Hvem bruger den? Hvad kommer de for? Hvad skal de kunne finde, forstå eller gennemføre?
Det er designarbejde, selv om der endnu ikke er tegnet noget.
Hvad er problemet?
En designopgave begynder ofte med en løsning.
"Vi skal have en ny forside."
"Vi skal have en konfigurator."
"Vi skal have et dashboard."
Det kan sagtens være rigtigt. Men jeg vil gerne et skridt tilbage først.
Hvorfor skal forsiden laves om? Hvad kan brugerne ikke finde i dag? Hvad skal konfiguratoren gøre lettere? Hvilken beslutning skal dashboardet hjælpe nogen med at træffe?
Nogle gange viser det sig faktisk, at løsningen er mindre end den opgave, vi begyndte med.
Hvis problemet er, at kunderne ikke kan finde priserne, er løsningen måske ikke et redesign af hele websitet. Det kan være, at priserne bare skal være nemmere at finde.
Det er en ret vigtig forskel, når nogen skal betale for arbejdet bagefter.
Brugeren og forretningen skal det samme sted hen
Jeg prøver at forstå, hvad brugeren kommer for.
En kunde vil måske finde ud af, hvad noget koster. Sammenligne to produkter. Bestille en tid. Forstå en kompliceret ydelse. Eller bare afgøre, om virksomheden er relevant.
Samtidig har virksomheden et mål.
Den vil have en henvendelse, et salg, en tilmelding eller måske bare undgå, at kunden ringer med et spørgsmål, som hjemmesiden burde have besvaret.
De to ting skal helst mødes.
Hvis man kun designer efter virksomhedens behov, får man let en side fyldt med budskaber, som virksomheden gerne vil fortælle.
Hvis man kun ser på brugerens umiddelbare ønsker, kan man ende med en løsning, der er behagelig at bruge, men ikke løser den opgave, virksomheden betaler for.
Designet skal få de to behov til at mødes.
Hvad skal komme først?
Når jeg nogenlunde forstår opgaven, begynder strukturen at blive vigtig.
Hvilken information skal brugeren møde først? Hvad skal vedkommende vide, før næste valg giver mening? Hvilke ting hører sammen? Hvad kan gemmes væk? Og hvor mange valg behøver der egentlig at være?
Det er informationsarkitektur og brugerflow, men i praksis handler det meget om rækkefølge.
Forestil dig en formular med 15 felter. Man kan bruge lang tid på at designe flotte felter, gode labels og den helt rigtige afstand mellem dem.
Men hvis syv af felterne ikke er nødvendige, er den bedste designbeslutning måske at slette dem.
Det er den slags beslutninger, jeg helst vil tage, før jeg begynder at diskutere farver og hjørneradius.
Derfor kan jeg godt lide wireframes
På et tidspunkt skal tankerne selvfølgelig blive synlige.
Her bruger jeg ofte simple wireframes.
De må gerne være kedelige.
En overskrift. Et felt. En knap. Nogle grå bokse.
Det gør det lettere at tale om strukturen uden samtidig at skulle forholde sig til billeder, typografi og visuel stil.
Kan man forstå siden? Kommer informationen i den rigtige rækkefølge? Er næste skridt tydeligt? Mangler der noget? Kan noget fjernes?
Det er billigere at flytte en grå firkant end at ændre en færdig løsning.
Så kommer Figma
Når strukturen begynder at hænge sammen, giver det mening at arbejde mere detaljeret med designet.
Typografi, farver, hierarki, afstande, komponenter og de forskellige tilstande, en brugerflade kan befinde sig i.
Det er også her, virkeligheden skal begynde at presse sig på.
Hvad sker der, når overskriften er dobbelt så lang som den i mockuppet? Hvordan ser en formular ud, når noget går galt? Hvad sker der på en telefon? Hvad hvis der er 17 søgeresultater i stedet for de tre, der passede så pænt ind i designet?
Den færdige løsning kommer sjældent til at indeholde præcis det indhold, designeren brugte, da den blev tegnet.
Så den skal kunne holde til lidt mere end præsentationen.
Man opdager meget ved at give den til andre
Når projektet giver mulighed for det, vil jeg gerne have andre til at prøve løsningen.
Det behøver ikke være et stort UX-studie.
Man kan komme langt ved at sætte en prototype foran en person, der ikke har været med til at lave den, og give vedkommende en konkret opgave.
Find prisen.
Opret en bruger.
Bestil produktet.
Find ud af, hvordan du ændrer dit abonnement.
Og så lade være med at hjælpe.
Hvis man selv har arbejdet med en løsning i flere uger, kender man allerede svarene. Man ved, hvor menuen er. Man ved, hvad ikonet betyder. Man ved, at knappen nederst på siden er næste skridt.
Den viden har brugeren ikke.
Finder man problemet her, kan man stadig ændre det, før det bliver en del af den færdige løsning.
Prototypen behøver heller ikke altid være i Figma
Nogle idéer er nemmere at undersøge i det medie, de til sidst skal fungere i.
Hvis jeg vil mærke et flow, en interaktion eller en responsiv opførsel, kan jeg derfor godt ende med at bygge en simpel prototype i browseren.
Jeg bruger Figma på mange designprojekter – oftest når jeg skal levere videre til andre.
Men når jeg åbner det, skulle en del af designarbejdet gerne allerede være i gang.
Jeg vil have en idé om, hvilket problem vi forsøger at løse, hvem der skal bruge løsningen, hvad de skal kunne, og hvad virksomheden skal have ud af det.
Så kan jeg begynde at tegne.
Et godt design begynder ikke med, hvordan løsningen skal se ud. Det begynder med at forstå, hvad den skal løse.
Webdesign & UXJeg arbejder med design af brugerflader fra de første wireframes og prototyper til det færdige design og designsystem – med udgangspunkt i, hvad brugeren skal kunne, og hvad forretningen skal have ud af det.
Når en side ikke bliver fundet på Google, er det fristende at begynde med teksten. Men før jeg ville ændre indholdet, ville jeg sikre mig, at Google faktisk kan finde siden, læse den og forstå, hvilken version der skal vises i søgeresultatet. Det er en stor del af det, teknisk SEO handler om - Tekniske problemer kan stå i vejen for selv godt indhold.
Teknisk SEO begynder før søgeordene
SEO bliver ofte blandet sammen med søgeord, tekster og links.
Den tekniske del ligger et andet sted. Her handler det blandt andet om, hvordan hjemmesiden er bygget, hvilke URL'er den bruger, hvad søgemaskinen får lov til at besøge, og hvordan siderne hænger sammen.
Kan Google finde siden?
Kan den crawles?
Må den indekseres?
Returnerer serveren den rigtige statuskode?
Peger siden på sig selv som den primære version, eller fortæller et canonical-tag Google, at en anden URL er vigtigere?
Findes det samme indhold på fem forskellige adresser?
Det er spørgsmål, den besøgende sjældent tænker over. Men de er en del af det tekniske grundlag, søgemaskinen møder.
Først skal siden findes. Derefter kan den indekseres
Google kan godt besøge en side uden at tage den med i sit indeks. Og en side kan eksistere på hjemmesiden uden at være nem for Google at finde.
Derfor ville jeg ikke konkludere ret meget ud fra sætningen:
"Siden ligger jo på hjemmesiden."
Jeg ville blandt andet kigge på interne links, sitemap, robots.txt, meta robots, HTTP-statuskoder og canonical-tags.
Og jeg ville se på, hvad Google selv rapporterer om URL'en. I Google Search Console kan URL Inspection blandt andet vise oplysninger om Googles indekserede version og teste en live-URL.
Det er typisk mere nyttigt end at installere endnu et SEO-plugin og håbe, at en grøn indikator løser problemet.
Websitearkitektur betyder også noget
En søgemaskine møder ikke hjemmesiden som et sitemap tegnet på en væg. Den bevæger sig blandt andet gennem links mellem siderne.
Derfor betyder strukturen noget.
Hvis en vigtig side kun kan findes gennem en søgefunktion eller ligger gemt fem-seks niveauer nede uden ordentlige interne links, gør man arbejdet vanskeligere.
Det samme gælder den anden vej.
Hvis næsten alle sider linker til alt, fortæller strukturen meget lidt om, hvad der hører sammen, og hvad der er vigtigt.
Jeg tænker derfor interne links som en del af selve hjemmesiden, ikke som noget der drysses på bagefter for SEO'ens skyld.
Navigation, kategorier, brødkrummer og links i indholdet hjælper både mennesker og søgemaskiner med at forstå sammenhængen.
Redirects er kedelige, indtil de mangler
Når en hjemmeside bliver bygget om, ændrer URL'erne sig ofte.
/om-os/ bliver måske til /virksomheden/.
Den gamle side findes ikke længere, og den nye fungerer fint. Men Google kan have kendt den gamle adresse i årevis. Andre hjemmesider kan linke til den. Brugere kan have gemt den.
Hvis den gamle URL bare forsvinder, ender de forbindelser på en 404-side.
Derfor kortlægger jeg normalt eksisterende URL'er, før et website bliver erstattet. De relevante gamle adresser kan derefter viderestilles til de nye.
Det er ikke den del af et nyt website, nogen står og beundrer ved lanceringen.
Men det er ofte noget af det arbejde, man bliver glad for blev gjort.
Canonicals skal pege det rigtige sted
En hjemmeside kan have flere URL'er, der viser det samme eller næsten det samme indhold.
Det sker blandt andet med filtrering, parametre, kategorier og forskellige tekniske måder at nå samme side på.
Her kan et canonical-tag fortælle søgemaskinen, hvilken URL man betragter som den primære.
Problemet kommer, når systemet peger forkert.
Jeg har set løsninger, hvor templates, plugins og egne tilpasninger alle har haft en mening om metadata. Resultatet kan være, at siden teknisk fortæller noget andet til Google, end man regner med.
Derfor er selve tilstedeværelsen af et canonical-tag mindre vigtig end, hvor det peger hen.
Hvad med hastighed og Core Web Vitals?
Performance og teknisk SEO overlapper.
En langsom hjemmeside er dårlig for brugeren, og performance er derfor også noget, jeg undersøger. PageSpeed Insights er et godt sted at begynde, fordi man både kan se målinger og få peget på konkrete områder, der bør undersøges.
Men jeg ville ikke starte et SEO-projekt med målet:
Vi skal have 100 i Lighthouse.
En Lighthouse-score kan være nyttig til at finde problemer. Den fortæller ikke alene, om hjemmesidens tekniske SEO er god, og den fortæller heller ikke, om indholdet fortjener en god placering.
Lighthouse er en diagnose, ikke en karakter.
Hvis siden allerede fungerer hurtigt for rigtige brugere, kan der være vigtigere ting at bruge tiden på end at flytte en score fra 96 til 100.
Strukturerede data gør det muligt at beskrive indhold i et format, som søgemaskiner kan fortolke maskinelt.
Det kan eksempelvis være information om en virksomhed, et produkt, en artikel eller et arrangement.
Schema markup giver mest mening, når det beskriver noget, der faktisk findes på siden, og implementeringen er korrekt.
Til det kan Google Rich Results Test bruges til at undersøge de rich-result-formater, Google understøtter, mens Schema.org Validator kan bruges til at validere Schema.org-markup mere generelt.
Mængden af markup siger i sig selv meget lidt. Det afgørende er, om den beskriver indholdet korrekt.
Hreflang, når der er flere sprog
På websites med flere sprog eller regionale versioner kommer hreflang ind i billedet.
Det hjælper søgemaskinen med at forstå forholdet mellem eksempelvis en dansk, svensk og engelsk version af samme indhold.
Har hjemmesiden kun dansk indhold, kan hreflang springes over.
Det er et meget enkelt eksempel på noget, jeg synes er vigtigt i teknisk SEO: Man behøver ikke implementere en funktion, bare fordi den står på en SEO-tjekliste.
En del af arbejdet er at afgøre, hvad der faktisk er relevant for den konkrete hjemmeside.
Hvad er teknisk SEO så ikke?
Teknisk SEO kan skabe gode tekniske betingelser for en side.
Det kan ikke gøre et irrelevant produkt relevant, skabe efterspørgsel efter noget ingen søger efter eller automatisk gøre en tynd artikel til det bedste svar på et spørgsmål.
Hvis ti virksomheder har teknisk velfungerende websites og alle vil findes på den samme søgning, skal søgemaskinen stadig vælge mellem dem.
Her spiller andre dele af SEO ind: indhold, relevans, links, autoritet og hvad brugeren faktisk leder efter.
Derfor ville jeg være skeptisk, hvis en teknisk gennemgang blev solgt som en sikker vej til bestemte placeringer.
Teknikken kan fjerne forhindringer.
Den kan ikke bestemme, hvem der skal ligge nummer ét.
Jeg ville begynde med at finde problemet
Hvis nogen siger til mig, at deres SEO ikke virker, ville jeg ikke begynde med en liste over 50 ting, der kan optimeres.
Jeg ville først prøve at finde ud af, hvad "ikke virker" betyder.
Er hele websitet svært at finde?
Er det enkelte sider?
Er siderne slet ikke indekseret?
Forsvandt trafikken efter en relancering?
Er der kommet nye URL'er?
Er hjemmesiden blevet langsommere?
Eller bliver siderne fint fundet og indekseret, men rangerer bare ikke på de søgninger, virksomheden gerne vil findes på?
Det er forskellige problemer og kræver forskellige løsninger.
Et website kan have perfekte redirects og stadig have dårligt indhold. Det kan have gode tekster og samtidig blokere vigtige sider fra indeksering.
Teknisk SEO handler derfor ikke om at optimere alt, man kan måle. Det handler om at finde de tekniske ting, der står i vejen – og lade resten være.
Gratis værktøjer til teknisk SEO
Jeg bruger værktøjer til at finde steder, der skal undersøges. De fortæller sjældent alene, hvad der bør prioriteres.
01_Google Search Consolemit naturlige udgangspunkt til indeksering, sitemaps, søgetrafik og enkelte URL'er. Links-rapporten viser interne links og finder vigtige sider med for lidt intern opmærksomhed.
02_PageSpeed Insightstil performance, Core Web Vitals og konkrete performanceproblemer på den enkelte side.
03_Chrome DevToolsbrowserens egne udviklerværktøjer. Jeg bruger blandt andet Network, Elements og Console til at undersøge HTML/DOM, JavaScript, redirects, response headers, ressourcer og rendering.
04_Google Rich Results Testtil at undersøge strukturerede data i forhold til de rich-result-formater, Google understøtter.
05_Schema.org Validatortil en bredere kontrol af Schema.org-markup, herunder JSON-LD, Microdata og RDFa.
06_AI-værktøj til interne linksanalyserer indhold på tværs af sider og foreslår relevante links og ankertekster. Fx LinkStorm (kun engelsk) og LinkSigma.
Et værktøj kan pege på et problem. Det afgør ikke, om problemet er vigtigt nok til, at man skal bruge tid på at løse det.
Performance & SEOJeg arbejder med performance fra måling og diagnose til billeder, caching, databaseforespørgsler, JavaScript og teknisk SEO. Målet er ikke 100 i Lighthouse. Målet er et hurtigt website, der fungerer godt for rigtige brugere.
Hvad koster en hjemmeside – og hvorfor er to tilbud næsten umulige at sammenligne?
Jeg har set tilbud på hjemmesider, hvor det ene kostede 30.000 kroner og det andet 120.000. Det oplagte spørgsmål er, hvorfor den ene leverandør er fire gange så dyr. Det mindre oplagte spørgsmål er, om de overhovedet har tilbudt det samme.
Det mindre oplagte spørgsmål er, om de overhovedet har tilbudt det samme.
For en hjemmeside er ikke en standardvare. To tilbud kan begge indeholde "design, udvikling og lancering" og alligevel dække over vidt forskellige mængder arbejde.
Derfor ville jeg være forsigtig med bare at sammenligne tallet nederst på sidste side.
Man skal først finde ud af, hvad man faktisk køber.
Hvad koster en hjemmeside så?
Det kommer an på, hvad der skal bygges.
En hjemmeside kan være fem sider med kontaktformular og åbningstider. Den kan også have 2.000 produkter, tre sprog, login, integration til CRM, betaling, søgning og data fra andre systemer.
Begge dele kan kaldes en hjemmeside.
Prisen afhænger derfor ikke kun af antallet af sider. Den afhænger af, hvad der skal designes, udvikles, integreres, flyttes, testes og efterfølgende drives.
Det er også derfor, jeg har svært ved generelle prislister med "lille", "mellem" og "stor" hjemmeside.
De kan give en idé om et budgetniveau. Men de siger ikke ret meget om prisen, før nogen har forstået opgaven.
30.000 eller 120.000?
Forestil dig to tilbud på den samme nye hjemmeside.
Det første lyder på 30.000 kroner.
Det andet på 120.000.
I det billige tilbud er der et færdigt tema, som tilpasses virksomhedens farver og logo. Kunden flytter selv indholdet. Kontaktformularen bruger en standardløsning. Der er ingen særlig gennemgang af SEO, redirects eller performance.
Det andet tilbud begynder med informationsarkitektur og wireframes. Designet laves specifikt til virksomheden. Indhold og eksisterende URL'er håndteres som en del af flytningen. Formularen integreres med CRM. Der testes på mobil og forskellige browsere. Performance gennemgås før lancering.
30.000 mod 120.000 fortæller nu en lidt anden historie.
Det betyder ikke, at tilbuddet på 120.000 er det rigtige. Måske har virksomheden slet ikke brug for alt det.
Det afgørende er at opdage forskellen før man vælger leverandør.
Hvad med hjemmesider til 5.000 kroner?
De findes også.
Og jeg ville ikke afvise dem, bare fordi prisen er lav.
En hjemmeside til 5.000 kroner kan teknisk set være helt fin. Hvis virksomheden har brug for fem enkle sider, en kontaktformular og et design baseret på en eksisterende skabelon, er der ikke nødvendigvis nogen grund til at gøre projektet større.
Det interessante er snarere, hvordan det kan lade sig gøre til den pris.
Nogle leverandører har standardiseret processen meget. De bruger gennemprøvede skabeloner og komponenter, begrænser antallet af sider og retterunder og kan derfor bygge den samme type løsning langt hurtigere end et projekt, der begynder med analyse, wireframes og et individuelt design.
Andre fordeler betalingen anderledes.
Hjemmesiden kan være billig eller ligefrem gratis at få bygget, mens hosting, support, vedligeholdelse og ændringer betales gennem en løbende aftale. Den model findes allerede på det danske marked. Der er både løsninger med månedlig betaling og binding og løsninger uden eller med relativt kort binding.
Det er der ikke i sig selv noget galt med.
Man skal bare sammenligne den samlede aftale og ikke kun etableringsprisen.
Hvad koster løsningen over tre eller fem år? Hvad er inkluderet i den løbende betaling? Hvor længe er man bundet? Hvem ejer domænet, designet og indholdet? Kan hjemmesiden flyttes til en anden leverandør? Og hvad sker der med den, hvis aftalen opsiges?
En hjemmeside til 5.000 kroner kan derfor være præcis den rigtige løsning.
Men 5.000 kroner fortæller lige så lidt om, hvad man køber, som 120.000 kroner gør.
Hvad betyder "design og udvikling"?
Det kan dække over overraskende meget.
Design kan være nogle få tilpasninger af en eksisterende løsning. Det kan også begynde med informationsarkitektur og wireframes og ende med prototyper, responsive layouts og et komponentbibliotek i Figma.
"Udvikling" er mindst lige så bredt.
Er der tale om installation og konfiguration? Skal der udvikles funktionalitet specifikt til virksomheden? Er integrationer inkluderet? Hvem bygger formularerne? Hvad med cookie consent, tracking, søgning, mail og brugerrettigheder?
To leverandører kan derfor begge skrive "design og udvikling" på tilbuddet og have prissat noget meget forskelligt.
Jo mere der overlades til fortolkning, desto sværere bliver priserne at sammenligne.
Det arbejde, man ikke kan se
En del af arbejdet ender aldrig som noget, man kan pege på på skærmen.
Ved et eksisterende website kommer historikken oveni.
Et website, der har eksisteret i ti år, indeholder ti års beslutninger. Noget skal med videre. Noget kan fjernes. Noget skal erstattes. Og noget opdager man først, når man begynder at undersøge løsningen.
Det arbejde kan fylde meget lidt i ét tilbud og ganske meget i et andet.
En redirect er ikke særlig imponerende på et statusmøde. En gammel URL, der efter lanceringen giver 404 og mister trafik fra Google, er noget lettere at få øje på.
Hvem har ansvaret bagefter?
En anden forskel gemmer sig ofte efter ordet lancering.
Hvem opdaterer CMS'et? Hvem tager backup? Hvem reagerer, hvis en integration stopper med at virke? Hvem ejer hostingkontoen, domænet og koden?
Kan en anden udvikler overtage løsningen?
Og hvad koster det, når der skal ændres noget om seks måneder?
Det ville jeg gerne kende svarene på, før jeg sammenlignede tilbuddene.
En løsning kan være billig at lancere og dyr at eje.
Standard eller specialudvikling?
Her kan prisforskellen blive stor.
Hvis problemet allerede er løst godt af WordPress, Shopify eller en eksisterende tjeneste, er der sjældent nogen grund til at udvikle det hele fra bunden.
Omvendt kan en standardløsning blive dyr, hvis den skal presses til at gøre noget, den ikke er lavet til. Så begynder plugins, workarounds og specialtilpasninger at samle sig.
Jeg har ingen principiel præference for specialudvikling frem for standardløsninger.
Jeg vil hellere finde den løsning, der løser opgaven uden unødvendig kompleksitet.
Nogle gange er det et plugin. Andre gange er det egen kode. Og nogle gange skal man slet ikke bygge funktionen.
14 sider gør ikke tilbuddet bedre
Et langt tilbud kan se grundigt ud.
Men man kan sagtens skrive 14 sider uden at have forstået problemet.
Jeg ville hellere se efter, om leverandøren har forstået de væsentlige dele af opgaven.
Hvad forsøger virksomheden at opnå? Hvem skal bruge løsningen? Hvem skal redigere den? Hvilke systemer skal den tale med? Hvad findes allerede? Og hvilke antagelser bygger prisen på?
Det sidste kan flytte prisen ganske meget.
Hvis én leverandør regner med, at indholdet kan eksporteres automatisk, mens en anden har undersøgt systemet og konstateret, at halvdelen skal håndteres manuelt, bliver deres priser naturligvis forskellige.
Jeg ville sammenligne opgaven før prisen
Hvis jeg fik tilbud på 30.000 og 120.000 kroner foran mig, ville jeg lægge dem ved siden af hinanden og prøve at gøre dem sammenlignelige.
Hvad er med i begge? Hvad findes kun i det ene? Hvad skal kunden selv levere? Hvilke forudsætninger er der taget? Hvad er ikke med? Og hvor ligger den største usikkerhed?
Nogle gange fører den gennemgang også til et andet spørgsmål:
Har vi overhovedet brug for en ny hjemmeside?
Måske kan den eksisterende løsning ryddes op, redesignes eller udbygges. Hvis det løser problemet, ville jeg hellere bruge pengene dér end bygge nyt, bare fordi projektet begyndte med en forespørgsel på en ny hjemmeside.
Det billigste tilbud kan sagtens være det rigtige
Hvis opgaven kan løses ordentligt for 30.000 kroner, er der ingen præmie for at bruge 120.000.
Hvis det billige tilbud derimod mangler arbejde, som virksomheden alligevel får brug for, er noget af regningen bare flyttet til senere.
Derfor synes jeg heller ikke, spørgsmålet "Hvad koster en hjemmeside?" kan besvares særlig meningsfuldt med ét tal.
Jeg ville begynde et andet sted:
Hvad skal hjemmesiden kunne, hvad kræver det at bygge den ordentligt, og hvad skal der ske med den bagefter?
Når man ved det, kan man begynde at sammenligne priser.
Hvor forsvinder timerne hen?
For en almindelig virksomhedshjemmeside kan arbejdet eksempelvis fordele sig sådan:
01_Afklaring & planlægningbehov, mål, scope, krav og tekniske valg.4–10 timer
02_Informationsarkitektursider, navigation og indholdsstruktur.4–12 timer
03_UX & wireframesbrugerflows, funktioner, wireframes og prototyper.8–20 timer
04_Visuelt designlayout, typografi, farver, komponenter og responsive versioner.12–30 timer
05_Frontend-udviklingHTML, CSS, JavaScript, animationer og komponenter.20–50 timer
06_CMS & backendopsætning, datamodeller, administration og brugerrettigheder.12–30 timer
07_Specialudviklingfunktioner og logik, der ikke findes som standard.4–30+ timer
08_IntegrationerCRM, ERP, PIM, betaling, nyhedsbrev og API'er.4–30+ timer
09_Indhold & migreringtekster, billeder, dokumenter og eksisterende data.4–20+ timer
10_Formularer & mailformularer, notifikationer, spam-beskyttelse og maillevering.4–12 timer
11_Teknisk SEOmetadata, URL-struktur, redirects, canonicals og strukturerede data.4–12 timer
12_Performancebilleder, caching, scripts, database og Core Web Vitals.4–10 timer
13_Tracking & samtykkeanalytics, tags og cookie consent.2–6 timer
14_Test & fejlretningmobil, browsere, formularer, integrationer og skærmstørrelser.8–20 timer
15_Tilgængelighedtastatur, kontraster, semantik og skærmlæsere.4–12 timer
16_Hosting & deploymentserver, DNS, SSL, staging, produktion og backup.4–10 timer
17_Sikkerhed & driftopdateringer, overvågning og løbende vedligeholdelse.2–8 timer*
18_LanceringDNS-skift, redirects, indeksering og kontrol af løsningen.4–10 timer
19_Dokumentation & overdragelsedokumentation, instruktion og overdragelse til dem, der skal arbejde videre.2–8 timer
20_Projektstyring & dialogmøder, koordinering, feedback, prioritering og løbende afklaringer.8–20 timer
Ikke alle hjemmesider kræver alle opgaverne — en simpel løsning kan springe flere af dem over eller løse dem på få timer, mens integrationer, migrering eller specialudvikling alene kan tage væsentligt længere end intervallerne ovenfor på andre projekter. Det er derfor ikke en prisliste eller en opskrift på, hvor lang tid en hjemmeside skal tage — det er et eksempel på, hvad der kan gemme sig bag de to ord "design og udvikling" i et tilbud.
*Drift er typisk løbende, så timerne her dækker primært etablering og klargøring omkring lanceringen.
Teknisk rådgivningJeg hjælper med at gennemskue tilbud, vurdere om en løsning skal bygges, redesignes eller udbygges, og finde den løsning, der matcher opgaven uden unødvendig kompleksitet.
En langsom hjemmeside kan skyldes et billede på 4 MB. Den kan også skyldes 10 andre ting. Det første spørgsmål er derfor ikke, hvad sitet er bygget i – det er, hvor tiden forsvinder hen.
En langsom hjemmeside kan skyldes et billede på 4 MB.
Det kan også være serveren, der bruger to sekunder på at svare. Et script fra et statistikværktøj. Et plugin, der laver alt for meget arbejde. En databaseforespørgsel, der burde tage 20 millisekunder, men tager halvandet sekund.
Eller lidt af det hele.
Når nogen fortæller mig, at deres hjemmeside er langsom, er mit første spørgsmål derfor normalt ikke, hvad den er bygget i.
Jeg måler den.
Ellers risikerer man at bruge en halv dag på at optimere billeder på et website, hvor problemet i virkeligheden ligger et helt andet sted.
Hvad betyder langsom?
Det er faktisk det første, man skal finde ud af.
Er det den første side, der tager lang tid om at komme frem? Er siden synlig hurtigt, men reagerer langsomt, når man klikker? Hopper indholdet rundt, mens siden loader? Er det kun produktsiderne? Kun på mobil? Kun for brugere, der ikke er logget ind?
Eller føles hele sitet bare tungt?
De symptomer kan have meget forskellige årsager.
En langsom server kan betyde, at browseren står og venter, før den overhovedet får noget at vise. Et stort billede kan betyde, at siden begynder hurtigt, men bruger lang tid på at få det vigtigste indhold på plads. For meget JavaScript kan betyde, at alt tilsyneladende er hentet, mens browseren stadig står og arbejder.
Derfor er "langsom" ikke præcist nok til at begynde at optimere efter.
Men jeg bruger dem som diagnoseværktøjer, ikke som facit.
Jeg vil blandt andet vide, hvor lang tid serveren er om at svare. Hvilke filer browseren henter. Hvor store de er. Hvornår det vigtigste indhold bliver synligt. Hvad der blokerer browseren undervejs. Og hvad der sker ude hos rigtige brugere.
Har sitet trafik nok, foretrækker jeg feltdata.
En laboratorietest fortæller, hvad der skete under én kontrolleret test. Feltdata fortæller, hvad der faktisk sker på telefoner, computere og netværk ude hos brugerne.
De to ting er ikke altid enige.
Billeder er stadig en klassiker
Jeg møder stadig websites, hvor et billede bliver vist i 600 pixels bredde, men browseren får tilsendt en original på 4.000 pixels.
Det er sjældent nødvendigt.
Billeder skal have fornuftige dimensioner, komprimeres ordentligt og leveres i et format, browseren kan håndtere effektivt. Og billeder længere nede på siden behøver normalt ikke blive hentet, før brugeren nærmer sig dem.
Men billedoptimering er også et godt eksempel på, hvorfor man skal måle først.
Hvis billederne allerede er rimeligt optimerede, får man ikke meget ud af at bruge tre timer på at presse yderligere 30 KB ud af dem.
Der er ingen gevinst i at optimere det forkerte problem meget grundigt.
JavaScript har en pris
Det moderne web kan utrolig meget.
Det betyder også, at vi sender utrolig meget kode ned i browseren.
Hver enkelt integration kan være fuldstændig legitim.
Men browseren er ligeglad med organisationsdiagrammet. Den skal stadig hente og afvikle det hele.
Jeg vil derfor ofte hellere finde ud af, hvorfor et script er på siden, end spare nogle få kilobytes i en CSS-fil. Hvis ingen længere ved, hvorfor et tredjepartsscript bliver indlæst på samtlige sider, er det værd at undersøge.
Det hurtigste script er trods alt det, browseren aldrig behøver at hente.
Nogle gange ligger problemet på serveren
Man kan optimere frontend nok så meget, men hvis serveren bruger lang tid på at fremstille siden, begynder man allerede bagud.
På et WordPress-site kan årsagen eksempelvis være plugins, tunge databaseforespørgsler, eksterne API-kald eller manglende caching. På en specialbygget løsning kan problemet være en forespørgsel, der henter langt mere data end nødvendigt, eller kode, der udfører det samme arbejde igen og igen. Og nogle gange er serveren ganske enkelt underdimensioneret eller dårligt konfigureret.
Her hjælper det ikke meget at konvertere endnu et billede til WebP.
Man er nødt til at finde flaskehalsen.
Caching kan gøre en enorm forskel
Hvis en side stort set er den samme for alle besøgende, er der sjældent nogen grund til at bygge den helt forfra ved hvert eneste besøg.
Det er grundidéen i caching.
Men caching findes i flere lag. Browseren kan gemme filer. En CDN kan levere dem tættere på brugeren. Webserveren kan cache hele sider eller dele af dem. Applikationen kan gemme resultater, som ellers skulle beregnes igen. Databasen kan undgå at blive spurgt om det samme hele tiden.
Det kan gøre en meget stor forskel.
Men caching kan også ende som et plaster på en løsning, der grundlæggende laver for meget arbejde. Hvis en databaseforespørgsel tager tre sekunder, vil jeg gerne vide hvorfor – også selv om vi bagefter cacher resultatet.
Plugins er ikke langsomme. Nogle plugins er.
På WordPress ender diskussionen hurtigt med antallet af plugins.
"Vi har 37 plugins," siger kunden som regel. "Er det derfor, sitet er langsomt?"
Måske.
Men 37 fortæller mig ikke ret meget i sig selv.
Et lille plugin kan lave én simpel ting og næsten ikke kunne måles. Et andet kan indlæse scripts og styles på alle sider, lave eksterne kald og udføre en håndfuld databaseforespørgsler ved hvert besøg.
Derfor vil jeg vide, hvad de 37 plugins laver, før jeg begynder at slette dem. Det samme gælder temaer, frameworks og tredjepartsløsninger.
Mobilen er ofte dér, virkeligheden viser sig
Et website kan føles hurtigt på udviklerens MacBook med fiberforbindelse og stadig være langsomt for en stor del af brugerne.
En telefon har ikke nødvendigvis samme processorkraft. Forbindelsen er ikke nødvendigvis stabil. Og browseren kan samtidig have en hel del andet at lave.
"Det loader da hurtigt hos mig," hører jeg indimellem. Det er derfor ikke en særlig brugbar performance-måling.
Det er også en af grundene til, at jeg foretrækker feltdata, når der er nok af dem. Jeg vil hellere vide, hvad brugerne oplever, end hvor hurtigt sitet er på min egen computer.
Skal alt være grønt?
Nej.
Jeg kan godt lide grønne tal.
Men jeg ville ikke bruge timer på at flytte en Lighthouse-score fra 98 til 100, hvis brugerne allerede har en hurtig oplevelse, og tiden kunne bruges på noget vigtigere.
Det gælder også Core Web Vitals. De er nyttige, fordi de måler forskellige dele af brugeroplevelsen. Men et website skal stadig fungere uden for måleværktøjet.
Lighthouse er en diagnose, ikke en karakter.
Hvad gør man så ved en langsom hjemmeside?
Jeg ville ikke begynde med at installere endnu et performance-plugin.
Jeg ville begynde med at finde ud af, hvor tiden forsvinder.
Er serverens svartid problemet, undersøger jeg server, applikation, database og caching. Er det billederne, arbejder jeg med størrelse, format og levering. Er browseren begravet i JavaScript, finder jeg ud af, hvad der bliver kørt, hvornår det bliver kørt, og om det overhovedet behøver være der. Er det tredjepartsscripts, må man nogle gange tage en diskussion om, hvorvidt værdien af dem står mål med prisen. Og er problemet kun på bestemte sidetyper, begynder jeg dér.
Først måle. Så optimere.
Performancearbejde handler selvfølgelig om teknik. Men en stor del af arbejdet handler om prioritering. Der vil næsten altid være mere, man kan optimere. Spørgsmålet er, hvad der faktisk gør en mærkbar forskel.
Derfor begynder jeg med målingen og arbejder mig frem til årsagen, før jeg ændrer noget. Ellers risikerer man at gøre det, der er nemmest at optimere, i stedet for det, der faktisk gør hjemmesiden langsom.
Det hurtigste website er ikke nødvendigvis det med den højeste score. Det er det, der føles hurtigt for dem, der skal bruge det.
Performance & SEOJeg arbejder med performance fra måling og diagnose til billeder, caching, databaseforespørgsler, JavaScript og teknisk SEO. Målet er ikke 100 i Lighthouse. Målet er et hurtigt website, der fungerer godt for rigtige brugere.
WordPress, Umbraco, Drupal, Shopify, Webflow eller noget helt sjette? Mit lidt irriterende svar er som regel: Hvad skal det bruges til?
Jeg bliver indimellem spurgt, hvilket CMS jeg ville vælge i dag.
Mit lidt irriterende svar er som regel: Hvad skal det bruges til?
Spørgsmålet om, hvilket CMS der er bedst, giver omtrent lige så lidt mening som spørgsmålet om, hvilket køretøj der er bedst.
En varevogn er fremragende, hvis man skal flytte et køleskab. Den er mindre oplagt, hvis man skal køre Le Mans.
Det samme gælder CMS'er.
Start med opgaven
Jeg har arbejdet med blandt andet WordPress, Umbraco, Magento og Shopify og overtaget løsninger bygget af andre. Det har ikke gjort mig mere overbevist om, at ét system er det rigtige.
Tværtimod.
Et system kan være fremragende og stadig være det forkerte valg.
Hvis opgaven er et almindeligt virksomhedswebsite med sider, artikler, cases, medarbejdere og nogle formularer, kan WordPress være et meget pragmatisk valg – se WordPress – kort fortalt for hvorfor.
Hvis virksomheden i forvejen arbejder tungt med Microsoft og .NET, har egne udviklere og mere komplekse integrationer, kan Umbraco give mere mening.
Hvis opgaven først og fremmest er at sælge varer, ville jeg ikke begynde med spørgsmålet om CMS. Så ville jeg begynde med e-commerce. Her kan Shopify være det oplagte valg, mens Magento kan give mening i en helt anden størrelse og kompleksitet.
Hvis marketing selv skal kunne bygge og ændre meget af sitet visuelt uden konstant at involvere en udvikler, er Webflow værd at kigge på.
Og Drupal?
Det kan være et stærkt valg, når kompleksiteten faktisk kræver det. Mange indholdstyper, rettigheder, workflows, flere redaktørgrupper og krav til governance kan ændre regnestykket.
Men jeg ville ikke vælge Drupal, fordi det kan mere.
Jeg ville vælge det, hvis opgaven kræver det, det kan mere.
Måske skal du slet ikke have et CMS
Det bliver lidt overset i diskussionen.
Når man skal bygge et website, bliver CMS'et ofte behandlet som en selvfølge. Først vælger vi CMS, og bagefter finder vi ud af, hvordan resten skal passe ind i det.
Men måske ligger produktdata allerede i et PIM. Kundedata i et CRM. Priser i et ERP-system. Brugerne i en applikation. Og måske består det indhold, nogen faktisk skal redigere, af ti sider og fire tekstfelter.
Så er spørgsmålet ikke nødvendigvis, hvilket stort CMS man skal installere.
Måske er et lille administrationsinterface nok. Måske giver et headless CMS mening – jeg har skrevet mere om den afvejning i WordPress vs. headless. Måske skal CMS'et kun være én af flere datakilder.
Og nogle gange er den bedste beslutning at beholde det system, man allerede har. Man behøver ikke udskifte teknologi, bare fordi der findes nyere teknologi – se også Hvornår skal man skifte CMS?
Hvem skal arbejde i det mandag morgen?
Det spørgsmål er ofte vigtigere end featurelisten.
For det teknisk bedste CMS kan være et dårligt valg, hvis marketingafdelingen hader at arbejde i det.
Og det mest redaktørvenlige system kan være et dårligt valg, hvis udviklerne skal kæmpe mod platformen, hver gang virksomheden vil noget, der ligger lidt uden for standarden.
Jeg ville derfor se på valget fra mindst tre sider.
Brugeren: Hvad skal den besøgende faktisk kunne?
Redaktøren: Hvem skal oprette og vedligeholde indholdet, og hvor tekniske er de?
Forretningen og udviklerne: Hvilke integrationer, funktioner og ændringer skal løsningen kunne rumme de næste år?
Det sidste er vigtigt.
Man vælger ikke kun CMS til det website, man lancerer på fredag. Man vælger også en del af fundamentet for de ændringer, man endnu ikke kender.
Hvad koster det egentlig?
Prislisten fortæller kun en del af historien.
Et open source-CMS er ikke gratis, bare fordi licensen er det. Og et system med månedligt abonnement er ikke nødvendigvis dyrt, bare fordi der står et beløb på fakturaen hver måned.
Udvikling. Hosting. Opdateringer. Plugins og extensions. Integrationer. Sikkerhed. Redaktørernes tid.
Et CMS koster ikke kun det, der står på fakturaen. Det koster også tid at udvikle, drive og ændre.
Tid for redaktørerne, når noget er besværligt. Og tid for den næste udvikler, der skal forstå de beslutninger, der er blevet truffet undervejs.
Derfor kan et CMS uden licens være dyrere end et med abonnement. Og en løsning, der er billig at bygge, kan blive dyr at eje.
Og så er der afhængigheden.
Kan en anden udvikler overtage? Kan data eksporteres? Er virksomheden bundet til et bestemt bureau, en bestemt hostingplatform eller en bunke specialkode, ingen længere helt ved, hvorfor findes?
Den billigste løsning på lanceringsdagen er ikke nødvendigvis den billigste løsning efter fem år.
Hvad ville jeg vælge?
Det kommer an på opgaven.
Det er stadig det irriterende svar.
Jeg har ingen principiel modstand mod WordPress, Umbraco, Drupal, Shopify, Webflow, Magento eller headless. Jeg har heller ingen særlig interesse i at bruge dem, hvis de ikke løser problemet.
Jeg ville først finde ud af, hvad brugerne skal kunne. Hvad redaktørerne skal kunne. Hvilke systemer løsningen skal tale med. Hvem der skal drive den. Og hvad virksomheden realistisk forventer, at løsningen skal udvikle sig til.
Derefter ville jeg begynde at kigge på teknologi.
For hvis nogen anbefaler et bestemt CMS, før de har spurgt til indholdet, redaktørerne, integrationerne og forretningen omkring det, ville jeg være en smule skeptisk.
Man skal ikke finde en opgave til sit CMS. Man skal finde et CMS til sin opgave.
En visuel identitet skal kunne fungere uden grafikeren
En visuel identitet er nem at få til at se godt ud på en skærm. Det bliver sværere, når den skal ud i virkeligheden – i en PowerPoint, på en faktura, på et skilt nogen selv retter i tre år senere.
En visuel identitet er nem at få til at se godt ud på en computerskærm.
Det bliver sværere, når den skal ud i virkeligheden.
Logoet skal på hjemmesiden. I en PowerPoint. På LinkedIn. I en mail-signatur. På en faktura. Måske på et skilt, en bil, en T-shirt eller noget så banalt som et Word-dokument, nogen selv retter i tre år senere.
Og pludselig er det ikke længere grafikeren, der sidder med filen.
Det er dér, man finder ud af, om man har lavet en visuel identitet eller bare et flot design.
Det begynder næsten altid med den pæne version
Når man udvikler en identitet, er det fristende at vise den dér, hvor den tager sig bedst ud.
Logoet står med masser af luft omkring sig. Typografien sidder perfekt. Farverne er rigtige. Fotografiet passer til kompositionen. Ingen har skrevet en overskrift, der er dobbelt så lang som den, designeren brugte i oplægget.
Man er nødt til at vise idéen under ordentlige forhold.
Problemet opstår, hvis identiteten kun fungerer under ordentlige forhold.
For det gør virkeligheden sjældent.
Et logo, der fungerer fantastisk i toppen af en hjemmeside, kan blive ulæseligt som profilbillede på LinkedIn. En skrifttype, der fungerer på en Mac, findes måske ikke på den Windows-maskine, hvor salgsafdelingen laver PowerPoint. En sart farve, der ser fantastisk ud på en kalibreret skærm, kan falde fuldstændig sammen på en kontorprinter.
Og det grafiske element, der binder hele identiteten sammen i designmanualen, kan vise sig at være næsten umuligt at bruge i en mailsignatur.
Det er ikke undtagelserne. Det er opgaven.
En identitet er et system
Jeg har altid haft lidt svært ved idéen om, at en visuel identitet først og fremmest er et logo.
Logoet er selvfølgelig vigtigt. Men det er kun én af de komponenter, der får en virksomhed til at ligne sig selv.
Typografi. Farver. Billedstil. Afstande. Hierarki. Former. Ikoner. Måden en overskrift står på. Hvor meget der må ske på én gang. Og lige så vigtigt: hvad man konsekvent lader være med at gøre.
Tilsammen danner de et system.
Et godt system betyder ikke, at alt skal se ens ud.
Det betyder, at tingene skal kunne være forskellige og stadig tydeligt høre sammen.
En faktura behøver ikke ligne hjemmesiden. En LinkedIn-annonce skal ikke ligne et visitkort. En præsentation har andre krav end et skilt.
Men man skal helst kunne mærke, at den samme afsender står bag.
Og systemet skal kunne tåle de situationer, designeren ikke selv har planlagt.
Kan overskriften stadig fungere, når den er 73 tegn lang? Kan logoet genkendes i 32 × 32 pixels? Kan en ekstern leverandør forstå systemet uden at ringe til grafikeren?
Det er ofte dér, det viser sig, om identiteten holder.
Designmanualen er ikke identiteten
Jeg har lavet designmanualer med regler for logo, farver, typografi, billedbrug og produktion.
De er nyttige.
Men en designmanual kan også blive en meget flot dokumentation af et system, ingen i praksis kan bruge.
Der kan stå præcis, hvor meget luft logoet skal have omkring sig. Det hjælper ikke meget, hvis den person, der skal lave næste præsentation, ikke kan finde den rigtige logofil.
Der kan stå seks RGB-, CMYK- og Pantone-værdier. Det hjælper ikke, hvis ingen har besluttet, hvilken farve der skal bruges som standard i PowerPoint.
Der kan være fire forskellige logovarianter. Det hjælper ikke, hvis ingen kan gennemskue, hvornår de skal bruge hvilken.
En identitet bliver ikke stærkere af at have flere regler. Den bliver stærkere af at have de rigtige regler. Og nogle gange af at have færre.
Når andre skal overtage
Det er i virkeligheden her, meget af mit arbejde med visuel identitet ligger.
Ikke kun i at designe noget, der ser rigtigt ud, men i at gøre det muligt for andre at bruge det bagefter.
Det kan være en udvikler, der skal omsætte farver, typografi og spacing til komponenter og CSS. En marketingmedarbejder, der skal lave et opslag. En sælger, der åbner PowerPoint. Et trykkeri, der skal bruge den rigtige PDF. Eller en virksomhedsejer, der fredag eftermiddag selv skal ændre åbningstiden på et skilt.
De mennesker skal ikke nødvendigvis forstå alle de grafiske overvejelser bag identiteten.
Systemet skal hjælpe dem med at træffe nogenlunde de rigtige valg alligevel.
Det er dér, design går fra at være en leverance til at blive noget, virksomheden faktisk kan bruge.
Når alle pludselig kan lave grafik
AI skærper problemet.
Jeg skrev i Er mit job som grafiker truet? om, hvordan AI gør selve produktionen af grafik billigere. Det betyder også, at langt flere i en virksomhed kan fremstille noget selv.
Marketing kan generere et billede. Salg kan lave en præsentation. Direktøren kan få AI til at lave en illustration. En ekstern samarbejdspartner kan generere en annonce.
Hver enkelt ting kan isoleret set se ganske professionel ud.
Og tilsammen kan virksomheden begynde at ligne fem forskellige virksomheder.
Det gør ikke behovet for en visuel identitet mindre. Tværtimod bliver det vigtigere at kunne beskrive, hvad der får virksomheden til at ligne sig selv.
Farver og fonte er en del af det. Men også billedstil, komposition, tone og kontrast.
Tidligere lavede man den slags rammer, så andre kunne arbejde videre med identiteten uden grafikeren ved siden af. Nu skal rammerne også fungere, når nogen sætter AI til at producere noget.
Forskellen mellem to prompts bliver større:
"Lav et professionelt billede til vores LinkedIn-opslag" – over for – "Lav noget, der tydeligt ligner os."
Det sidste kræver, at der faktisk findes et os at ligne.
Den skal kunne tåle at blive brugt
Den bedste test af en visuel identitet kommer ikke nødvendigvis, når den bliver præsenteret.
Den kommer seks måneder senere.
Når nogen har lavet en præsentation uden at spørge. Når udvikleren har bygget den næste funktion på hjemmesiden. Når der er kommet en ny medarbejder. Når et dokument skal printes på kontorets printer fem minutter før et møde. Når AI har genereret et billede til et opslag. Når logoet pludselig skal stå på noget, ingen havde tænkt på, da identiteten blev lavet.
Hvis virksomheden stadig ligner sig selv dér, begynder identiteten at have bevist sit værd.
For en visuel identitet skal ikke kun se rigtig ud, når den bliver præsenteret.
Den skal kunne holde, når grafikeren ikke længere er i rummet.
AI-genereret grafik er rykket ud af computeren og ind i den virkelige verden. Spørgsmålet er ikke længere, om AI kan lave grafik. Det kan den. Spørgsmålet er, hvad der så er tilbage af grafikerens arbejde.
Det slog mig for alvor i sommers, da jeg var ude at rejse.
På menukort og A-skilte foran restauranterne dukkede den samme type billeder op igen og igen. Burgere, pizzaer, cocktails og durum kebab med et udtryk, jeg efterhånden forbinder med AI-genereret grafik.
Man kunne stadig godt se det. AI kan åbenbart endnu ikke helt finde ud af at lave en lækker burger eller en durum kebab, man faktisk får lyst til at spise.
Men det er nok mest et spørgsmål om tid.
Siden er jeg begyndt at lægge mærke til det andre steder. I Facebook-opslag, annoncer og små virksomheders markedsføring. Ikke nødvendigvis fordi jeg med sikkerhed kan afgøre, at noget er lavet med AI, men fordi der er begyndt at tegne sig en genkendelig æstetik: glat, overtydelig og lidt mere reklameagtig, end afsenderen måske selv er.
Det interessante var ikke så meget, om billederne var gode eller dårlige.
Det var, at jeg pludselig stod og kiggede på noget, en grafiker, illustrator eller fotograf tidligere kunne være blevet betalt for at lave.
Og som grafiker er det svært ikke at stille spørgsmålet:
Er det noget af mit arbejde, jeg står og kigger på?
Det er blevet billigt at lave noget, der ser godt ud
For få år siden havde en mindre restaurant grundlæggende tre muligheder, hvis den skulle bruge en illustration til et menukort eller et skilt.
Man kunne selv lave den. Man kunne finde noget eksisterende stockmateriale. Eller man kunne betale en grafiker eller illustrator for at lave den.
Nu findes der en fjerde mulighed.
Man beskriver, hvad man vil have, og kort tid efter har man ikke ét forslag, men ti eller tyve. Kan man ikke lide resultatet, prøver man igen.
Hvis en lille café uden nævneværdigt marketingbudget nu kan få lavet en illustration, som gør dens menukort mere indbydende, har jeg svært ved at argumentere for, at den burde have betalt en grafiker i stedet.
Det ville mest være et argument for at bevare mit eget arbejde.
AI har fjernet en produktionsbarriere, og for mange mennesker er det en reel forbedring.
Men var det overhovedet min opgave?
På den korte bane føler jeg mig faktisk ikke særlig truet.
For sandheden er, at mange af de AI-genererede ting, jeg ser, aldrig ville være landet på mit skrivebord alligevel.
Restauranten i den lokale fodboldklub, der laver et nyt menukort hver uge, ville næppe tidligere have ringet til en grafiker hver torsdag. Det kunne ganske enkelt ikke betale sig.
Måske havde de selv rettet lidt i et gammelt Word-dokument. Måske var den gamle menu bare blevet hængende en uge mere.
Nu kan de lave noget nyt på få minutter.
I det tilfælde har AI ikke overtaget grafikerens arbejde. AI har løst en opgave, som tidligere slet ikke ville være blevet løst, fordi forholdet mellem pris og udbytte ikke gav mening.
Men det betyder ikke, at markedet bare bliver større, og at ingen mister noget.
Når det bliver muligt at få lavet grafik næsten gratis, ændrer det også forventningen til, hvad grafik bør koste. En virksomhed, der tidligere ville have samlet sine behov og betalt en grafiker for en større opgave, kan nu begynde at løse dele af den selv.
Og noget af det, der starter som opgaver, jeg aldrig ville have fået, kan sagtens bevæge sig ind på områder, jeg tidligere tog betaling for.
Grænsen mellem nyt arbejde skabt af AI og gammelt arbejde overtaget af AI er derfor ikke særlig skarp.
Det er også derfor, jeg på den korte bane ikke føler mig særlig truet, samtidig med at jeg godt kan se, hvor udviklingen peger hen.
Noget af mit gamle arbejde er truet
Hvis opgaven er:
"Lav en flot illustration af en burger, som vi kan sætte på vores A-skilt."
så er behovet for mig mindre, end det var for fem år siden.
Det samme gælder variationer over en idé. Fritlægning af billeder. Udvidelse af et fotografi. En hurtig illustration. Forskellige visuelle retninger. Materiale i flere formater.
Det er opgaver, som tidligere kunne kræve en person med bestemte værktøjer og færdigheder, og som nu i nogle tilfælde kan løses på få minutter.
Da jeg lærte grafisk arbejde, var værktøjerne i sig selv en væsentlig del af kompetencen. Man skulle kunne Photoshop, Illustrator og InDesign.
Men håndværket bestod aldrig kun i at kunne betjene programmerne.
Det var også at forstå farvestyring og vide, hvad der sker, når noget bevæger sig fra skærm til tryk. At levere filer med de rigtige farveprofiler, beskæring og bleed. At håndtere fonte korrekt. At forstå opløsning, billedformater og forskellige produktionsmetoder.
Og det var at opdage, at teksten på skiltet ikke kan læses på den afstand, det faktisk skal ses fra. At kontrasten er for lav. At logoet bliver for småt. At det vigtigste budskab drukner. At noget, der ser godt ud på min skærm, ikke nødvendigvis fungerer på et A-skilt, en telefon eller i tryk.
Grafikeren leverer med andre ord ikke bare en fil. En del af arbejdet er at forstå, hvor og hvordan den skal fungere.
Meget af den viden var samtidig en adgangsbillet til arbejdet. Kunden betalte blandt andet grafikeren, fordi grafikeren kunne noget, kunden ikke selv kunne.
Den adgangsbillet er blevet billigere.
Man behøver ikke længere beherske alt det for at fremstille noget, der ved første øjekast ser professionelt ud.
Men man behøver stadig en del af det, hvis resultatet også skal fungere, når det forlader skærmen.
Og når langt flere pludselig kan fremstille deres egen grafik, opstår et andet paradoks: Resultaterne bliver mere individuelle, men begynder samtidig at ligne hinanden.
Hvorfor ligner det så alligevel noget, jeg har set før?
Mulighederne er nærmest blevet uendelige. Alligevel er der et udtryk, som går igen.
Mættede farver. Bløde illustrationer. Store smil. Perfekte produkter. Dramatisk lys. Meget lidt tilfældighed.
Det hele ser på en måde rigtigt ud. Måske lidt for rigtigt.
Men det er ikke et nyt problem.
Stockfotos gav os mødelokaler fyldt med usædvanligt glade mennesker. WordPress-temaer fik tusindvis af virksomheder til at have nogenlunde samme hjemmeside. Bootstrap gjorde det muligt at bygge en pæn brugerflade uden selv at designe alle elementerne. Canva gjorde professionelt udseende layouts tilgængelige for mennesker, der aldrig havde åbnet InDesign.
AI er endnu et skridt i den retning.
Forskellen er, at resultatet ikke længere behøver være den samme skabelon eller det samme stockfoto. Hvert billede kan være unikt.
Og alligevel kan de godt føles ens.
Der er måske også en geografisk slagside i det.
Meget af den generative AI, vi bruger, er udviklet af amerikanske virksomheder til et globalt marked. Det kan mærkes i æstetikken. Det polerede, farvemættede og meget eksplicitte visuelle sprog ligger ofte tættere på international reklameæstetik end på den mere afdæmpede nordiske designtradition, jeg selv er vokset op med.
Det betyder ikke, at AI kun kan lave amerikansk grafik. Man kan selvfølgelig bede om noget andet, og modellerne bliver hele tiden bedre til at ramme bestemte stilarter, steder og kulturelle referencer.
Men standardforslaget betyder noget.
Hvis millioner af mennesker pludselig får adgang til et værktøj, der kan træffe en stor del af de visuelle valg for dem, får værktøjets idé om, hvordan noget "godt" ser ud, også betydning for det visuelle landskab omkring os.
På den måde er modellen måske ved at få lidt af den samme rolle, som skabelonen havde før. Forskellen er bare, at skabelonen ikke længere er synlig. To mennesker kan få to forskellige billeder og stadig ende med noget, der bygger på nogenlunde de samme æstetiske valg.
Resultatet kan være unikt uden nødvendigvis at være særligt originalt.
Det er også en del af grafikerens arbejde, der måske bliver vigtigere. Ikke nødvendigvis at fremstille alternativet, men at kunne se, når standardforslaget ikke passer. Når den lokale restaurant pludselig ligner en amerikansk fastfoodkæde, eller en dansk virksomhed får et visuelt udtryk, der kunne tilhøre hvem som helst.
Det kræver ikke nødvendigvis, at jeg selv tegner illustrationen. Men det kræver, at nogen opdager, at den er forkert.
Også den observation har selvfølgelig en udløbsdato.
Modellerne bliver bedre til lokale referencer, og brugerne bliver bedre til at styre dem. Måske bliver det om nogle år langt sværere overhovedet at tale om en genkendelig AI-æstetik.
Men lige nu synes jeg, den er der.
Grafik og grafisk design er ikke helt det samme
Det er måske her, mellem at fremstille og at beslutte, den vigtigste forskel ligger.
AI er blevet meget god til at fremstille grafik. Men at fremstille noget er ikke det samme som at beslutte, hvad der skal være der – eller hvordan det skal fungere, når det møder virkeligheden.
Grafisk design har aldrig kun handlet om at kunne lave det, der ender på siden.
Hvad skal fylde? Hvad skal næsten ikke kunne ses? Hvem skal forstå det? Kan det læses på den afstand, det skal ses fra? Hvilken typografi passer til stedet? Skal udtrykket være humoristisk, eksklusivt, billigt, alvorligt eller næsten usynligt?
Og måske det vigtigste spørgsmål:
Skal der overhovedet være et billede?
Det er den del af grafisk arbejde, der er nem at overse, fordi resultatet af en god beslutning nogle gange netop er, at der ikke bliver lavet særlig meget.
AI kan også hjælpe med beslutningerne
Det ville være lidt for bekvemt at stoppe argumentet dér og sige, at AI kan producere, mens mennesket tænker.
For AI bliver også bedre til det sidste.
Jeg kan allerede bruge AI til at diskutere et layout, foreslå retninger, kritisere en komposition, finde alternativer og stille spørgsmål til mine egne valg. Det er ikke længere bare en billedgenerator i den anden ende.
Så jeg tror heller ikke på den beroligende version af historien, hvor AI overtager det kedelige arbejde, mens vi mennesker beholder alt det kreative.
Grænsen er ikke så pæn.
Hvis produktionen er blevet billigere, er der ingen grund til at tro, at vurderingen og beslutningerne for altid vil være forbeholdt os.
Fra at fremstille til at vælge
Jeg oplever noget tilsvarende i mit arbejde med kode.
AI betyder, at jeg kan producere mere kode hurtigere end tidligere. Derfor bruger jeg mindre af min tid på selve produktionen og mere på at vurdere det, der bliver produceret.
Er det den rigtige løsning? Passer den ind i resten? Hvad mangler? Hvad skal fjernes? Hvad bliver dyrt om tre år?
Noget af det samme er ved at ske med grafik.
Når det bliver billigt at fremstille ti forslag, bliver det mere værdifuldt at kunne se, hvilket af dem der er det rigtige.
Eller at alle ti er forkerte.
Erfaringen forsvinder ikke, fordi produktionen bliver lettere. Men den bliver brugt et andet sted.
Det flytter ikke nødvendigvis grafikeren ud af processen. Det flytter, hvor i processen grafikeren skaber værdi.
Et øjebliksbillede
Der er et grundlæggende problem ved at skrive en artikel som denne:
Konklusionen har en udløbsdato.
Det, AI kan i dag, er ikke nødvendigvis det, den kan om et år. Nogle af de ting, jeg i dag kan pege på som forskellen mellem at generere et billede og levere grafisk arbejde, bliver den også bedre til.
Konklusionen i den artikel er, at AI på kort sigt ikke ændrer, hvad jeg kan – men den ændrer min arbejdsgang.
Pointen er ikke, at udviklingen nødvendigvis fortsætter i en lige linje, eller at AI bliver bedre til alt.
Pointen er, at det er farligt at bygge sin faglige identitet på de ting, AI ikke kan endnu.
For et år siden kunne jeg pege på opgaver i mit arbejde med kode, hvor AI ikke var særlig nyttig. Nogle af dem bruger jeg AI til i dag. Der er ingen særlig god grund til at tro, at grafik bliver anderledes.
Derfor kan mine konklusioner her kun være et øjebliksbillede.
Hvis jeg genlæser artiklen om to år, er der sandsynligvis ting, jeg i dag betragter som grafikerens område, som AI til den tid løser uden større problemer.
Det interessante er derfor ikke kun, hvor grænsen går lige nu.
Det er, hvad der sker, når den flytter sig.
Så er jeg truet som grafiker?
På den korte bane: ikke særlig meget.
En del af den AI-grafik, jeg ser omkring mig, repræsenterer ikke tabte opgaver. Den repræsenterer opgaver, som aldrig ville være blevet bestilt hos en grafiker til at begynde med.
Men dele af mit arbejde er truet.
Så når jeg står foran det A-skilt og tænker, om det er noget af mit gamle arbejde, jeg kigger på, er svaret både ja og nej.
Nogle af illustrationerne kunne have været opgaver, jeg engang blev betalt for at lave. Andre eksisterer kun, fordi de nu kan fremstilles så billigt, at nogen synes, det er værd at gøre.
Og de to kategorier kommer sandsynligvis til at flyde mere og mere sammen. Når virksomheder opdager, at de selv kan løse små grafiske opgaver, stopper det ikke nødvendigvis ved de opgaver, de aldrig tidligere ville have købt.
Om AI lige nu har lavet en burger med lidt mærkelig ost eller en durum kebab, ingen rigtig får lyst til at spise, er næppe det, der kommer til at redde grafikerfaget.
Det bliver bedre.
Men der er stadig nogle spørgsmål tilbage.
Passer billedet til restauranten? Ser stedet ud som sig selv? Eller er det bare endnu en unik illustration, der alligevel ligner alle de andre? Kan skiltet læses fra den anden side af gaden? Hænger det sammen med menukortet, hjemmesiden og resten af oplevelsen? Og skulle illustrationen overhovedet have været der?
Når det bliver næsten gratis at fremstille et billede, bliver værdien i højere grad at kunne svare på de spørgsmål. Det er også det arbejde, jeg selv laver i visuel identitet: ikke kun at fremstille grafikken, men at afgøre, hvad den skal, og om den overhovedet skal være der.
Måske er jeg derfor mindre truet som grafiker, end jeg er udfordret på, hvad det vil sige at være grafiker.
De fleste stiller det forkerte spørgsmål først. Det interessante er ikke, hvilket CMS der er bedst – det er, om problemet overhovedet er CMS'et.
Spørgsmålet "skal vi have et nyt CMS?" kommer som regel før diagnosen. Nogen er blevet frustreret – redaktionen, udviklerne, ledelsen – og frustrationen bliver hurtigt oversat til et platformsspørgsmål, fordi det er det, der er lettest at handle på. Et nyt CMS er et projekt med en start og en slutning. At finde ud af, hvad der faktisk er galt, er sværere, og det bliver ofte sprunget over.
Først: hvad er det, der gør ondt?
Det, folk kalder "et CMS-problem", er som regel én af tre forskellige ting, og de kræver hver deres løsning.
Et vedligeholdelsesproblem. Gamle plugins, ingen opdateringer, kode ingen tør røre, ingen versionsstyring. Det er ikke platformens skyld – det er otte år, hvor ingen har ryddet op. Løsningen er oprydning, ikke et nyt system.
Et implementeringsproblem. Platformen er fin, men den konkrete løsning er bygget dårligt – en produktstruktur, der aldrig blev tænkt igennem, en integration limet sammen i sidste øjeblik, et indholdshierarki der gav mening for det første projekt og ikke for det, sitet er blevet til siden. Det løses ved at bygge om, ikke ved at skifte fundament.
Et platformsproblem. Det er det sjældneste af de tre, og det stærkeste argument for et nyt CMS: platformens måde at modellere data og håndtere arbejdsgange på passer ikke længere til det, virksomheden har brug for. Ikke fordi nogen har implementeret det dårligt – men fordi det, virksomheden skal kunne, ikke passer ind i den måde, platformen tænker indhold på. Nogle gange er svaret ikke et andet CMS, men en anden arkitektur omkring det eksisterende – se WordPress vs. headless.
Et platformsproblem kan også være mere grundlæggende: at systemet ikke længere vedligeholdes eller sikkerhedsopdateres og derfor ikke er forsvarligt at blive på.
De tre bliver konstant blandet sammen, og det er dyrt. Et vedligeholdelsesproblem løst med en migration er penge brugt forkert – og et reelt platformsproblem, der bliver mødt med endnu en oprydning, er tid, der bare udskyder den samme samtale et år.
Når problemet ikke er CMS'et
De fleste "vi bør skifte CMS"-samtaler starter her, uden at nogen har opdaget det. Plugins der overlapper, fordi forskellige udviklere har løst det samme problem to gange over otte år. Et tema, ingen tør opdatere. Ingen versionsstyring, så ingen ved, hvad der faktisk er ændret siden sidst. Det er ikke tegn på, at platformen er forkert – det er tegn på, at systemet aldrig har fået den vedligeholdelse, det havde brug for. Jeg har skrevet den fulde liste i Kunsten at arve en WordPress-installation; den gentager jeg ikke her.
Når CMS'et faktisk er blevet problemet
Et reelt platformsproblem ser anderledes ud. Det opstår, når den måde, systemet organiserer indhold og data på, ikke længere passer til det, virksomheden skal kunne. Hvis en ny funktion hver gang kræver endnu en undtagelse, et ekstra lag eller den samme information gemt flere steder, er det værd at spørge, om problemet stadig kan løses inden for den eksisterende platform.
Det tekniske er kun den halve historie. Et system kan fungere upåklageligt teknisk og stadig være forkert, hvis redaktionen har udviklet sig væk fra det. Hvis en redaktør skal kende interne ID'er for at rette en side, kopiere det samme indhold ind tre forskellige steder, eller ringe til en udvikler for at oprette en ny indholdstype, er problemet ikke nødvendigvis performance eller gammel kode. Det er et tegn på, at systemets arbejdsgange ikke længere passer til den organisation, der arbejder i det hver dag. Om det kræver et nyt CMS eller en bedre implementering af det eksisterende, er netop det, der skal undersøges.
Hvad bliver faktisk bedre?
Før man beslutter sig for en migration, bør der være et konkret svar på: når vi er færdige, kan vi ___, som vi ikke kan i dag.
"Vi får en nyere kodebase" er ikke et svar, der bærer et projekt af den størrelse. "Redaktionen kan administrere flere markeder uden udviklerhjælp" er det. "Produktdata får én model i stedet for at leve tre forskellige steder på tre forskellige måder" er det også. Forskellen er, om svaret peger på noget, nogen konkret kan gøre bagefter – ikke om koden ser pænere ud.
Det, man efterlader
"Vi bygger det bare på ny" lyder enklere, end det er. Under overfladen ligger indhold, URL'er, redirects, metadata, strukturerede data, billeder og filer, brugere, integrationer, formularer, tracking, samtykke, historiske data, redaktionelle arbejdsgange, rettigheder og alt det, søgemaskinerne allerede ved om sitet.
Men der er også noget mindre synligt end listen.
Den gamle løsning indeholder otte års beslutninger.
Nogle af dem er dårlige. Nogle af dem løser problemer, ingen længere kan huske eksisterede – en undtagelse for én kunde, en workaround for et system, der ikke findes mere, en regel ingen længere kan forklare, men som stadig løser et reelt problem. Flyt ikke noget, før du ved, hvorfor det er der.
En migration er et projekt i sig selv
En migration er ikke installation af et andet system med det gamle indhold hældt ind. Det gamle system skal typisk fortsætte med at fungere, mens det nye bliver bygget, og ændringer i indhold og data stopper ikke imens.
Derfor skal en migration også have en plan for overgangen: hvad flyttes automatisk, hvad skal bygges om, hvad skal testes, og hvornår det nye system overtager. "Vi flytter bare indholdet over" viser sig ofte at være den mindste del af arbejdet.
Reparere eller skifte?
Ikke fordi systemet er gammelt. Ikke fordi koden er grim. Og heller ikke fordi et andet CMS ser bedre ud i en demo.
Skift, når det eksisterende system står i vejen for det, virksomheden eller redaktionen skal kunne – og når det er dyrere at blive ved med at arbejde rundt om begrænsningerne end at flytte.
Er problemet derimod plugins, manglende opdateringer og kode, ingen længere tør røre, har man måske ikke brug for et nyt CMS.
Man har brug for at få styr på det, man allerede har. Det er også den del af arbejdet med CMS-løsninger, jeg oftest bliver kaldt ind til.
Det, der gør WordPress nemt at udvide, er samtidig årsagen til mange af de problemer, man møder i ældre installationer.
WordPress blev lanceret som blogsystem i 2003 og har siden udviklet sig til et CMS, der bruges til alt fra simple websites til webshops, medlemssystemer og større indholdsløsninger.
WordPress er open source og kan derfor bruges, ændres og udbygges gratis. Der findes samtidig et meget stort økosystem af temaer og plugins, som gør det muligt at tilføje funktionalitet uden nødvendigvis at udvikle alt fra bunden.
Fleksibilitet er den store styrke
En grundinstallation af WordPress er forholdsvis enkel. Funktionaliteten kan derefter udvides efter behov med plugins eller egen kode.
Det kan være alt fra SEO, formularer og flersproget indhold til betalingsløsninger, medlemsstyring, integrationer og komplette webshops med WooCommerce. WordPress kan også integreres med eksterne systemer og API'er eller bruges som headless CMS med en separat frontend.
Den fleksibilitet betyder, at en løsning kan begynde enkelt og senere udvides, hvis behovene ændrer sig.
Bygget til at arbejde med indhold
En af WordPress' styrker er den redaktionelle del. Sider og indlæg kan oprettes og redigeres uden adgang til selve koden, og blokeditoren Gutenberg gør det muligt at opbygge indhold af tekst, billeder og andre blokke.
Med et gennemtænkt tema og et begrænset sæt komponenter kan redaktører arbejde forholdsvis frit med indholdet uden samtidig at kunne ødelægge designet.
WordPress giver et fint udgangspunkt for teknisk SEO, men en god placering i søgeresultaterne kommer naturligvis ikke automatisk af at vælge WordPress. Indhold, performance, struktur og den tekniske implementering er stadig afgørende.
Fleksibiliteten er også svagheden
Den samme fleksibilitet har en pris. Hver udvidelse tilføjer endnu en del, som skal fungere sammen med resten og vedligeholdes over tid.
Et plugin kan løse et konkret problem på få minutter. Efter nogle år kan resultatet være 30, 40 eller 50 plugins fra forskellige leverandører, som hver især bliver opdateret i forskelligt tempo og kan være afhængige af hinanden, temaet eller bestemte versioner af PHP og WordPress.
Det gør ikke nødvendigvis installationen dårlig. Men jo flere bevægelige dele der er, desto mere er der også at forstå og vedligeholde.
Opdateringer og sikkerhed
WordPress, temaer og plugins bliver løbende opdateret med nye funktioner, fejlrettelser og sikkerhedsopdateringer. Det betyder også, at en WordPress-installation ikke er noget, man bør bygge og derefter glemme.
Nogen skal derfor have ansvaret for drift, backup, opdateringer og sikkerhed – enten ejeren selv, en leverandør eller hostingudbyderen.
Problemet opstår ofte, når en installation ikke længere kan opdateres uden risiko for, at noget går i stykker. Så bliver en enkelt udskudt opdatering til flere, og efter nogle år kan man stå med et system, som ingen tør røre.
Specialtilpasninger
WordPress kan tilpasses meget langt, men på et tidspunkt er færdige temaer og plugins ikke nødvendigvis den bedste løsning.
Specialudviklede temaer, egne blokke og integrationer kan give en enklere løsning, fordi funktionaliteten kan bygges til den konkrete opgave frem for at blive tilføjet gennem generelle plugins. Til gengæld kræver det udvikling og dermed en større investering end at installere et færdigt plugin.
Derfor er gratis ikke nødvendigvis billigst på længere sigt – og specialudvikling er heller ikke nødvendigvis den rigtige løsning. Det afhænger af opgaven.
WordPress eller noget andet?
WordPress passer godt til løsninger, hvor indhold skal kunne administreres af redaktører, og hvor der samtidig er behov for fleksibilitet og mulighed for at udvide systemet senere.
Det er ikke nødvendigvis det rigtige valg til alle projekter. En simpel hjemmeside kan måske løses bedre med en hosted website builder, mens meget specialiserede applikationer kan være bedre tjent med et framework eller et andet CMS.
Valget bør derfor begynde med opgaven – ikke med platformen.
Kort sagt
WordPress' største styrke og største svaghed er den samme: fleksibiliteten.
Det kan være et enkelt CMS med få specialbyggede komponenter eller en installation med 50 plugins, tre page builders og kode fra seks forskellige udviklere.
Derfor afhænger kvaliteten af en WordPress-løsning mindre af WordPress i sig selv og mere af, hvordan den er bygget, udvidet og vedligeholdt gennem årene.
Det er også udgangspunktet for mit arbejde med CMS-løsninger: at forstå, hvad der allerede er der, før noget bliver rørt.
WordPress vs. headless — hvad er forskellen i praksis
Headless giver frihed ved at skille tingene ad. Men det, man skiller ad, skal bagefter forbindes igen.
Hvis svaret er "vi vil gerne have Next.js, fordi det er mere moderne", har man ikke identificeret et forretningsproblem. Man har identificeret en teknologipræference.
Headless bliver som regel solgt som det moderne valg – hurtigere, mere fleksibelt, klar til fremtiden. Det er sjældent forkert i sig selv. Det er bare ikke svaret på det, de fleste spørgsmål om headless egentlig handler om.
Det interessante er ikke, om noget kan lade sig gøre. Det er, hvad det koster at få det til at fungere ordentligt.
Hvad betyder headless egentlig?
I almindelig WordPress er redaktion og fremvisning ét system. Redaktøren skriver i wp-admin, temaet ved, hvordan det skal se ud, og WordPress selv genererer siden, browseren får at se.
Headless skiller de to ad. WordPress bliver stedet, hvor indholdet bliver oprettet og administreret, men ikke det system, der bygger den færdige hjemmeside. Indholdet leveres gennem et API til en separat frontend, ofte bygget i noget som Next.js eller Nuxt, som bestemmer, hvordan det vises.
Hvad får man allerede med almindelig WordPress?
Det er let at gøre traditionelt WordPress til den gammeldags modstander, headless skal besejre. Det er en dårlig start på samtalen, for WordPress har én arkitektonisk fordel, der er større end de fleste diskussioner giver den kredit for: det hænger sammen.
Redaktøren skriver indhold. Temaet ved, hvordan det skal vises. WordPress genererer siden. Preview er en del af den samme kæde, fordi temaet både står for den offentlige side og den visning, redaktøren arbejder op imod. Plugins kan koble sig på hele kæden – fra et felt i redigeringen til noget, der rent faktisk vises på siden.
Det er ikke bare nemmere. Det er mindre integration. Der er færre steder, noget kan holde op med at stemme overens med noget andet.
Headless fjerner ikke den forbindelse. Det gør forbindelsen til noget, man selv skal definere og vedligeholde.
Hvornår giver adskillelsen mening?
Tre mønstre går igen, når adskillelsen rent faktisk giver mening.
Samme indhold i flere kanaler. En artikel, et produkt eller en kampagne skal vises på hjemmesiden, i en app og måske på et skærmsystem i en butik – hver med sit eget udseende. WordPress skal levere indholdet til alle tre, uden selv at bestemme, hvordan det ser ud noget af stederne.
Frontend skal udvikles og deployes uafhængigt af CMS'et. Frontend-teamet arbejder i en helt anden stak end PHP og WordPress-temaer, med sin egen release-rytme, og vil ikke være bundet af, hvordan WordPress bygger sider.
CMS'et er én datakilde blandt flere. Frontenden henter ikke kun WordPress-indhold – den sammensætter produktdata, brugerdata, søgeresultater og CMS-tekst fra forskellige systemer. Så er det ikke naturligt, at WordPress samtidig skal eje selve præsentationslaget.
Det er headless som arkitektur, ikke som "WordPress med en moderne frontend."
Hvad med performance?
Performance nævnes ofte som argumentet for headless, og det er værd at være præcis her, fordi påstanden sjældent holder, som den bliver fremført.
Et velkonfigureret WordPress-site er ikke langsomt, fordi det er WordPress. Med full-page cache, reverse proxy og CDN kan en stor del af trafikken håndteres, uden at PHP og databasen overhovedet bliver ramt. Og en tung frontend bygget i React kan sagtens være langsommere for den besøgende end et simpelt, godt cachet WordPress-tema. Arkitekturen er ikke en performance-score i sig selv.
Det reelle argument er et andet: adskillelsen giver andre muligheder for deployment, caching og skalering – ikke fordi headless automatisk er hurtigere, men fordi frontend og backend kan bygges, caches og skaleres hver for sig, uafhængigt af hinanden.
Hvad koster adskillelsen?
Frontenden bliver et selvstændigt softwareprojekt. Ikke nødvendigvis bygget fra bunden – der er frameworks, komponentbiblioteker og designsystemer at bygge på – men det skal bygges, deployes og vedligeholdes som sit eget projekt, med sin egen infrastruktur omkring sig.
WordPress' plugin-økosystem holder heller ikke nødvendigvis. Et almindeligt plugin tilføjer ofte funktionalitet både i backend og på selve siden. I en headless opsætning kan backend-delen fungere fint, mens frontend-delen bliver ubrugelig, fordi der ikke er noget WordPress-tema til den at hægte sig på. Man kan ikke uden videre regne med, at det økosystem, der gør WordPress hurtigt at bygge med, fungerer på samme måde.
Og noget af det, redaktøren tidligere oplevede som ét system, bliver til flere ting, der hver skal fungere for sig og sammen: preview, navigation, formularer, søgning, redirects, SEO-felter. Ingen af delene forsvinder. Men nogen skal nu sørge for, at de fungerer på tværs af grænsen mellem CMS og frontend, i stedet for at det bare var sådan, systemet virkede.
Sikkerhed og vendor lock-in
To andre argumenter dukker ofte op, og begge fortjener samme nøgterne blik som performance.
Sikkerhed er ikke et spørgsmål om WordPress mod headless – det er et spørgsmål om angrebsflade. Langt de fleste WordPress-sårbarheder sidder i plugins og temaer, ikke i selve kernen, som opdateres løbende og hurtigt ved sikkerhedshuller. En headless opsætning fjerner ikke plugin-økosystemet, den ændrer bare, hvor det virker: backend-delen af et plugin er stadig kode, der kan have sårbarheder, uanset om frontenden er et WordPress-tema eller Next.js. Det, headless reelt giver, er en mindre offentlig flade – wp-admin behøver ikke være tilgængeligt fra internettet, når frontenden ikke er afhængig af det ved runtime.
Vendor lock-in handler ikke om, hvorvidt man kan skifte CMS – det kan man med begge arkitekturer. Forskellen er, hvad der følger med i det skifte. I almindelig WordPress er indhold, tema og præsentation vævet sammen, så et CMS-skift som regel betyder, at frontenden også skal bygges om. Med en headless frontend, der allerede henter sit indhold gennem et API, er selve skiftet mindre: content-laget kan udskiftes, uden at frontenden nødvendigvis skal genopbygges fra bunden – forudsat den nye kilde kan levere data i et format, frontenden allerede forstår.
Det behøver ikke være alt eller intet
WordPress kan eksempelvis levere indhold gennem sit API til en app, mens hjemmesiden fortsat kører med et almindeligt WordPress-tema. Det er en hybrid løsning: det meste forbliver, som det var, og kun det, der reelt har brug for adskillelsen, får den.
Det kan være en mere pragmatisk vej end at gøre hele løsningen headless fra begyndelsen. Man får mulighed for at bruge WordPress som indholdskilde dér, hvor det giver mening, uden samtidig at overtage kompleksiteten på hele sitet.
Hvornår ville jeg vælge hvad?
Tre spørgsmål er mere brugbare end ét.
Skal det samme indhold bruges i flere forskellige produkter eller kanaler? Har frontenden behov for at kunne udvikles og deployes uafhængigt af WordPress? Har organisationen udviklingskapaciteten til at eje to adskilte dele bagefter – ikke kun til at bygge dem, men til at drive dem?
Er svaret nej til alle tre, er der sjældent en god grund til at skille tingene ad. Et ja er heller ikke automatisk et argument for headless – men det er et konkret behov, man kan begynde at vurdere arkitekturen ud fra. Hvis svaret i stedet er "vi vil gerne have Next.js, fordi det er mere moderne", har man ikke identificeret et forretningsproblem. Man har identificeret en teknologipræference.
Headless giver frihed ved at skille tingene ad. Men det, man skiller ad, skal bagefter forbindes igen – og det er det arbejde, der er let at overse, når beslutningen bliver truffet. Det er også den del af opgaven, jeg oftest bliver kaldt ind til i arbejdet med CMS-løsninger: at forstå, hvad der reelt binder et system sammen, før man skiller det ad.
Det er en fordel, hvis indhold skal bruges i flere kanaler, frontenden skal leve sit eget liv, eller WordPress kun er én af flere datakilder.
Prisen er mere integration, mere drift og flere dele, der skal fungere sammen.
Headless er ikke automatisk hurtigere eller bedre. Hvis man ikke kan pege på det konkrete problem, adskillelsen løser, er der sjældent nogen grund til at købe kompleksiteten.
Ikke fordi jeg har opgivet Figma. Men fordi det nogle gange er hurtigere at se, om en idé holder, i browseren end på et canvas.
Når idéen er hurtigere at bygge end at tegne
Der er en mere praktisk side af det arbejde, jeg laver. Når jeg har en idé om, hvordan noget skal fungere, kan det nogle gange være lige så hurtigt og intuitivt for mig at skrive HTML, CSS og JavaScript som at arbejde mig frem til det i Figma.
Jeg skriver strukturen, giver den lidt styling, sætter et par interaktioner på og ser, om idéen holder. Ikke som færdig udvikling, men som en prototype, der allerede befinder sig tæt på virkeligheden.
Det er blevet endnu mere oplagt med AI-værktøjer som Claude Code og moderne front-end frameworks. Opsætning, boilerplate og den femte variant af den samme knap går hurtigere, og der bliver mere tid tilbage til det, der faktisk kræver en beslutning.
To slags feedback
Det giver en anden form for feedback.
I Figma kan jeg se, om noget ser rigtigt ud. I browseren kan jeg se, om det fungerer.
Det er ikke det samme. Et statisk design kan ikke vise mig, om et flow rent faktisk hænger sammen, når jeg selv klikker mig igennem det, eller om en animation, der så rigtig ud i hovedet, faktisk føles forkert, når den kører.
Og nogle gange er det først dér, jeg opdager, at den løsning, jeg havde forestillet mig, ikke er så god, som den så ud på skærmen.
Det er noget af det, jeg godt kan lide ved at kunne begge dele. Jeg behøver ikke vente på, at en anden bygger idéen, før jeg finder ud af, om den holder.
Ikke et opgør med Figma
Det betyder ikke, at jeg altid starter i kode. Tværtimod.
Figma er stadig det rigtige værktøj til mange af de tidlige beslutninger. Når flows skal undersøges, informationsarkitektur skal på plads, eller forskellige løsninger skal sammenlignes, er det langt hurtigere at kunne flytte rundt på tingene uden at skulle bygge dem først.
Men jeg har ikke længere en fast idé om, at design skal være færdigt, før udviklingen begynder. For mig kan de to ting godt være en del af den samme proces.
En skitse kan blive til kode. Koden kan ændre skitsen. Og nogle gange er det hurtigste sted at finde ud af, om en idé holder, faktisk ikke i designværktøjet, men i browseren.
Det er også den erfaring, jeg bringer med ind i webdesign og UX og webudvikling: et design, der er tænkt med byggebarhed for øje, og en kode, der respekterer den tanke, designet allerede har formet.
Den dyreste kode er den, man ikke behøver at skrive
Ikke al dyr kode er dårlig kode. Nogle af de dyreste beslutninger, jeg har været med til, var velskrevne løsninger på problemer, ingen havde endnu.
26 år i faget, og især årene med Lifeguard, lærte mig, hvor let det er at forveksle produktudvikling med værdiskabelse. Når man kan bygge noget, er det fristende at bygge det. En ny funktion løser et problem. En integration åbner en mulighed. En mere fleksibel arkitektur gør produktet fremtidssikret. Problemet opstår, når man bygger en løsning på et behov, man endnu ikke har bevist.
Det, der kostede, før vi vidste hvad det var værd
White-label-arkitekturen bag Vitalityguard er det tydeligste eksempel. Den var dyr i den uge, den blev besluttet, og der var ingen garanti for, at nogen nogensinde ville have brug for at skifte identitet ud på platformen. Den viste sig at være grunden til, at vi kunne sælge samme platform videre under et andet navn seks uger efter stiftelsen.
D-mærket er et andet. Vi 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. Det var en tung proces, der strakte sig over et år. På det tidspunkt var det svært at se, hvad investeringen konkret skulle give os. Senere viste den sig at åbne døre, vi ellers ikke havde adgang til.
Ingen af delene var forkerte beslutninger. De var dyre, før de var noget værd, og det er den type investering, man ikke kan vide, betaler sig - man kan kun vide, at ingen af dem gør det, hvis man aldrig tager dem.
Men det er ikke det samme som at bygge foran
Forleden sad jeg med til en undervisningstime på EK - Erhvervsakademi København på Guldbergsgade Campus. En tidligere kollega underviser nu i databasedesign, og jeg var der for at se ham undervise - danne mig et indtryk, ikke for at sige noget. Men han bad mig supplere undervejs. Det, jeg sagde til de studerende, var, at man i opbygningen af en database ikke kun skal løse de behov, kunden har nu, men også de behov, der kommer over tid, og som kunden endnu ikke ved, de har.
Det lyder som det modsatte af pointen ovenfor. Det er det ikke - men det er den anden halvdel af den samme beslutning, og det er let at glemme, når man først har brændt sig på den dyre variant.
Zonesystemet i Lifeguard er eksemplet - userspaces, som vi kaldte det internt. En bruger kunne have en af flere roller - fra almindelig bruger til coach til virksomhedens egen administrator - og var tilknyttet et eller flere teams, som igen hørte under en virksomhed. Det var mere granularitet, end noget enkelt kundeforhold krævede på det tidspunkt. Da Vitalityguard senere skulle give Danica adgang til brugernes data, kunne vi ikke bare udlevere den - hverken juridisk eller i praksis. Løsningen blev et nyt userspace til Danica - ikke en ny konstruktion, men endnu et lag oven på strukturen, der allerede var der. Derfor kunne vi løse det på tre uger: de kunne se det, brugeren selv havde givet adgang til om sig selv, brugeren kunne fjerne tilladelsen igen når som helst, og al databehandling blev liggende i vores eget system. Vi gav aldrig data fra os. Havde adgang og synlighed ikke i forvejen været adskilt i modellen, havde det været en ombygning, ikke en tilføjelse.
Forskellen ligger ikke i, om man bygger foran
Den ligger i, hvad man bygger foran til. Zonesystemet var et strukturelt valg: en datamodel, der adskilte roller, teams og synlighed fra hinanden, uden at vide præcis hvilken kombination der ville blive brug for. Vi forudså ikke Danica. Vi byggede bare noget, der kunne rumme et ukendt behov uden at blive bygget om. Det koster noget at bygge fleksibilitet ind fra starten. Men det kan koste langt mere at opdage bagefter, at strukturen ikke kan rumme behovet.
White-label-arkitekturen var det samme slags valg - struktur, ikke funktion. Det, der er dyrt, er noget andet: at bygge funktioner, integrationer og features på en gisning om, hvad nogen vil bruge dem til. Det er ikke fremsyn. Det er at bygge det, der øger mulighederne, før man har bygget det, der reducerer usikkerheden.
Så pointen er ikke byg mindre. Den er: byg den struktur, der kan rumme det, du endnu ikke ved - og vent med resten, til nogen faktisk beder om det.
Kode bliver til økonomi dér
Som udvikler spørger man, om noget kan bygges. Som teknisk ansvarlig skal man også spørge, hvorfor det skal bygges nu. Det er forskellen mellem kode, der løser et problem, og kode, der bare åbner en mulighed.
Jeg skrev om den økonomiske side af det i Efter en konkurs: en teknisk beslutning er også en økonomisk beslutning. Det er den anden side af samme erfaring.
Det er også det, jeg bruger tiden på i teknisk rådgivning: at spørge hvorfor, før man spørger hvordan.
Fra koder til reviewer – hvordan AI har ændret arbejdsgangen
AI ændrer på kort sigt ikke, hvad jeg kan – det ændrer blot min arbejdsgang.
“AI bliver aldrig dårligere, end det er nu.”
Lars Nielsen, ven og tidligere forretningspartner
Den sætning blev hængende.
Ikke som et forsvar for AI, men fordi den flytter spørgsmålet. Diskussionen om, hvorvidt værktøjet er godt nok, har en udløbsdato. Spørgsmålet om, hvad man selv laver, når det er, har ikke.
Hvad der faktisk ændrede sig
Jeg har kodet professionelt siden 1998. I det meste af den tid har arbejdet været at skrive koden – sidde med problemet, finde vejen igennem og skrive linjerne selv. Det er stadig en stor del af mit arbejde. Men ikke på samme måde som før.
Jeg skriver stadig kode, men en større del af dagen går med at formulere opgaven præcist, vurdere det, der kommer tilbage, og afvise det, der ikke holder. Det ligner efterhånden mindre én udvikler foran en editor og mere en udvikler, der samtidig leder et meget hurtigt, meget bogstaveligt og temmelig upålideligt lille hold.
Det minder mig om, da jeg sad i Lifeguard og briefede mine udviklere – skrev opgaverne ind i Trello, forklarede hvad der skulle laves, og gennemgik det, der kom tilbage. Arbejdsdagen føles i dag tættere på den rolle end på den, jeg havde ti år før.
Hvorfor det kræver mere erfaring, ikke mindre
Den udbredte antagelse er, at værktøjet gør erfaring mindre værd. Min oplevelse er den modsatte. En model kan skrive noget, der ser overbevisende rigtigt ud, også når det ikke er det – og forskellen er ikke nødvendigvis synlig ved første gennemlæsning.
At se forskellen kræver, at man ved, hvad man leder efter:
Den forespørgsel, der virker på ti rækker og falder over på hundredtusind.
Den fejlhåndtering, der ser komplet ud, men aldrig rammer den sti, det handler om.
Det bibliotek, der løser problemet og trækker tredive gange så meget med sig som nødvendigt.
Det kommer ikke af at kunne prompte. Det kommer af at have set systemer virke, fejle og blive vedligeholdt længe nok til at genkende problemerne, før de bliver dyre.
Den vurdering er ikke blevet mindre vigtig. Den fylder mere af arbejdet end nogensinde før.
Hvad jeg holder fast i
Jeg lader ikke noget gå videre, jeg ikke har læst. Ikke af princip, men fordi jeg står på mål for det. Når en kunde ringer om halvandet år, fordi noget er gået i stykker, er det ikke et værktøj, der skal forklare, hvorfor det er bygget sådan.
Og der er stadig opgaver, hvor jeg åbner editoren og skriver det selv, fordi det går hurtigere end at beskrive det. Det er ikke nostalgi. Det er den rigtige beslutning, oftere end debatten lader ane.
Er der udviklere i fremtiden?
Jeg har spurgt mig selv om det tit. Jeg tror, der er.
Men jeg tror, der kommer til at blive udviklet langt mere. Ting, der før var for dyre at bygge, kan nu laves på en brøkdel af tiden. Og når prisen falder, holder man ikke nødvendigvis op med at købe. Man begynder også at købe det, man tidligere måtte undvære.
Der vil stadig være efterspørgsel efter løsninger, der ikke er generiske, og efter design, nogen faktisk har tænkt over. Det bliver ikke mindre værd, fordi det trivielle bliver billigere.
Det, der bekymrer mig mere, er vejen ind. Venstrehåndsopgaverne – dem man lærte håndværket på – bliver overtaget. Det var dér, man byggede den erfaring op, som senere gør det muligt at se, hvornår et forslag ikke holder.
Jeg ved ikke, hvor den erfaring skal komme fra nu. Det har jeg ikke noget godt svar på.
Jeg ved heller ikke, hvor meget af den kode, jeg arbejder med om fem år, jeg selv kommer til at skrive fra første tegn.
Men det er heller ikke længere det interessante spørgsmål.
Jeg skal stadig forstå problemet. Jeg skal stadig kunne se, når løsningen er forkert. Og når kunden ringer halvandet år senere, er ansvaret stadig mit.
Jeg er stadig udvikleren. Jeg bruger bare mere af dagen som reviewer for en kollega, der skriver ekstremt hurtigt, aldrig bliver træt og indimellem tager fuldstændig fejl.
Det er også den erfaring, der går ind i webudvikling: at kunne se, om noget virker, uanset hvem eller hvad der skrev det først.
Lars Nielsen, som satte tanken i gang, udkommer selv løbende om AI på LinkedIn og på YouTube.
8 år, 34 plugins og et tema, ingen tør røre. Opgaven begynder ikke med at rette noget – den begynder med at finde ud af, hvad der bliver brugt.
Opgaven lyder sjældent som et projekt. Den lyder som: “vores site er blevet langsomt”, eller “vi kan ikke opdatere, uden at noget går i stykker”. Bagved ligger en WordPress-installation, der har kørt i otte år, og som ingen har haft det fulde overblik over siden den udvikler, der byggede den, holdt op.
Det er en af de mere almindelige opgaver i WordPress-verdenen. Den bliver bare sjældent beskrevet, fordi den ikke er et nyt site med et før-og-efter-billede.
Det første skridt er ikke at rette noget
Fristelsen er at gå i gang: deaktivere plugins, opdatere kernen, rydde op i temaet. Det er også den hurtigste vej til at slukke for noget, der viste sig at være vigtigt.
Første skridt er at finde ud af, hvad der faktisk bliver brugt. Hvilke plugins gør noget, siden faktisk viser. Hvilke sidetyper findes der, og hvem redigerer dem. Hvad sker der ved en bestilling, en tilmelding, en formular – hele vejen fra klik til mail eller database. Det tager typisk en dag eller to, og det er den bedst brugte tid i hele opgaven.
Reglen, jeg arbejder efter, er enkel: rør ikke noget, før du ved, hvorfor det er der. Kode, der ser overflødig ud, er ofte nogens løsning på et problem, der ikke er dokumenteret nogen steder.
Hvad man typisk finder
Der er nogle mønstre, der går igen.
Plugins, der overlapper. To cache-plugins installeret af hver sin udvikler. En galleriløsning, der bruges på én side, som ingen har besøgt i to år.
Plugins, der udsender konkurrerende metadata. Den værste variant af overlappet, fordi den ikke gør noget synligt. To SEO-plugins skriver hver sin title, sin canonical og sine Open Graph-tags i samme sidehoved, og temaet lægger måske et tredje sæt oven i. Siden ser rigtig ud i browseren – men Google får modstridende signaler om, hvad siden hedder, og hvilken URL der er den rigtige. Det er ikke et plugin, der er i stykker. Det er to, der begge virker.
Ændringer i temaet frem for i et child theme. Det betyder, at temaet ikke kan opdateres, uden at ændringerne forsvinder – og derfor er det ikke blevet opdateret. Derfra breder det sig: når temaet står stille, tør man heller ikke opdatere WordPress eller PHP, og til sidst er hele installationen låst fast af noget, ingen kan huske.
Sporing, der kører uden om samtykket. Google Tag Manager installeret gennem et plugin, mens samtykket håndteres af et andet. Hver for sig virker de: banneret vises og gemmer valget, og GTM indlæser sine tags. De ved bare ikke nødvendigvis af hinanden, så brugerens valg i banneret bliver ikke omsat til den adfærd, man tror. Det er den slags, der ikke opdages ved almindelig brug af sitet, men først når man ser på, hvad browseren faktisk sender.
Kode, ingen tør røre. En functions.php på 1.000 linjer, hvor det meste er tilføjet af forskellige mennesker over flere år. Ingen kommentarer, ingen historik, fordi det aldrig har ligget i Git.
Hvad jeg gør ved det
Rækkefølgen betyder mere end værktøjerne.
En kopi og versionsstyring. Installationen skal ligge et sted, hvor man kan prøve noget af uden at ramme det, kunden bruger. Og koden skal i Git – ikke for at være moderne, men fordi det er forskellen på “vi ændrede noget, og nu virker det ikke” og “vi kan se præcis, hvad der skete”.
Det, der gør ondt nu. Er sitet langsomt, måler jeg hvorfor, før jeg optimerer. Er der en sikkerhedsopdatering, der er blevet udskudt i to år, er den vigtigere end oprydning. Kunden skal mærke en forskel, før man går i gang med det, der ikke kan ses.
Én ting ad gangen. Ét plugin fjernet, sitet testet, videre. Det tager længere tid end at rydde op i én omgang, men når noget går i stykker, ved man, hvad det var.
Det, der gør næste gang lettere. Et child theme, så temaet kan opdateres. Ændringer flyttet fra functions.php til et sted, de kan læses. En kort note om, hvad der er hvor.
Hvornår det ikke kan betale sig
Nogle gange er svaret at bygge nyt. Det er det, når temaet er så gennemhullet, at oprydningen bliver dyrere end en ny frontend, eller når indholdsstrukturen ikke passer til det, sitet skal kunne i dag. Er det frontenden, der er problemet, er det ikke automatisk et argument for at forlade WordPress som CMS – se WordPress vs. headless.
Men det er sjældnere, end man tror – og det er værd at være opmærksom på, at den, der skal bygge det nye, sjældent er den mest objektive til at vurdere det. Et site med otte års indhold, indeksering og indgående links har en værdi, der ikke står i kodebasen.
Det, det egentlig handler om
En arvet installation er sjældent kun et teknisk problem. Det er også et spørgsmål om, at nogen skal kunne svare på, hvad der sker, og hvorfor.
Det er dét, arbejdet går ud på: at gøre et system, ingen forstår, til et system, nogen kan drive. Koden bliver bedre undervejs, men det er ikke pointen. Pointen er, at næste gang der skal ændres noget, er det en opgave og ikke en risiko.
Det er den samme tilgang, jeg bruger i WordPress og CMS: at forstå, hvad der allerede er der, før noget bliver rørt.
Det jeg oftest møder
En arvet installation har sjældent dem alle, og de færreste er alvorlige hver for sig. Det er kombinationen, der gør en opgave svær at estimere.
01_Plugin-gæld30-60 plugins, hvor flere løser næsten samme problem, nogle er forladte, og ingen ved længere, hvilke der er nødvendige.
02_Plugin-konflikterTo plugins hooker ind samme sted, loader hver sin version af et bibliotek eller ændrer den samme funktionalitet.
03_OpdateringsangstWordPress, PHP, tema eller plugins kan ikke opdateres, fordi ingen ved, hvad der knækker.
04_Købte temaer og page buildersElementor, Divi, WPBakery og lignende kan efter nogle år efterlade en løsning, der er svær at ændre uden at arbejde imod systemet.
05_PerformancePlugins og temaer loader CSS og JavaScript på alle sider, også hvor det ikke bruges. Dertil tunge billeder, dyre queries og manglende caching.
06_Database-oprydningwp_options, autoloadede options, revisions, transients og tabeller fra plugins, der for længst er slettet.
07_WP-CronPraktisk indtil jobs bliver tunge, fejler stille eller skal køre pålideligt på et bestemt tidspunkt.
08_SikkerhedGamle plugins og temaer, for brede rettigheder, XML-RPC, filuploads, ubeskyttede endpoints og administratorer nok til at stille et fodboldhold.
09_Egen kode de forkerte stederÆndringer direkte i parent theme eller i et plugin, snippets i functions.php - og den klassiske lille rettelse i core.
10_Manglende versionsstyringÆndringer lagt direkte på produktion via wp-admin eller FTP, og ingen sikker måde at se, hvad der er ændret siden sidst.
11_Staging og produktionDatabaseindhold skal den ene vej, kode den anden, mens uploads og redaktionelle ændringer helst ikke må overskrives.
12_URLs i databasenSerialiserede data og absolutte URLs gør en almindelig search/replace mere spændende, end den burde være.
13_Mailwp_mail() kan godt returnere succes, uden at mailen ender i modtagerens indbakke. Pludselig bliver SMTP eller en mailtjeneste, SPF, DKIM og DMARC en del af WordPress-opgaven.
14_REST API og integrationerAutentificering, rate limits, webhooks, retries og eksterne systemer, der ikke opfører sig, som dokumentationen lovede.
15_WooCommerceEn kategori for sig: checkout, hooks, ordrestatusser, betalingsgateways, moms, fragt, mails og plugins oven på plugins.
16_FlersprogethedWPML eller Polylang, hreflang, oversatte slugs, canonicals og indhold, der ikke findes på alle sprog.
17_Teknisk SEORedirects, canonicals, sitemap, robots, strukturerede data - og flere SEO-plugins, der alle vil bestemme indholdet af <head>.
18_Tracking og samtykkeTag Manager, GA4, Google Ads, Consent Mode og cookie consent. Typisk her man opdager, at tre plugins og temaet alle indsætter tracking.
19_Gutenberg og blokkeFint, når det er tænkt igennem. Mindre fint, når redaktøren får 80 blokke og mulighed for at bryde designsystemet.
20_Roller og rettighederEditor skal kunne rette dette, men ikke dét - hurtigt mere kompliceret end standardrollerne i WordPress rækker til.
21_Mediebiblioteket12.000 billeder, 14 genererede størrelser af hvert og 40 GB thumbnails, hvor ingen ved, hvilke temaet bruger.
Listen er ikke en anklage mod WordPress. Det er, hvad der sker med systemer, mange mennesker har rørt ved gennem otte år.
Et sprog er til at lære. Det er domænet og kodebasen, der tager tid – og to maskiner, der kostede mere opmærksomhed end syntaksen.
Efter godt tyve år, hvor PHP har været det sprog, jeg tænkte i, skiftede jeg delvist over til C#. Delvist, fordi det afhang af projektet: Egon og ebillet kørte på Umbraco og krævede .NET, mens resten af kunderne lå på min sædvanlige stak.
Syntaks er til at læse sig til. Typer, klasser, arv, interfaces – det er de samme begreber, jeg har brugt hele tiden, med andre nøgleord foran. En uges tid inde kunne jeg løse reelle opgaver i C#.
Det, der faktisk tog tid
Domænet. Hvad forretningen egentlig gør, hvorfor tallene beregnes præcis sådan, hvilke regler der ikke står nogen steder, fordi alle på kontoret kender dem.
Og kodebasen. Ikke sproget, men dette systems udgave af det: hvorfor der er to lag, der ser ud til at gøre det samme, hvilket af dem der er det nye, og hvad det gamle stadig bruges til. Den slags læres ved at læse og spørge, ikke ved at slå op.
Platformen var Umbraco, ikke bare C#
Strukturen var genkendelig. Helpers, middleware, models, views og services havde alle paralleller til den verden, jeg kendte fra Laravel. Jeg skulle lære en ny implementation, ikke en helt ny måde at tænke webapplikationer på.
Og for at være ærlig lå mine opgaver heldigvis primært i view-laget og i assets – dér, hvor forskellen mellem de to verdener er mindst. Jeg skiftede ikke til .NET i fuld bredde; jeg arbejdede i den ende af det, hvor min erfaring bar mest med over.
Det, jeg skulle vænne mig til, var at skulle starte projektet for at se det. Bag den lille grønne play-knap i Visual Studio ligger fire ting:
Starter IIS Express.
Publicerer projektet til den.
Tilkobler debuggeren.
Åbner browseren.
I PHP gemmer man filen og trykker opdater – webserveren kører i forvejen, og der er ikke noget at publicere.
Det ændrer rytmen i en arbejdsdag. Man holder op med at rette én ting og kigge, og samler i stedet flere ændringer, fordi hver runde koster en opstart. Til gengæld har man en debugger hæftet på fra første sekund, og det er ikke ingenting.
To maskiner
.NET-arbejdet foregik på PC i Visual Studio Professional – ikke VS Code, som jeg bruger til alt andet, men den fulde IDE. Når der skulle laves designelementer, eller når dagen bød på en af de kunder, der lå på PHP, sprang jeg tilbage til min Mac. Værktøjerne og arbejdsgangen sidder der, og det går hurtigere end at bygge det samme op forfra på den anden maskine.
Rent praktisk var det løst. Mus og tastatur kunne skifte mellem maskinerne med ét tryk, og begge maskiner brugte den samme skærm. Hardwaren var ikke problemet. Det, der ikke fulgte med, var hænderne.
Filerne fulgte heller ikke af sig selv. De grafiske filer flyttede jeg mellem maskinerne gennem OneDrive, som allerede var koblet på projektet – lavpraktisk frem for elegant, men det virkede, og ingen havde bedt om en bedre løsning.
Genvejstasterne ligger forskelligt. Kopiér, indsæt, skift vindue, hop til linjestart – de sidder i fingrene efter tyve år, og efter et tryk på den knap sidder de forkert. Værst er < og >: på et dansk layout ligger de ét sted på Mac og et andet på PC. Når man skriver markup eller generics, rammer man dem konstant, og fingrene rammer det forkerte sted lige så konstant. Man skriver ikke om; man rammer bare den forkerte tast og opdager det et sekund senere. Hver gang koster ingenting. Hundrede gange om dagen gør.
Flere gange om dagen, i månedsvis. Det er den slags, der ikke står i nogen opgørelse over, hvad et sprogskifte koster.
Det, jeg tog med mig
Efter tyve år med PHP var det interessant at opdage, hvor lidt af erfaringen der faktisk var bundet til PHP.
At læse fremmed kode, finde mønstre i et system, stille de rigtige spørgsmål til et krav og vide, hvornår noget sandsynligvis bliver et problem senere – det fulgte med. Det er den del af webudvikling, der ikke handler om sproget, men om at forstå det, der allerede er bygget.
C# skulle læres. Selvfølgelig. Men det viste sig at være den mindst interessante del af skiftet.
Det svære var at lære endnu en kodebase, endnu et domæne og endnu en platform at kende.
35 millioner på det højeste, konkurs i december 2023, nyt selskab syv måneder senere. Det her er, hvad der lå imellem – og hvad jeg tog med.
I december 2023 blev Lifeguard Health erklæret konkurs. Vi havde kørt i syv år, haft 40+ mennesker ansat undervejs, Mærsk som kunde, et joint venture med Dansk Sundhedssikring og investorer i ryggen. På det højeste var selskabet værdisat til 35 millioner. Så kom corona, og vi fandt aldrig tilbage.
De sidste måneder gik med at holde det i live, mens vi ventede på den kunde, der skulle redde det. Kunden trak sig i 11. time. Der var ikke nogen plan B, og det er der sjældent på det tidspunkt - man har brugt alt, hvad man havde, på at nå dertil.
Det lyder i en CV-linje som en glidende overgang. Det var det ikke.
Det tager længere tid, end regnskabet siger
En konkurs har en dato. Kurator sender et brev, selskabet ophører, og der står et årstal i CVR-registret. Alt det er overstået på nogle uger.
Det, der tager tid, er noget andet. En virksomhed, man har bygget i syv år, ligger i hovedet som en samling uafsluttede tanker: hvad der skulle have været gjort anderledes, hvornår man burde have set det, hvem man skylder en forklaring. Ingen af delene lukker, fordi kurator er færdig.
Jeg troede, jeg skulle bruge tiden på at finde ud af, hvad jeg ville nu. Det var forkert. Tiden gik med at finde ud af, hvad der egentlig var sket.
Hvad der egentlig gik galt
Da jeg gennemgik det, delte det sig i det, markedet gjorde ved os, og det, vi gjorde ved os selv. Grænsen mellem de to er mindre skarp, end jeg gerne ville have, at den var.
Den ene så længe ud som ren timing. Vi byggede en B2B-sundhedsplatform til HR-afdelinger og gik ind i en investorverden, hvor et selskab helst skal være afsat på tre til fem år.
Tidslinjen er værd at holde op mod den forventning. 2015 og 2016 gik med at bygge. Fra 2016 kørte vi VitalityGuard i joint venture med Dansk Sundhedssikring i to år, hvor vi voksede på deres salgsapparat. I 2018 blev samarbejdet opløst over uenighed om salgsstrategien, og vi brugte det næste stykke tid på at finde vores egen retning igen - og på selv at skulle sælge, for første gang siden opbygningsfasen.
Der er noget her, jeg først har set bagefter. Vi gik ind i en verden, der regner i exits, uden selv at have bygget mod en. Der lå ingen plan for, hvem selskabet skulle sælges til, eller hvordan det skulle se ud den dag. Vi byggede et produkt, vi troede på, og regnede med, at resten fulgte efter.
Noget af det, jeg siden har lagt mærke til hos erhvervsfolk, der lykkes, er, at de sjældent kun har ét sted, deres økonomi skal komme fra. Vi havde ét skud. Og det var ikke bygget til at blive solgt.
Det var dér, vi var, da alle gik hjem i marts 2020. Og da de et år senere skulle tilbage på kontoret, lå HR ned i praktik: flytte arbejdsstationer tilbage, finde ud af hvem der mødte ind hvilke dage, holde sammen på en organisation, der havde vænnet sig til noget andet. Forebyggende trivsel var ikke det, der stod øverst.
I 2021 forsøgte vi noget andet: et samarbejde med BT, som vi kaldte Reload, i et forsøg på at tage konceptet fra B2B til B2C. Det var et forsøg på at finde en vej uden om det marked, der lige var lukket - og det bar heller ikke.
Resten er sværere at se på, fordi den var vores egen. Vi kunne dokumentere værdien. Bedre trivsel, færre sygedage, mindre stress, højere fastholdelse - tal, vi kunne lægge på bordet. Og virksomhederne ville stadig ikke betale for den.
Grunden var prisen, og prisen var vores egen beslutning. Vi udviklede løbende og havde store ambitioner, og oven i lå den personlige coach - det, der gjorde produktet virksomt, og det, der gjorde det dyrt. HR kunne godt se værdien. HR havde bare ikke den slags penge - det havde finance. Og finance forstod faktisk tallene bedre: produktivitet og to sygedage færre pr. medarbejder er et regnestykke, de kan lave. De skulle bare ikke bruge et trivselsprodukt for at komme frem til det.
Der er et spørgsmål, jeg stadig ikke har svaret på: var produktet for komplekst? Vi arbejdede hele tiden på at løse alle virksomhedens og brugernes udfordringer, og hver enkelt beslutning gav mening, da den blev truffet. Men vi endte som en schweizerkniv. Noget, der kan det hele, og som derfor er svært at forklare enkelt.
Jeg ved ikke, om et mindre produkt havde solgt bedre. Jeg ved, at det havde været billigere at bygge, billigere at drive og nemmere at forklare til en, der ikke sad i HR.
Det er den fejl, jeg tænker mest over. Ikke at vi byggede noget, der ikke virkede, men at vi byggede noget stort til en, der ikke kunne købe det. Vi byggede til HR og talte HR's sprog, mens beslutningen lå hos nogen, der målte i noget helt andet.
På nogle punkter føltes det som et trafikuheld i slowmotion. Man kan se, hvad der rammer hvad, og man har rigeligt med tid til at tænke over det. Man kan bare ikke nå at flytte sig.
Hvad jeg tog med
Det første er banalt og alligevel svært: byg det, der beviser antagelsen, før det, der bygger på den. Vi havde teknikken i orden længe før vi vidste, om nogen ville købe. Det føles produktivt at bygge. Det er også den nemmeste måde at udskyde det spørgsmål, der afgør det hele.
Det andet handler om, hvad man siger ja til. Hos Lifeguard var jeg CTO, medstifter og i lange perioder den, der skrev det meste af koden. Det gav mening, mens vi var få. Det gav mindre mening, da vi var 25 på lønningslisten samtidig, og det er svært at give slip på noget, man selv har bygget – også når det er den eneste rigtige beslutning.
Det tredje er det, jeg tog mest med: en teknisk beslutning er også en økonomisk. White label-arkitekturen, vi byggede til VitalityGuard, var dyr i den uge, den blev besluttet, og den var grunden til, at platformen kunne sælges videre under et andet navn seks uger efter stiftelsen. GDPR-arbejdet med Bech-Bruun var dyrt og virkede overdrevet, indtil Mærsk kom ind med krav, vi ellers ikke kunne have svaret på.
Man kan ikke vide på forhånd, hvilke af den slags investeringer der betaler sig. Men man kan heller ikke bygge noget, der kan bære, uden at tage nogle af dem.
Hvorfor jeg gjorde det igen
Da tre personer kontaktede mig i forsommeren 2024 om ESGRapporter, var mit første svar ikke ja.
Det, der gjorde forskellen, var ikke idéen. Det var, at jeg blev anbefalet af en tidligere investor fra Lifeguard - en, der havde set det gå galt og alligevel pegede på mig.
Jeg vidste også, hvad jeg gik ind til denne gang. Ikke hvordan det ville ende, men jeg havde prøvet den anden ende før. Jeg vidste, hvad det koster at bygge for meget, hvad det koster ikke at vælge fra - og hvor meget der skal være på plads, før man skriver den første linje kode.
Det man ikke lærer af en succes
Der findes en masse skrevet om at starte virksomhed. Der findes forsvindende lidt om at lukke en – i hvert fald fra den, der stod i den.
Det er ikke, fordi det er sjældent. De fleste selskaber lukker. Det er, fordi der ikke er noget at sælge i historien, og fordi den, der har prøvet det, sjældent har lyst til at være eksemplet.
Sejren har mange fædre, nederlaget er faderløst. Det er derfor, den ene slags historie bliver fortalt igen og igen, og den anden ikke bliver fortalt af nogen.
Men jeg tror, det er den mest brugbare erfaring, jeg har. Ikke fordi den gør mig bedre til at undgå det – det gør den ikke – men fordi jeg nu ved, hvad de beslutninger, jeg rådgiver om, koster, når de går galt. Det er en anden slags viden end den, man får af at læse om det.
Når noget lykkes, ved man ikke hvorfor. Man har gjort hundrede ting, og de virkede. Når det ikke lykkes, får man den regning specificeret.
Lifeguard kørte i syv år. Det er ikke en fiasko, der varer syv år. Det er syv år, der endte i en konkurs, og de to ting er ikke det samme.
Den her tekst bliver nok aldrig færdig. Nye erkendelser dukker op med tiden, og hver gang flytter de en smule på, hvad jeg tror, der skete. Sådan er det nok med den slags.
Da vi byggede ESGRapporter, havde konkurrenterne tungere beregningsmotorer end os. Vi satsede et andet sted: på at det, brugeren sad tilbage med, var værd at vise frem.
Kravene kom med CSRD-direktivet og ESRS-standarden, der følger med. De ramte de store børsnoterede selskaber først, men effekten forplantede sig nedad: en stor virksomhed skal rapportere på hele sin værdikæde, og pludselig lå der et spørgeskema i indbakken hos dens underleverandører.
En produktionsvirksomhed med 30 ansatte havde hverken en bæredygtighedsafdeling eller budget til et konsulenthus. Men den havde en kunde, der forlangte tallene.
Det var den virksomhed, vi byggede ESGRapporter til. Jeg var medstifter og CTO, og platformen skulle gøre en ESG-rapport mulig for nogen, der hverken kendte standarden eller havde nogen til at oversætte den.
Markedet var der allerede. Så spørgsmålet var ikke, om vi kunne bygge en beregningsmotor til. Det var, hvad vi skulle bygge i stedet – og svaret blev to ting, der hang sammen.
Det er ikke tallene, der er svære
Det, brugerne gik i stå på, var sjældent en beregning. Det var de beskrivende afsnit.
En ESG-rapport består ikke kun af forbrugstal. Der skal stå noget om virksomhedens politik på området, om hvordan risici håndteres, om hvad der er gjort i år og hvad der planlægges. Den slags kan ikke regnes ud. Den skal skrives.
Og der sidder en driftsleder med et tomt felt og en overskrift, der lyder som noget fra en paragraf. De ved godt, hvad virksomheden gør. De ved bare ikke, hvad man skriver.
At fortælle, hvad der skulle stå
Det var den ene halvdel af arbejdet. Ikke at forklare standarden, men at fortælle, hvad der skulle stå i feltet.
Hvert felt fik sin egen indgang: hvad handler dette afsnit om, hvad plejer der at stå, hvad ville en læser gerne vide. Ikke en definition af kravet, men et konkret bud på, hvad man kunne svare. Vi brugte AI til at hjælpe med at formulere det færdigt ud fra brugerens egne stikord – ikke til at finde på indholdet, men til at gøre tre linjer til et afsnit, der kan læses.
Forskellen er, hvem der står inde for det. En ESG-rapport er et dokument, virksomheden hæfter for. Genereres den af en model, der gætter kvalificeret, falder den fra hinanden i det øjeblik nogen spørger, hvor det kommer fra.
Rapporten er et produkt, ikke en indberetning
Den anden halvdel af satsningen lå i selve dokumentet – det, der lå på skærmen, når arbejdet var færdigt.
De fleste værktøjer i markedet leverede data. Et regneark, en compliance-fil, noget der kunne sendes videre og lægges i et arkiv. Teknisk korrekt, og fuldstændig uden værdi den dag, virksomheden gerne vil bruge arbejdet til noget.
For når en virksomhed har brugt en uge på det her, vil den ikke bare have det overstået. Den vil vise det frem. Til kunden, der spurgte. På hjemmesiden. Til den samarbejdspartner, der bringer bæredygtighed op, fordi det er blevet en del af samtalen.
Så vores rapport skulle kunne sendes til tryk. 17 A4-sider med forside, typografi og gennemført layout – ikke en PDF-udskrift af en formular, men noget der lignede en årsrapport. Noget man kunne lægge i receptionen.
Når design og kode er samme problem
Det var også grunden til, at opgaven passede mig. Jeg har lavet grafisk design lige så længe, som jeg har kodet, og her lå de to ting i det samme produkt.
Et rapportlayout, der skal holde til indhold, ingen kender på forhånd, er ikke et designproblem eller et kodeproblem. Det er begge dele på én gang: en tabel skal kunne bryde over to sider uden at miste sin overskrift, et afsnit på fyrre ord og et på fire hundrede skal begge se ud som om, de var tænkt sådan.
Havde en designer tegnet det, og en anden bygget det, var vi endt i den runde, hvor tegningen og virkeligheden forhandler. Her var der ingen runde. Det er den samme tankegang, jeg tager med ind i webdesign og UX: et design skal kunne holde til virkeligheden, ikke kun til det første udkast.
Det svære er at sige nej
Hver gang en bruger stod fast, var der en fristelse til at tilføje: et felt mere, en note, en undtagelse, en indstilling. Hver af dem er rimelig i sig selv.
Samlet er de grunden til, at det oprindelige problem findes. Enterprise-værktøjerne til ESG er ikke komplekse, fordi nogen ville have dem komplekse. De er komplekse, fordi hver enkelt tilføjelse gav mening, da den blev lavet.
At holde noget enkelt er ikke en fase i starten af projektet. Det er en beslutning, man skal træffe igen hver gang.
Fra database og backend til frontend, integrationer og drift.
Jeg udvikler og vedligeholder webbaserede løsninger fra ende til anden. Det betyder, at jeg kan tage ansvar for hele den tekniske kæde – også for de dele, der ligger mellem systemerne, og for det, der skal fungere, efter løsningen er sat i drift. Jeg arbejder primært med PHP, Laravel, MySQL og JavaScript. Jeg bruger frameworks og andre værktøjer, når de giver mening for løsningen – ikke bare fordi de findes. Skal designet også tænkes med, dækker webdesign og UX den del.
Hvad det typisk dækker
Integrationer til tredjeparts-API'er, betalingsflows, brugeradministration, rettighedsstyring og de administrationsværktøjer, som redaktører og support bruger i det daglige. Det er ofte den del af løsningen, der ikke er synlig for brugeren, men som er afgørende for, at systemet fungerer og kan drives effektivt – planlagte jobs, mailflows, logging, import og eksport af data, webhooks og selve driften og deploymentet bagved.
Hvordan jeg arbejder
Jeg overtager lige så ofte eksisterende løsninger, som jeg bygger nye. Første skridt er at forstå, hvad der allerede er bygget – og hvorfor. Også når dokumentationen mangler. Derefter løser jeg det, der gør ondt nu, samtidig med at jeg holder øje med, hvad der bør forbedres på længere sigt. Målet er ikke nødvendigvis at bygge alting om, men at få løsningen til at fungere bedre, være lettere at vedligeholde og skabe et solidt fundament for det næste.
Forløb og afregning
Udgangspunktet er timebasis, fordi udviklingsopgaver sjældent har et fast omfang, før man er i gang. En integration kan vise sig enkel eller afdække ti undtagelser, ingen kunne se på forhånd. Når en opgave er afgrænset nok til at kunne estimeres med rimelig sikkerhed – en konkret funktion eller en veldefineret integration – kan den også løses til fast pris.
Leveringen markerer ikke nødvendigvis afslutningen på samarbejdet. Rettelser, tilpasninger og videreudvikling foregår løbende på samme måde som resten af samarbejdet. De fleste kunder er tilbagevendende, og koden lever videre længe efter den første levering.
Design af brugerflader, der skal fungere for både brugeren og forretningen.
Udgangspunktet er, hvad brugeren skal kunne, og hvad forretningen skal have ud af det. Jeg arbejder i Figma fra de første wireframes og prototyper til det færdige design og designsystem. Skal det også bygges og driftes, dækker webudvikling den del.
Hvad det typisk dækker
Informationsarkitektur, wireframes, interaktive prototyper og komponentbiblioteker, som udviklingen kan tage direkte udgangspunkt i. Når projektet giver mulighed for det, tester jeg på rigtige brugere. Det er som regel billigere at opdage problemet dér end efter lancering.
Fordelen ved at jeg også koder
Designet bliver lettere at bygge. Jeg har en god fornemmelse for, hvilke designvalg der typisk koster udviklingstid, og hvilke der ikke gør, og jeg leverer specifikationer, som en udvikler kan bruge uden at gætte. Det fjerner den runde, hvor design og udvikling forhandler om, hvad tegningen egentlig betød.
Forløb og afregning
Design starter på timebasis, indtil omfanget er klart – hvor mange skærmbilleder, hvor mange iterationer, og om der skal testes på brugere undervejs. Er opgaven afgrænset, fx en komponentbiblioteksopdatering eller et bestemt flow, kan den løses til fast pris.
Leveringen markerer ikke nødvendigvis afslutningen på samarbejdet. Justeringer af det leverede design og videre iterationer, når produktet udvikler sig, afregnes løbende – på samme måde som resten af samarbejdet.
Visuel identitet til virksomheder, der skal se ud som noget, man kan regne med.
Logo, farver, typografi og de retningslinjer, der holder det hele sammen – også når andre end mig skal arbejde videre med det.
Hvad det typisk dækker
Visuelle identiteter, designmanualer, tryksager, emballage, skiltning og præsentationsmateriale. Jeg arbejder i Photoshop til billedbehandling, Illustrator til logoer og vektorgrafik og InDesign, når materialet skal sættes op til tryk – med de specifikationer og opsætninger, trykkeriet faktisk kan bruge.
Hvorfor det hænger sammen med resten
En identitet, der kun findes som en PDF, falder fra hinanden i det øjeblik, den skal bruges på et website. Derfor bygger jeg identiteten som et system, der kan føres hele vejen fra visitkort og præsentationer til digitale komponenter og CSS. Identiteten skal kunne genkendes og holde sammen, uanset hvor man møder den.
Forløb og afregning
En visuel identitet er ofte den type opgave, der lader sig afgrænse på forhånd – logo, farvepalet, typografi, en designmanual – og kan derfor løses til fast pris, når omfanget er aftalt. Løbende arbejde, fx tryksager eller nyt materiale hen ad vejen, afregnes på timebasis.
Justeringer og udvidelser af identiteten – nye formater, nye anvendelser – håndteres løbende, som resten af samarbejdet.
CMS Løsninger bygget til dem, der skal arbejde i dem hver dag.
Jeg arbejder primært med WordPress, men også med Umbraco og Magento – og med headless-løsninger, hvor redaktion og frontend er adskilt. Udgangspunktet er, at redaktøren skal kunne passe indholdet uden at kende systemet bagved, og uden at være afhængig af en udvikler for hver lille ændring.
Hvad det typisk dækker
Temaer bygget fra bunden frem for købte standardtemaer, egne felter, blokke og komponenter, integrationer og migrering fra ældre systemer – samt oprydning i installationer, hvor plugins har fået lov at vokse frit.
Jeg bygger både nyt og overtager eksisterende installationer. Det sidste begynder ofte med at finde ud af, hvad der faktisk bliver brugt, hvad der kan fjernes, og hvad man ikke skal røre, før man ved, hvorfor det er der.
Det svære ved WordPress
WordPress er nemt at udvide. Det er også problemet. Et plugin løser hurtigt dagens opgave, men efter nogle år kan resultatet være et system, ingen tør opdatere, fordi ingen længere ved, hvad der afhænger af hvad. Jeg forsøger derfor at holde installationen så enkel, som opgaven tillader – og sørger for, at kode, indhold og integrationer kan vedligeholdes af den næste, der overtager.
Om plugins
Hvert plugin er kode, som nogen skal vedligeholde. Jeg bruger dem, når de løser et reelt problem, og skriver selv det, der ikke behøver endnu en afhængighed. Færre bevægelige dele gør som regel både vedligeholdelse, performance og sikkerhed lettere at holde styr på.
Forløb og afregning
En ny installation eller et velafgrænset tema kan løses til fast pris, når omfanget er kendt. En overtaget installation starter altid på timebasis – man ved ikke, hvor meget arbejde den kræver, før man har set, hvad der faktisk ligger under overfladen.
Løbende drift, opdateringer og rettelser afregnes på timebasis, på samme måde som resten af samarbejdet – de fleste WordPress- og CMS-kunder er tilbagevendende, frem for enkeltstående opgaver.
Websites, der loader hurtigt – også på en telefon på et dårligt net.
Arbejdet begynder med en måling, ikke med et gæt. Ellers risikerer man at optimere det, der er nemt at måle, frem for det, der faktisk gør sitet langsomt.
Hvad det typisk dækker
Core Web Vitals, billedformater og -levering, caching i flere lag, databaseforespørgsler og mængden af JavaScript og CSS, browseren skal hente og afvikle. SEO-delen handler primært om det tekniske: strukturerede data, canonicals, hreflang, redirects og indeksering. Målet er at gøre det nemt for søgemaskinerne at forstå, finde og indeksere indholdet.
Hvad jeg måler på
Feltdata frem for laboratorietal, når der er trafik nok til det. Lighthouse er en diagnose, ikke en karakter. Målet er ikke 100 i Lighthouse. Målet er et hurtigt website, der fungerer godt for brugerne.
Forløb og afregning
En performance-gennemgang – måling, diagnose og en prioriteret liste over, hvad der reelt flytter noget – kan løses til fast pris, fordi arbejdet er velafgrænset. Selve implementeringen afhænger af, hvad målingen viser, og afregnes derfor typisk på timebasis.
Opfølgende målinger og justeringer, når sitet eller trafikken ændrer sig, håndteres løbende på samme måde som resten af samarbejdet.
Når der skal træffes en teknisk beslutning, og du mangler nogen at vende den med.
Det kan være valg af teknologi og arkitektur, vurdering af et tilbud fra et bureau eller en gennemgang af en kodebase, man har arvet.
Nogle gange er opgaven at finde den rigtige løsning. Andre gange er den at finde ud af, om den løsning, der allerede er foreslået, faktisk er den rigtige.
Hvad det typisk dækker
Kodegennemgang med en skriftlig vurdering, estimering og risikovurdering af projekter, teknisk due diligence før et køb og sparring med interne teams, der har brug for et erfarent, uafhængigt blik på deres tekniske valg.
Hvad jeg trækker på
Jeg har kodet professionelt siden 1998 og været CTO og medstifter af en digital platform, hvor tekniske beslutninger også skulle holde til drift, økonomi og revision. Jeg har set konsekvenserne af de valg, jeg rådgiver om – også de forkerte, jeg selv har truffet. Det betyder, at min rådgivning ikke kun bygger på, hvad der burde virke. Den bygger også på erfaring med, hvad der sker, når løsninger skal fungere i virkeligheden.
Forløb og afregning
Rådgivning afregnes på timebasis – det er svært at sætte fast pris på en vurdering, hvis konklusion man ikke kender på forhånd. En afgrænset leverance, fx en skriftlig kodegennemgang med en fast deadline, kan aftales til fast pris, når omfanget er kendt.
Opfølgende spørgsmål og videre sparring, når beslutningen er truffet og implementeringen går i gang, håndteres løbende på samme måde som resten af samarbejdet.
Vi anvender cookies og lignende teknologier til at sikre hjemmesidens funktionalitet, afspille indlejrede Vimeo-videoer og udarbejde anonymiseret statistik via Google Analytics. Du kan læse mere om, hvordan vi anvender cookies og lignende teknologier, samt hvordan vi behandler dine personoplysninger, i vores cookiepolitik.
Har du spørgsmål til vores behandling af data eller dine rettigheder, er du altid velkommen til at kontakte os. os.
Indsamler statistik om brugen af hjemmesiden, så vi kan forbedre indhold og brugeroplevelse.
Udløb
Op til 24 måneder
Hvad er en cookie?
En cookie er en lille tekstfil, som gemmes på din computer, tablet eller mobiltelefon, når du besøger en hjemmeside. Cookies anvendes bredt for at få hjemmesider til at fungere, forbedre brugeroplevelsen samt give ejeren af hjemmesiden information om, hvordan siden anvendes. En cookie er ikke et program og kan ikke indeholde virus eller anden skadelig kode.
Hjemmesidens brug af cookies
Vi anvender cookies for at sikre, at hjemmesiden fungerer korrekt, samt for at forbedre din brugeroplevelse. Cookies kan blandt andet bruges til at huske dine valg, eksempelvis sprogindstillinger, samtykkevalg og tekniske præferencer.
Derudover anvender vi statistiske cookies til at analysere, hvordan hjemmesiden bruges, så vi kan optimere funktionalitet, struktur og indhold.
Du kan se en detaljeret oversigt over de cookies, vi anvender, herunder formål og udløbstid, under kategorierne: Nødvendige, Funktionelle og Statistiske.
Hvor længe opbevares cookies?
Hvor længe en cookie gemmes på din enhed afhænger af den enkelte cookie. Nogle cookies slettes automatisk, når du lukker din browser (sessionscookies), mens andre gemmes i en længere periode.
Levetiden for hver cookie fremgår i vores cookieoversigt. Opbevaringsperioden beregnes fra dit seneste besøg på hjemmesiden.
Sådan afviser eller sletter du cookies
Du kan til enhver tid ændre eller trække dit samtykke tilbage via cookie-ikonet nederst på hjemmesiden.
Du kan også blokere eller slette cookies via indstillingerne i din browser. Vær dog opmærksom på, at hvis du afviser nødvendige cookies, kan visse funktioner på hjemmesiden muligvis ikke fungere korrekt.
