A visual identity has to work without the designer
A visual identity is easy to make look good on a screen. It gets harder when it has to go out into the real world – into a PowerPoint, onto an invoice, onto a sign someone edits themselves three years later.
[English translation pending — Danish text below as a placeholder.]
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 jeg truet som grafiker? 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.
48 years old, CTO, graphic designer, and full-stack developer (LAMP/LEMP) with 26 years of experience in developing digital solutions for a broad target group of companies.
From 2015 to 2023, I was CTO and co-founder of Lifeguard Health ApS. Here, I worked on the development of a digital health platform that combined technology, data and personal coaching. The role included everything from product development, UX and software architecture to management of development teams, operations and business development. The eight years at Lifeguard shaped my approach to both technology, products and people and today form the foundation for much of what I work with.
Read more
Watch Lifeguard's Core-story
Lifeguard presentation_1_4_
03_Employment_history_
My experiences
In my role as CTO at Lifeguard, I drew on the experience I have built up over the past 26 years.
In this section, I have tried to describe the experiences I have acquired through the tasks I have solved and the professional skills I have used.
As shown in the previous section, I have dealt with a wide range of tasks and taken on many different job roles, ranging from sound engineer to photographer, graphic artist, web developer, and CTO. The common feature in all of them has been my passion for creating meaningful experiences and my drive to create something unique.
In my approach, I have always been open to exploring new solutions to existing challenges, and I have never been afraid to acquire new knowledge. This has resulted in a wide range of skills that I have put together over time.
I have tried to list the most relevant ones here.
Rating
- " This is what I do best".
- " I'm pretty good at it".
- " I can do this just fine".
- " It's not what I'm best at, but I can if necessary".
- " I'm not good at it - but I'm willing to learn".
A visual identity has to work without the designer
A visual identity is easy to make look good on a screen. It gets harder when it has to go out into the real world – into a PowerPoint, onto an invoice, onto a sign someone edits themselves three years later.
AI-generated graphics have moved out of the computer and into the real world. The question is no longer whether AI can make graphics. It can. The question is what is then left of the graphic designer's work.
Valued at 35 million at its height, bankrupt in December 2023, a new company seven months later. This is what sat in between – and what I took with me.
When we built ESGRapporter, the competition had heavier calculation engines than we did. We bet somewhere else: on what the user was left holding being worth showing to someone.
I was born and raised in Copenhagen. But after a few years living with small children in an apartment in Østerbro, my girlfriend and I chose to move to a house in the suburb. We've lived in Hellerup for 11 years now, in a less pulsating neighborhood but no further away from Copenhagen than you can hop on the bike and then you're back.
I often do the latter; it's all about inspiration and new impressions. For the same reason, I still try to combine these trips with my passion for shooting photos. But since work has always been my hobby, it has been a challenge to find a balance between leisure and work projects.
When I'm not working, I spend a lot of time playing and listening to music. Unfortunately, over time, it has mostly become listening, which has been a very expensive but also rewarding passion.
The common feature of all my passions is the desire to create something. I hope this can benefit you.
TL;DR:We built the ESG reporting platform in Laravel, and I carried the technical responsibility for the direction, the reporting side and everything visual.
The demand for ESG reporting increased significantly due to new EU regulations and a growing focus on documenting companies' environmental, social, and governance efforts. Many businesses suddenly faced extensive reporting requirements without having the internal resources or specialist knowledge needed to handle the process.
In the early summer of 2024, I was approached by three people working on the idea behind ESGRapporter. They lacked the technical foundation and a profile experienced in digital platforms, UX and product development. I was recommended for the role by a former investor from Lifeguard Health ApS, and on July 29th 2024 we founded ESGRapporter ApS.
The requirements
The requirements arrived with the CSRD directive and the ESRS standard that accompanies it. They hit the large listed companies first, but the effect travelled downwards fast: a large company has to report on its entire value chain, and suddenly its suppliers found a questionnaire in the inbox they could not answer. A manufacturer with thirty employees had neither a sustainability department nor the budget for a consultancy – but it did have a customer demanding the numbers.
The gap in the market
The market was already filled with solutions focused on data collection, compliance, and enterprise-level reporting. However, we identified a gap: there were very few user-friendly platforms where ordinary companies and non-specialists could create ESG reports themselves without being experts in ESG, legislation, or reporting structures.
The vision behind ESGRapporter was therefore to create an “ESG for dummies” platform – a solution where users could build reports step-by-step through a more intuitive process while also having the ability to present the final report in a visually polished and professional format. The goal was to make ESG reporting understandable and accessible for companies without specialised ESG knowledge.
The project drew heavily on the experience I had previously gained from working with complex platforms, onboarding flows, and user-centered digital product development.
My tasks
I held overall technical responsibility for the direction: which way the platform should go, and what to build when.
In practice I owned the graphic design, the reporting side and everything visual – built in Laravel, with the information architecture and user flows. The admin module was built by my colleague Samuel – partly to take some of the load off me, partly because he had years of Laravel experience behind him.
A significant part of the work involved transforming complex reporting requirements and abstract ESG concepts into concrete and user-friendly workflows. This included onboarding flows, dynamic forms, report structures, export functionality, and presentation design.
We used AI to help users formulate and improve descriptive report text based on their own input. The purpose was not to fully automate ESG reporting, but to make the writing process more accessible for users who were not used to writing report content themselves.
The project required both technical understanding, product insight, and the ability to balance compliance, design, usability, and commercial considerations.
TL;DR:I handled development, UI/UX and graphic identity. 60% of my time went to BmyGuest and IDoMeetings, which Revolvo co-owned.
From mid-2024 I worked at Revolvo ApS as a Senior Developer covering development, UI/UX and graphic identity. Around 60% of my time went to BmyGuest and IDoMeetings – two companies Revolvo co-owned – with the rest going to the agency's own clients.
The role cut across disciplines that are usually split between several people: graphic identity and design at one end, frontend and backend at the other, with UX, technical analysis and debugging in between. Much of the work sat on top of established systems, where the existing codebase, the client’s business and the need for steady improvement all had to be reconciled. Clients included Egon, IDoMeetings, BmyGuest, ebillet and Formula Auto.
At Revolvo I worked on digital solutions for clients including Egon, IDoMeetings, BmyGuest, ebillet and Formula Auto. The work called for a pragmatic approach, often combining technical execution with a quick read on user experience, operations and commercial reality.
The stack changed from client to client – WordPress in one place, Umbraco or Magento the next – so part of the job was switching context without losing pace. It drew on my experience with SEO, performance, design systems and API integrations.
No greenfield
It is a condition of agency work that rarely gets said out loud: you inherit code you did not write, in systems you did not pick, for clients whose business you have a week to understand. There is no greenfield. There is a codebase, a history and a deadline.
That suited me. After twenty years, the interesting part is rarely building something new from scratch, but working out why the existing thing does not work, and what it takes to fix it without knocking something else over. It requires reading unfamiliar code quickly, and being willing to push back when a client asks for something that is technically a bad idea.
C#, .NET and Umbraco
Egon.no ran on Umbraco, which meant C# and .NET – a stack I had not worked in before. After more than twenty years in PHP it was a reminder that a language is learnable; it is the domain and the codebase that take time. I took it on because the client was there, and because a statically typed language and a different way of thinking about architecture are worth having tried.
AI as a tool
This was also where I started using AI in daily work – first ChatGPT, later Claude, wired straight into VS Code and my git flow. Not to write code I do not understand, but for what a new stack costs the most time on: reading unfamiliar code, getting up to speed in an unfamiliar framework, and having something to argue against when a bug refuses to surface. It has become a fixture in the toolbox, on a par with a debugger.
The role suited my profile because it demanded both broad technical experience and the ability to get into a client's solutions, workflows and constraints quickly.
My tasks
The work was split by client, and each one came with its own stack and its own backlog. These are some of the ones I spent the most time on.
Egon
Implemented a new design and helped build the membership portal and the ordering flow, which covers the chain's 45 restaurants across Norway. Wrote the frontend files and cleaned up the CSS and UX along the way – the site runs on Umbraco, so this meant C# and .NET.
IDoMeetings
Built their website and cleaned up the frontend stack. IDoMeetings resells a platform to its own customers, so the template has to carry many different identities without forking into one version per client. I developed new templates and features – among them a dashboard giving staff an overview of every room and its status on a single map.
BmyGuest
The broadest brief: graphic identity, design, UX and code – frontend as well as backend. As with IDoMeetings the end product is a template each customer gets their own version of, so the design had to be loose enough to hold all of them and tight enough to still look like something.
ebillet
Designed and coded the views and partials for the portals ebillet provides to its customers. 90 cinemas run their ticket sales on the system. Umbraco again.
Formula Auto
Started as a pure design brief – design and UX for the European arm of Spares.net – and turned into a full Magento 2 template with the pages built out. The same brief followed for sparesusa.net. That site is not live yet, so the link points to my demo build.
Two machines, two worlds
The real adjustment was not the language but the context. Egon and ebillet demanded .NET, meaning a PC and Visual Studio; everything else ran on my usual stack – a Mac with LAMP/LEMP.
Switching between the two machines several times a day took more attention than the C# itself. Each has its own shortcuts, its own tooling and its own way of doing things.
TL;DR:I built the LifeScore platform in Laravel with consent-based access to health data and an app for the wristband, and handled all UX and design.
I was the Co-founder and CTO at Lifeguard Health ApS. The company made it to its seventh birthday.
The idea
My partner and lead investor Mikkel Nybo Andersen had stepped down from the management of ContentCPH and sold his stake. He had an idea about making people healthier, and he needed someone who could carry the digital side and actually build it. We had worked together at the agency, so he knew what he was getting.
In 2015 Mikkel spent more than six months researching the market. We then began working on the concept, and on 23 May 2016 we founded LifeGuard Health ApS with the aim of creating a comprehensive and preventive B2B health concept with a holistic focusing on health, well-being, and performance. Our research showed that companies were already offering fitness subscriptions to their employees, but they had not been successful in motivating and retaining employees in a health program.
Digitising the coach
We recognized the opportunity to combine the best of both worlds: the digital world with the physical coach. By "digitizing the coach", we could deliver a scalable solution where many of the classic coach tasks could be moved into the digital domain.
This allowed us to combine automation principles and gamification known from existing health apps with people, creating results through a personal relationship. In collaboration with Morten Zacho, we developed a "Health Calculator" that could issue a numerical overall value for users' health with the help of onboarding data and ongoing input from both users and digital devices. This health calculation laid the foundation for all healthcare content.
LifeScore
Working with Morten Zacho, at the time working alongside Bente Klarlund at the Centre for Active Health, we developed the health calculation that became LifeScore. From onboarding data and continuous input from the user and their connected devices it computed three sub-scores – FitScore, DietScore and MindScore – which together produced a single figure for the user's health. LifeScore underpinned every piece of health content on the platform: it told the user where they stood, and the coach where to intervene.
The figure translated into three zones – green, amber and red. In practice it was an early-warning system: an employee heading for red was caught while something could still be done, rather than surfacing as sick leave six months later. That is the whole difference between prevention and treatment, and it was what the companies were paying for.
The platform and the app
The platform itself was a Laravel web application with role-based access. Five roles logged into the same solution and each saw a different version of it: the user got their training sessions, their health score and their dialogue with the coach. The coach got an overview of their users and could set up programmes. The health care manager – a clinical adviser from the insurer – could see personal data on the users who had consented, and intervene. The company manager got reporting on the workforce as a whole, never on the individual. And the administrator held it all together.
One person could hold several roles and switch between them – a coach could also be a user. That sounds trivial, but it means permissions cannot hang on the user; they have to hang on the role you are logged in as. With health data in the system, that distinction is not academic.
Alongside it ran a mobile app, published on the App Store and Google Play. Its main job was not to be a second interface but to act as a bridge: it pulled data from the user's fitness tracker and passed it on to the platform, where it fed into the health calculation. Without that bridge the calculation was left with whatever the user typed in themselves – and self-reporting is notoriously optimistic.
Tested by 5,000
The algorithm and the coaching concept were beta-tested across user segments before launch. More than 5,000 Danes onboarded the first version and helped us calibrate the model – and it was that body of data that made the calculation credible enough to build a product on.
VitalityGuard
Six weeks after founding the company, a shortcut appeared. Together with Dansk Sundhedssikring we set up a joint venture, VitalityGuard, which resold the same platform to their customers under a different name and a different visual identity. The same codebase, the same LifeScore – a new identity on top. It forced us to build the platform white-label ready from the start, long before we could afford to think about architecture for its own sake.
The shortcut was their sales operation: Dansk Sundhedssikring already had the customers and the relationships, where we had the product and no sales force. It brought Maersk in as a client. The partnership was dissolved in 2018 over a disagreement about sales strategy, and we went our separate ways with a shared source code.
Reload and Berlingske Media
With covid having shut down B2B sales, we tried to compensate by going straight to the consumer market. We built a freemium platform – a free health test and health profile as a springboard for selling coaching – and struck an affiliate deal with Berlingske Media on a ”no cure, no pay” basis: we carried the development cost, they carried the media cost, with the tabloid BT as the main channel.
The traffic arrived. Over 100,000 visitors in a short space of time. The sales did not. After two months we put the project on hold.
The diagnosis was uncomfortable but clear: the audience did not match, and the media strategy was wrong. We had assumed reach alone would sell, and underestimated how much a recommendation from a person is worth against an advert in a publication. The platform itself survived, though, and large parts of it were reused in the core product – so the work was not wasted, only the business model.
The company
LifeGuard was far more than training; we also offered sleep and stress guidance with podcasts, videos, exercises, and coach dialog. At our peak, we had more than 25 employees – the Facebook page still stands as an archive of what we built. We had financial backing from the Growth Foundation and several investors, and were a part of the entrepreneurial environment of Health Tech Hub Copenhagen.
It was covid that broke the business. The market shut, and converting customers became close to impossible: budgets were uncertain, appetite for investment had gone, and the HR departments we sold to were busy holding together an organisation that had suddenly gone home. We had stretches of four to five months with no sales worth the name.
And when companies came back, they were somewhere else. Working from home had become normal, budgets had been rewritten, and wellbeing was something you discussed on Teams rather than something you invested in.
We kept it running for three years after the lockdown but never found our way back to growth. In December 2023 Lifeguard was declared bankrupt.
My tasks
As CTO I was responsible for conceiving and building the platform. The audience was broad and fitness trackers were in their infancy – that, combined with the technical limitations of parts of the audience, forced us to be creative with the solution.
Code, design and team
I wrote the Laravel code myself, did all the UX and design, and owned the technical architecture. Alongside that I ran a small, scalable team of Romanian and Armenian developers, where my job was to scope the work, brief the developers and review and assess their commits.
In practice it came to roughly 40% development and design, 40% operations and management, and 20% marketing – including social and email. That is startup life: the role is not what the business card says, it is whatever is left undone.
Wristbands and data
The technical core was the integration with the fitness wristbands. Every user got one, and the Lifeguard app pulled steps and sleep data out of the wristband's own ecosystem and passed them on to the platform. That sounds simple, but hardware is unreliable: bands go unworn, Bluetooth drops, batteries die. The calculation had to survive gaps in the data without handing the user a score that was obviously wrong.
The audience was broad, too. We sold to companies, not to technology enthusiasts, and a fair number of users had limited experience with apps. The onboarding had to carry someone who did not particularly want to be there.
The shop
We also sold hardware and subscriptions: Mi Band wristbands, body-composition scales and health packages running three, six or twelve months. It ran on Shopify, which I built and operated – first under Lifeguard, later under Reload – with the themes written in Liquid.
The trick was making it feel like one product. The shop sat inside the platform behind the same login and the same navigation, so the user never experienced leaving Lifeguard, even though two systems were technically in play. A purchase in Shopify had to become access in Laravel: order a health package and the subscription had to be activated, a coach assigned and the wristband shipped.
It looks trivial in a diagram. It never is in practice – least of all when a payment fails halfway and a user is left with a wristband but no login.
White label from day one
Six weeks after founding the company, the platform had to be able to carry a brand other than our own. That forced a separation of content, logic and identity I would otherwise have deferred – and which turned out to be the right call when the partnership with Dansk Sundhedssikring was dissolved and the source code had to be split.
GDPR
Regulation (EU) 2016/679 was adopted at almost the same moment we founded the company. We handled health data – the most sensitive category there is – and it is not an area where you can patch things up afterwards. It set the constraints for everything from the data model to who could see what.
The answer was to split access in two. The first consent was required to use the platform at all: it gave the company anonymised, pooled figures for the workforce as a whole – never for the individual. The second was optional and let the clinical advisers see personal data, so they could reach out to an employee heading for the red zone.
You could use the system without giving your employer any insight into your health, and you could decide for yourself whether you wanted help. That line was not a detail – it was the precondition for anyone daring to use the system at all.
The work was formalised. Lifeguard was among the very first companies to complete the full process and earn the D-seal – Denmark's certification for IT security and responsible data use, backed by the Danish Industry Foundation, the Confederation of Danish Industry and the Danish Business Authority. We were also selected for the Danish Design Centre's programme on the Digital Ethics Compass, on thinking about data and digital design responsibly.
Technically it rested on Laravel, where the framework supplies part of the security itself: hashed passwords, CSRF tokens, XSS protection. All data was encrypted – TLS in transit, AES-256 at rest – and access followed the Principle of Least Privilege, so no employee could see more than their role required. We ran SIEM monitoring around the clock and static code analysis on everything we deployed.
The GDPR documentation itself was produced under VitalityGuard, where we could afford to have the law firm Bech-Bruun at the table. When the partnership dissolved in 2018, the material did not come with us.
I rebuilt it from the ground up together with Thomas Bonefeld Jørgensen and Jan Lindquist from Unikk.me: data processing agreements, DPIA, master policy, IT operations policy, privacy and security policy. Without a lawyer this time – there was no budget. It forced me to understand the regulation rather than nod along to someone who had read it. A hard way to learn GDPR, but it sticks.
The chat was the worst of it. User and coach messaged each other inside the platform, and people tell someone they trust all sorts of things – divorces, illness, sleepless nights, things they have not told their employer. Structured data you can categorise and bound; free text you cannot. The messages had to be treated as the most sensitive part of the system regardless of what was actually in them.
TL;DR:We ran the Lifeguard platform white-labelled through a joint venture with Dansk Sundhedssikring. Maersk was the biggest client.
Six weeks after founding Lifeguard, we set up a joint venture with Dansk Sundhedssikring. The deal was in place almost before our own company had got going. The aim was to deliver Lifeguard's services and platform to Dansk Sundhedssikring's customers as a white-label solution we called VitalityGuard.
Technically, VitalityGuard was the same platform as Lifeguard. The same codebase, the same LifeScore calculation, the same coaching flow – with an entirely different visual identity on top. It is a cheap way into a new market, but it demands that the platform be built so the identity can be swapped without the code forking in two. It was also what later made it possible to split the source code when the partnership was dissolved.
At that time, Dansk Sundhedssikring was new to the market and had experienced potential growth through an aggressive sales strategy. We grew together, and I experienced being given more resources for development. At the same time, we made the back office available, and with all the opportunities this gave us, we were able to focus on core tasks.
This meant that Lifeguard's development and roadmap were transferred to VitalityGuard. It is worth owning: we moved the direction of our own product into a company we only half owned.
That is the hidden price of a joint venture. You gain access to a sales operation you could never have built yourself, and to resources a bootstrapped startup cannot afford – but you pay with control over what gets built when. As long as both parties want the same thing, you do not feel it. It is only when they do not that the price becomes visible.
My Energy
It did not take long before Maersk came on board. A client of that size brought demands on security and documentation that lifted the platform – and an onboarding on an entirely different scale.
To carry it outward we drew up a shared communication strategy we called MyEnergy.
The name outlasted us. Maersk kept MyEnergy running as the umbrella for their whole health programme – still alongside Danica Pension – and later had a standalone intranet built on the brand. It is quietly satisfying: the platform is gone, but the concept held.
The model tested
The zone system and the two-consent model were inherited from Lifeguard, but this is where they were put to the test. Danica's healthcare managers were the ones who acted on the optional consent: they could see personal data on the employees who had given permission, and reach out to those heading for the red zone. Maersk only ever got the anonymised figures for the workforce as a whole.
It is a model that only holds if all three parties respect it. An employer pushing to see individual numbers would have brought the whole construction down. That did not happen – and frankly, it was the single most important precondition for anyone signing up at all.
Splitting up
It worked for two years. Then we started pulling in different directions.
Dansk Sundhedssikring wanted to build broad and slow: more features, larger clients, a platform that could carry their whole portfolio. We wanted to sell what we already had, to whoever would buy it now. Every time the roadmap had to be prioritised, those two wishes were set against each other – and the roadmap sat in the joint company.
The disagreement was about sales strategy, but behind it lay two different economic realities. Dansk Sundhedssikring had capital behind them and could afford to build slowly towards a larger market. Lifeguard was bootstrapped and had to earn money now – not in two years. Neither of us was wrong; we simply could not afford the same thing.
In 2018 VitalityGuard was split in two. An agreement was made on shared source code, and we left with a sum of money to keep Lifeguard running. It was a decent ending – no lawsuit, no locked codebase – and it was only possible because the platform had been built from the start so the identity could be separated from the logic.
Two years later, covid closed the market we had been arguing about.
My tasks
The role was the same as at Lifeguard: I wrote the Laravel code, did the UX and design, and ran the dev team. It was the same platform, after all. What changed was who set the requirements.
VitalitySync
The app followed the same white-label logic as the platform: at Lifeguard it was the Lifeguard app, here it was VitalitySync. The job was the same – to bridge. The chain was long: the wristband only spoke to the manufacturer's own app, Mi Fit, and from there steps and sleep data had to travel on into our platform. VitalitySync sat in the middle and translated.
Maersk
With Maersk came a security regime we had not met before. We had roughly a month to meet – and document – a set of requirements well beyond anything we had imposed on ourselves. It was uncomfortable, but it was also what lifted the platform: demands from a client that size are a free security audit, if you take them seriously.
At the same time we had to onboard large groups of employees at once. That asks something different from taking one user at a time: of the technology, and of the digital support that has to catch the ones who stall.
GDPR
Regulation (EU) 2016/679 was adopted almost as we founded the company, and we had two years to become compliant. That work happened here, under VitalityGuard, where we could afford to have the law firm Bech-Bruun at the table.
We built data protection and privacy into the business processes, the value chain and the product lifecycle, and a technical setup to support it. It was thorough, it was expensive, and it was worth it – not least because Maersk arrived shortly afterwards with demands we could not otherwise have answered.
Resources
In return we got something a bootstrapped startup rarely has: more developer resources and a back office that took the administration. It is hard to overstate what it means not to be doing the bookkeeping and invoicing yourself when you are also the one writing the code.
TL;DR:I built 60+ Facebook apps in PHP for Samsung, IKEA and H&M. The Nik & Jay campaign for Samsung won Danish Internet Awards 2014.
ContentCPH was a creative agency. But a bit of a bastard. A hybrid between an advertising, media, digital and activation agency.
ContentCPH has, since 2006, preached that customers should focus more on creating consumer involvement via relevant content. It was about providing new channels for target groups and events.
In 2008, I was recruited as an external Flash programmer and graphic designer. Through 2008-2009 I freelanced for them, and in 2010 I came on permanently, responsible for the digital content.
We ran Facebook pages for several high-profile companies, and when the activities were at their peak, we had contact with almost 800,000 Danish Facebook users through 60+ Facebook apps – among them Samsung, Sony, IKEA, H&M and TV3.
Social media
Back in 2010, the use of social media was growing. We had previously (2008) used MySpace to activate the Tiger Beer iPod Battle. But in 2010, Facebook was the one to use. We focused on activation and on the second screen – the screen the viewer held while watching TV. When viewers had watched the latest episode of ”Herre i eget Hus” or ”Masterchef”, they were invited over to Facebook, where they could interact with the show’s content, sign up for a roadshow with IKEA or Kvik Køkkener, or compete for a place in next year’s Masterchef.
The same move sat behind DFDS’ reality series on TV3: six episodes from the Oslo ferry, where TV3 followed the crew with no editorial control from the operator, and where social media carried the conversation on afterwards.
Samsung and Nik & Jay
We had a continuous and successful collaboration with Samsung Denmark. Among other things, I built a Facebook app for Samsung's activation of Nik & Jay. The app ran a countdown to the premiere of their new album UNITED: every time someone posted #pæntjatak on Instagram or Twitter, we took a minute off the clock. The audience could pull the release closer simply by making noise for it.
The countdown was eaten faster than expected, and the premiere moved 26 hours forward. I had to leave a family event in Tivoli to run it. That is the kind of miscalculation you want to make: we had counted cautiously, and the audience had not.
The campaign – activating Nik & Jay as ambassadors for the Galaxy S4 – won Danish Internet Awards 2014 in the Social Media category. We built it with Starcom and Universal Music. The jury cited ”an outstanding coordinated effort across multiple social channels” – activating Nik & Jay's fanbase and tying it to Samsung's products at the same time.
A festival camp with hot showers
Alongside this we also got Hennes & Mauritz on board, and from 2011 to 2013 ContentCPH handled the planning and execution of H&M Reboot Camp at Roskilde Festival.
Reboot Camp was a tent camp in support of Fashion Against AIDS: you bought a package with a pitched tent and breakfast, and a pop-up shop on site carried the collection. In 2011 that was 1,600 festival-goers in 800 tents, and the collection was more than 90 percent sold out by Thursday.
The point was that the camp looked nothing like the rest of the festival. Cofoco handled the food together with a sushi restaurant, and Joe & The Juice ran the lounge with food, drinks and entertainment – alcohol included, so for one week the bar was called Joe & the Booze. In the ChaChaCha styling salon professional hairdressers cut the guests’ hair, with the proceeds going to Aidsfonden. And there were hot showers.
It opened the festival to a whole new audience: people who wanted to be part of it, but not part of the mud pit. I have noted since that Roskilde Festival has increasingly built offerings aimed at exactly that segment.
On site I was part of the practical execution and the photo documentation.
My tasks
The title was ”Senior Digital Wizard”, which is the sort of thing an agency invents when the role does not fit a box. In practice I was the one who built what the others had sold.
60+ Facebook apps
The core of the job was Facebook apps in PHP. They look simple from the outside – sign up, upload a photo, enter the competition – but they had to be built again and again, for every campaign, with new rules, new data fields and a new deadline. Over five years it came to 60+.
That forces a kind of discipline. You cannot build 60+ apps from scratch and survive; you have to work out what recurs and build that once. It is the same lesson I later drew on at Lifeguard, when the platform had to carry two identities.
Everything else
Alongside that came flash and HTML banners for conventional media, static banners for Facebook, photo documentation of the live events the campaigns led up to, video editing, and advice whenever a client wanted something that could not be done.
TL;DR:I built campaign sites for Movia and the Danish Heart Foundation, among them Overraskende hurtig, which took bronze at the Creative Circle Award.
One of BOCCA's greatest strengths was the ability to tell stories. But back in 2009, the stories had moved over to the web. The solution to this was BOCCA // WIRED.
WIRED was a creative agency with a digital edge. In the two years they existed, they were a significant positive contributor to the BOCCA Group's financial result.
WIRED took home awards from the Creative Circle, the Danish Internet Awards, and the Webby Awards.
Overraskende hurtig
The campaign that ended up giving WIRED – and indirectly me – its first Creative Circle was ”Overraskende hurtig” (”Surprisingly fast”) for the Copenhagen transit authority Movia.
The task was to get more passengers onto the buses by making it tangible how far you could actually travel on the S-bus network. The campaign ran from late April 2009 across several weeks on outdoor, banners, bus wraps and a dedicated campaign site showing travel times and connections across the eight S-bus lines.
I was brought in by Mikkel Hyldenbrandt, Mikkel Würtz and Eskil Busck as an external Flash and PHP developer. Eskil and I had shared an office at Republikken, and we had already built the prelaunch site for L.O.C.’s Melankolia/XxxCouture together – so they knew what they were getting.
The campaign site was my part of the job. I built it together with a graphic designer and an art director – they handled the visual and conceptual side, I handled the development. It was awarded bronze in the Digital – Microsites category at the Creative Circle Award 2010 – a year when fewer than one in ten submitted works took any metal at all.
After only two years, WIRED was merged back into BOCCA Advertising Agency, driven by a wish to build a new agency with a stronger emphasis on owned media and digital campaigns.
In the meantime I had intensified my collaboration with a number of other agencies, among them BBDO, Verk and ContentCPH.
At the same time I was carrying a larger assignment for GN Netcom // Jabra, which I had taken over through EuroRSCG, and which demanded a good part of my time.
My tasks
From Photoshop to Flash
The workflow was the same every time: take the graphic elements, cut them up in Photoshop, import them into Flash and make the whole thing move. It sounds mechanical, but it is not – an art director draws what looks best, not what can be animated, and closing the gap between the two is what a Flash developer gets paid for.
The content lived in XML, not in the timeline
The S-bus campaign had to show eight bus lines, both directions, every single stop with its travel time and its connections to other lines. The standard Flash approach was to put all of that straight into the timeline. That would have meant hundreds of stops hard-coded into a file only someone with Flash installed could edit – and Movia revises its timetables twice a year.
So the content moved out of the movie and into XML. One schema per line, mirrored in both directions, where every stop was an element with a title, a travel time and a list of connections. The Flash file loaded those and built the display from them. The menu labels lived on their own, and the template for new lines sat as its own file, ready to be filled in.
The SEO was 2009 SEO
The price was visibility. A pure Flash site is a single file Google cannot read: no text, no links, no structure. All that tidy XML sat inside the player, where search engines never went.
The answer back then was meta tags – keywords in subject and dc.keywords, the list you wrote because that was how it was done. Google stopped listening to it soon after.
When HTML5 arrived the problem disappeared, and Flash went with it. It was a technology I spent years mastering that was dead five years later.
TL;DR:I won the agency's digital work back from the competitors and built an iPhone site and interactive product tools for GN/Jabra.
With over 300 offices in 75 countries, Euro RSCG was a top-five agency worldwide. But in Denmark, they lived a quiet life close to Vibenshus Runddel. As a network agency, they had several clients through their French parent company, including Citroën, Vichy and L’Oréal. These were supplemented by a solid portfolio of local brands – GN/Jabra, TV3, Vattenfall and Longo Vital among them.
Euro RSCG was strong on the creative discipline and delivered thorough work in classic media: ads, billboards, outdoor. But as the market moved, both clients and partners increasingly asked for digital formats and more flexible, technology-driven solutions.
The leap was bigger than it sounded. An ad is finished when it goes to print; a website has only just begun. It has to work in browsers that read the same code differently, it has to be fixed and extended after launch, and it reports numbers back on whether it actually works – numbers a billboard campaign was never measured on. With nobody in-house to translate between the creative brief and what could realistically be built, the digital parts of the work went to competitors, even when Euro RSCG had won the rest.
I had already been helping the agency with smaller digital jobs on an ongoing basis. But as the need grew and the work became both more frequent and more complex, I saw a clear opening to strengthen my own pipeline and position. So I left my shared office and took a desk of my own as an in-house freelancer at Euro RSCG. It put me next to both the creatives and the account managers, which meant getting into the work while it could still be shaped – rather than being handed a finished idea that then had to be forced into a technical reality.
My tasks
I was the agency’s digital voice – outwards towards the clients, and inwards whenever a creative brief needed a verdict on whether it could actually be built. The day-to-day production was online adaptations of what the agency already made: flash banners, online magazines in Flash, eCards and HTML mails. The agency’s own website sat with me as well.
Jabra
GN/Jabra was the client I spent the most time on. I built a standalone iPhone site – this predates responsive design, so the mobile version was a separate codebase with its own content.
Then came SoundLab and ComputeSpectrum, two interactive tools built in Flash. A headset sells on sound, but sound is hard to sell in print, and a specification in hertz means nothing to the person about to buy. The tools let the user hear the difference and see it as a curve at the same time – the product’s quality demonstrated rather than described.
On top of that came HTML mails and banner series in several language versions. I collected the recurring elements into a reusable toolbox with an accompanying design manual, keeping the visual language consistent across markets and cutting production time.
TL;DR:My own sole proprietorship since 2001. Through it I have sold web development to agencies that had the graphics but lacked the developer.
Bandits Inc. is my own personal playground.
The company was founded under the name Audiotracking v/Paul Nybo Andersen – a name picked more or less at random. At the same time I co-founded Audio Management ApS with a few others, and when the CVR registration needed something written on it, it ended up being a word from the world I thought I would make a living in back then: delivering and producing sound as a freelancer.
But no business strategy is complete without a marketing strategy, and I quickly found out that the things I could build in a browser to attract customers were in greater demand than the things I could do in front of a DAW. The name was never changed. It is still there, a sort of receipt for where I was headed when I got the number.
I have primarily used my CVR number to sell services to advertising agencies and companies that possessed graphic and communicative skills in-house but lacked a web developer. That is the role that keeps recurring: being the one who could build what the others had drawn. In practice the number has followed me through my entire career, running alongside the permanent positions and partnerships I have held along the way – it is the continuity, the rest are chapters.
The number has also lent its name to a fair amount of unpaid work for non-profit organisations, including Ombold and Save the Children.
A visual identity has to work without the designer
A visual identity is easy to make look good on a screen. It gets harder when it has to go out into the real world – into a PowerPoint, onto an invoice, onto a sign someone edits themselves three years later.
[English translation pending — Danish text below as a placeholder.]
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 jeg truet som grafiker? 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-generated graphics have moved out of the computer and into the real world. The question is no longer whether AI can make graphics. It can. The question is what is then left of the graphic designer's work.
[English translation pending — Danish text below as a placeholder.]
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.
Most people ask the wrong question first. The interesting one is not which CMS is best – it is whether the CMS is even the problem.
The question "should we get a new CMS?" usually arrives before the diagnosis. Somebody has become frustrated – the editorial team, the developers, management – and the frustration gets translated into a platform question quickly, because that is the easiest thing to act on. A new CMS is a project with a start and an end. Working out what is actually wrong is harder, and it often gets skipped.
First: what actually hurts?
What people call "a CMS problem" is usually one of three different things, and each needs a different fix.
A maintenance problem. Old plugins, no updates, code nobody dares touch, no version control. That is not the platform's fault – it is eight years where nobody cleaned up. The fix is cleanup, not a new system.
An implementation problem. The platform is fine, but this particular build is not – a product structure that was never thought through, an integration glued together at the last minute, a content hierarchy that made sense for the first project and not for what the site has become since. The fix is rebuilding the part that is broken, not replacing the foundation.
A platform problem. This is the rarest of the three, and the strongest argument for a new CMS: the way the platform models data and handles workflows no longer fits what the business needs. Not because anyone implemented it badly – but because what the business needs to do does not fit the way the platform thinks about content. Sometimes the answer is not a different CMS, but a different architecture around the existing one – see WordPress vs. headless.
A platform problem can also be more fundamental: the system is no longer maintained or security-patched, and staying on it is no longer safe.
The three get mixed up constantly, and that is expensive. A maintenance problem fixed with a migration is money spent on the wrong thing – and a real platform problem met with yet another cleanup is time that just postpones the same conversation a year later.
When the CMS is not the problem
Most "we should switch CMS" conversations start here, without anyone noticing. Plugins that overlap because different developers solved the same problem twice over eight years. A theme nobody dares update. No version control, so nobody knows what has actually changed since last time. None of that is a sign the platform is wrong – it is a sign the system has never had the maintenance it needed. I wrote the full list in The art of inheriting a WordPress installation; I will not repeat it here.
When the CMS has actually become the problem
A real platform problem looks different. It shows up when the way the system organises content and data no longer fits what the business needs to do. If a new feature keeps requiring another exception, another layer, or the same information stored in more than one place, it is worth asking whether the problem can still be solved within the existing platform.
The technical side is only half the story. A system can work flawlessly on a technical level and still be wrong, if the editorial team has outgrown it. If an editor has to know internal IDs to fix a page, copy the same content into three different places, or call a developer to create a new content type, the problem is not necessarily performance or old code. It is a sign that the system's workflows no longer match the organisation using it every day. Whether that calls for a new CMS or a better implementation of the existing one is exactly what needs working out.
What actually gets better?
Before deciding on a migration, there should be a concrete answer to: once we are done, we will be able to ___, which we cannot today.
"We get a newer codebase" is not an answer that carries a project of that size. "The editorial team can manage several markets without developer help" is. "Product data gets one model instead of living in three different places in three different ways" is too. The difference is whether the answer points to something someone can concretely do afterwards – not whether the code looks nicer.
What you leave behind
"We'll just build it fresh" sounds simpler than it is. Underneath sits content, URLs, redirects, metadata, structured data, images and files, users, integrations, forms, tracking, consent, historical data, editorial workflows, permissions, and everything the search engines already know about the site.
But there is also something less visible than the list.
The old solution contains eight years of decisions.
Some of them are bad. Some of them solve problems nobody remembers existed – an exception for one client, a workaround for a system that no longer exists, a rule nobody can explain any more but that still solves a real problem. Do not move anything before you know why it is there.
A migration is a project of its own
A migration is not installing a different system and pouring the old content into it. The old system typically has to keep working while the new one is built, and changes to content and data do not stop in the meantime.
That is why a migration also needs a plan for the transition: what moves automatically, what has to be rebuilt, what has to be tested, and when the new system takes over. "We'll just move the content over" often turns out to be the smallest part of the work.
Fix it, or switch?
Not because the system is old. Not because the code is ugly. And not because a different CMS looks better in a demo.
Switch when the existing system is in the way of what the business or the editorial team needs to be able to do – and when it costs more to keep working around the limitations than it does to move.
If the problem is instead plugins, missing updates and code nobody dares touch any more, you may not need a new CMS.
You need to get a grip on what you already have. That is also the part of the work on CMS solutions I most often get called in for.
The thing that makes WordPress easy to extend is also the reason behind most of the problems you meet in older installations.
[English translation pending — Danish text below as a placeholder.]
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 — the difference in practice
Headless gives you freedom by taking things apart. But whatever you take apart has to be put back together again.
[English translation pending — Danish text below as a placeholder.]
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.
Not because I have given up on Figma. But because sometimes it is faster to see whether an idea holds up in the browser than on a canvas.
When the idea is faster to build than to draw
There is a more practical side to the work I do. When I have an idea about how something should work, it can sometimes be just as fast and intuitive for me to write HTML, CSS and JavaScript as it is to work my way to it in Figma.
I write the structure, give it some styling, add a couple of interactions and see whether the idea holds up. Not as finished development, but as a prototype that already sits close to reality.
It has become even more obvious with AI tools like Claude Code and modern front-end frameworks. Setup, boilerplate and the fifth variant of the same button go faster, leaving more time for what actually needs a decision.
Two kinds of feedback
It gives a different kind of feedback.
In Figma I can see whether something looks right. In the browser I can see whether it works.
That is not the same thing. A static design cannot show me whether a flow actually holds together once I click through it myself, or whether an animation that looked right in my head actually feels wrong once it runs.
And sometimes that is the only place I discover that the solution I had pictured is not as good as it looked on screen.
That is part of what I like about being able to do both. I do not have to wait for someone else to build the idea before I find out whether it holds up.
Not a break with Figma
That does not mean I always start in code. Quite the opposite.
Figma is still the right tool for many of the early decisions. When flows need exploring, information architecture needs settling, or different approaches need comparing, it is far faster to be able to move things around without having to build them first.
But I no longer hold a fixed idea that design has to be finished before development begins. For me the two can be part of the same process.
A sketch can turn into code. The code can change the sketch. And sometimes the fastest place to find out whether an idea holds up is not the design tool, but the browser.
That is also the experience I bring into web design and UX and web development: a design thought through with buildability in mind, and code that respects the thinking the design has already shaped.
The most expensive code is the code you never had to write
Not all expensive code is bad code. Some of the most expensive decisions I have been part of were well-written solutions to problems nobody had yet.
26 years in the trade, and especially the years with Lifeguard, taught me how easy it is to mistake product development for value creation. When you can build something, it is tempting to build it. A new feature solves a problem. An integration opens a possibility. A more flexible architecture future-proofs the product. The problem shows up when you build a solution to a need you have not yet proven.
What cost before we knew what it was worth
The white-label architecture behind Vitalityguard is the clearest example. It was expensive in the week it was decided, with no guarantee anyone would ever need to swap the identity on top of the platform. It turned out to be the reason we could sell the same platform on under a different name six weeks after founding it.
The D-mærket seal is another. We were among the very first companies to go through the full process and become D-mærket certified - the Danish labelling scheme for IT security and responsible data use. It was a heavy process that ran over a year. At the time it was hard to see what the investment would concretely give us. It later turned out to open doors we would not otherwise have had access to.
Neither was the wrong decision. Both were expensive before they were worth anything, and that is the kind of investment you cannot know pays off - you can only know that none of them do if you never make them.
But that is not the same as building ahead
The other day I sat in on a class at EK - Copenhagen Business Academy at the Guldbergsgade campus. A former colleague now teaches database design there, and I was there to watch him teach - to form an impression, not to say anything. But he asked me to add to it as we went. What I told the students was that building a database is not only about solving the needs a client has now, but also the ones that arrive over time, that the client does not yet know they have.
That sounds like the opposite of the point above. It is not - but it is the other half of the same decision, and it is easy to forget once you have been burned by the expensive version of it.
The zone system in Lifeguard is the example - userspaces, as we called it internally. A user could hold one of several roles - from ordinary user to coach to the company's own administrator - and belonged to one or more teams, which in turn sat under a company. That was more granularity than any single client relationship required at the time. When Vitalityguard later had to give Danica access to users' data, we could not simply hand it over - not legally, and not in practice. The solution was a new userspace for Danica - not a new construction, but another layer on top of the structure that was already there. That is why we could solve it in three weeks: they could see what the user had given permission to share about themselves, the user could revoke that permission at any time, and all data processing stayed inside our own system. We never gave the data away. Had access and visibility not already been separated in the model, it would have been a rebuild, not an addition.
The difference is not whether you build ahead
It is what you build ahead for. The zone system was a structural choice: a data model that kept roles, teams and visibility separate, without knowing exactly which combination would be needed. We did not foresee Danica. We just built something that could hold an unknown need without being rebuilt. It costs something to build flexibility in from the start. But it can cost far more to discover afterwards that the structure cannot hold the need.
The white-label architecture was the same kind of choice - structure, not feature. What is expensive is something else: building features, integrations and options on a guess about what someone will use them for. That is not foresight. It is building what increases the options before you have built what reduces the uncertainty.
So the point is not build less. It is: build the structure that can hold what you do not yet know - and wait on the rest until someone actually asks for it.
Where code turns into economics
As a developer you ask whether something can be built. As the person responsible you also have to ask why it needs building now. That is the difference between code that solves a problem and code that just opens up a possibility.
I wrote about the economic side of this in After a bankruptcy: a technical decision is also a financial decision. This is the other side of the same experience.
It is also what I spend my time on in technical advisory: asking why before asking how.
From coder to reviewer – how AI changed the workflow
In the short term, AI does not change what I know – it changes my workflow.
“AI will never be worse than it is right now.”
Lars Nielsen, friend and former business partner
That line stayed with me.
Not as a defence of AI, but because it moves the question. The argument about whether the tool is good enough has an expiry date. The question of what you do yourself once it is does not.
What actually changed
I have been coding professionally since 1998. For most of that time the work was writing the code – sitting with the problem, finding the way through and writing the lines myself. It is still a large part of my work. But not in the same way as before.
I still write code, but a larger part of the day goes to stating the task precisely, assessing what comes back, and rejecting what does not hold. It looks less and less like one developer in front of an editor, and more like a developer who is also running a very fast, very literal and rather unreliable small team.
It reminds me of sitting at Lifeguard briefing my developers – writing the tasks into Trello, explaining what needed building, and reviewing what came back. The working day now feels closer to that role than to the one I had ten years earlier.
Why it takes more experience, not less
The common assumption is that the tool makes experience worth less. My experience is the opposite. A model can write something that looks convincingly right even when it is not – and the difference is not necessarily visible on a first read.
Seeing that difference requires knowing what to look for:
The query that works on ten rows and falls over at a hundred thousand.
The error handling that looks complete but never covers the path that matters.
The library that solves the problem and drags in thirty times more than needed.
That does not come from knowing how to prompt. It comes from having seen systems work, fail and be maintained long enough to recognise the problems before they get expensive.
That judgement has not become less important. It takes up more of the work than ever.
What I hold on to
I do not let anything ship that I have not read. Not on principle, but because I answer for it. When a client calls in eighteen months because something has broken, it is not a tool that has to explain why it was built that way.
And there are still tasks where I open the editor and write it myself, because that is faster than describing it. That is not nostalgia. It is the right call more often than the debate suggests.
Will there be developers in the future?
I have asked myself that often. I think there will be.
But I think a great deal more is going to get built. Things that used to be too expensive to build can now be done in a fraction of the time. And when the price falls, people do not necessarily stop buying. They also start buying what they previously had to go without.
There will still be demand for solutions that are not generic, and for design somebody has actually thought about. That does not become worth less because the trivial gets cheaper.
What worries me more is the way in. The routine work – the tasks you learned the craft on – is being taken over. That was where you built the experience that later lets you see when a suggestion does not hold up.
I do not know where that experience is meant to come from now. I have no good answer to that.
Nor do I know how much of the code I work with in five years I will have written myself from the first character.
But that is no longer the interesting question either.
I still have to understand the problem. I still have to see when the solution is wrong. And when the client calls eighteen months later, the responsibility is still mine.
I am still the developer. I just spend more of the day reviewing a colleague who writes extremely fast, never gets tired, and is occasionally completely wrong.
It is also the experience that goes into web development: being able to tell whether something works, regardless of who or what wrote it first.
Lars Nielsen, who set the thought going, regularly publishes on AI on LinkedIn and on YouTube.
8 years, 34 plugins and a theme nobody dares touch. The job does not start by fixing anything – it starts by working out what is in use.
The job rarely arrives as a project. It arrives as “our site has got slow”, or “we cannot update anything without something breaking”. Behind it sits a WordPress installation that has been running for eight years, and that nobody has had a full picture of since the developer who built it moved on.
It is one of the more common jobs in the WordPress world. It just gets described rarely, because it is not a new site with a before-and-after picture.
The first step is not to fix anything
The temptation is to get going: deactivate plugins, update the core, clean up the theme. That is also the fastest route to switching off something that turns out to matter.
The first step is working out what is actually in use. Which plugins do something the site actually shows. What page types exist, and who edits them. What happens on an order, a sign-up, a form – the whole way from click to email or database. It usually takes a day or two, and it is the best-spent time in the whole job.
The rule I work by is simple: do not touch anything until you know why it is there. Code that looks redundant is often somebody's solution to a problem documented nowhere.
What you usually find
Some patterns recur.
Plugins that overlap. Two caching plugins installed by two different developers. A gallery solution used on a single page nobody has visited in two years.
Plugins emitting competing metadata. The worst kind of overlap, because nothing visible goes wrong. Two SEO plugins each write their own title, their own canonical and their own Open Graph tags into the same document head, and the theme may add a third set on top. The page looks right in a browser – but Google gets contradictory signals about what the page is called and which URL is the real one. It is not one broken plugin. It is two working ones.
Changes made in the theme rather than a child theme. Which means the theme cannot be updated without losing them – and so it has not been updated. From there it spreads: with the theme standing still, nobody dares update WordPress or PHP either, and eventually the whole installation is held in place by something nobody can remember.
Tracking that runs around the consent. Google Tag Manager installed through one plugin while consent is handled by another. Separately they both work: the banner appears and stores the choice, and GTM loads its tags. They do not necessarily know about each other, so the visitor's choice in the banner is not turned into the behaviour you assume. It is the kind of thing you do not find by using the site normally, only by looking at what the browser actually sends.
Code nobody dares touch. A functions.php of 1,000 lines, most of it added by different people over several years. No comments, no history, because it was never in git.
What I do about it
The order matters more than the tools.
A copy and version control. The installation has to live somewhere you can try things without touching what the client is using. And the code has to go into Git – not to be modern, but because it is the difference between “we changed something and now it does not work” and “we can see exactly what happened”.
What hurts now. If the site is slow, I measure why before optimising. If a security update has been deferred for two years, that matters more than tidying. The client should feel a difference before anyone starts on the work that cannot be seen.
One thing at a time. One plugin removed, the site tested, on to the next. It takes longer than clearing everything in one pass, but when something breaks you know what it was.
What makes next time easier. A child theme, so the theme can be updated. Changes moved out of functions.php to somewhere they can be read. A short note on what is where.
When it is not worth it
Sometimes the answer is to build new. It is when the theme is so far gone that clearing it up costs more than a new frontend, or when the content structure does not fit what the site has to do today. If it is the frontend that is the problem, that is not automatically an argument for leaving WordPress as the CMS – see WordPress vs. headless.
But that is rarer than people think – and it is worth noting that whoever would build the new one is rarely the most objective judge of it. A site with eight years of content, indexing and inbound links has a value that does not appear in the codebase.
What it is really about
An inherited installation is rarely only a technical problem. It is also a question of somebody being able to answer what happens, and why.
That is what the work is: turning a system nobody understands into a system somebody can run. The code gets better along the way, but that is not the point. The point is that the next time something has to change, it is a task and not a risk.
It is the same approach I bring to WordPress and CMS: understand what is already there before anything gets touched.
What I meet most often
An inherited installation rarely has all of them, and few are serious on their own. It is the combination that makes a job hard to estimate.
01_Plugin debt: 30-60 plugins, several solving nearly the same problem, some abandoned, and nobody sure any more which are needed.
02_Plugin conflicts: Two plugins hooking the same place, loading different versions of a library, or changing the same behaviour.
03_Update anxiety: WordPress, PHP, theme or plugins cannot be updated, because nobody knows what breaks.
04_Bought themes and page builders: Elementor, Divi, WPBakery and the like can, after a few years, leave a site that is hard to change without working against the system.
05_Performance: Plugins and themes loading CSS and JavaScript on every page, including where it is unused. Plus heavy images, expensive queries and missing caching.
06_Database cleanup: wp_options, autoloaded options, revisions, transients and tables from plugins deleted long ago.
07_WP-Cron: Convenient until jobs get heavy, fail quietly, or need to run reliably at a particular time.
08_Security: Old plugins and themes, permissions that are too broad, XML-RPC, file uploads, unprotected endpoints, and enough administrators to field a football team.
09_Custom code in the wrong places: Changes made directly in the parent theme or in a plugin, snippets in functions.php - and the classic small fix in core.
10_No version control: Changes made straight onto production through wp-admin or FTP, and no reliable way to see what changed since last time.
11_Staging and production: Database content has to go one way, code the other, while uploads and editorial changes had better not be overwritten.
12_URLs in the database: Serialised data and absolute URLs make an ordinary search and replace more interesting than it ought to be.
13_Mail: wp_mail() can return success without the mail reaching the recipient's inbox. SMTP or a mail service, SPF, DKIM and DMARC suddenly become part of the WordPress job.
14_REST API and integrations: Authentication, rate limits, webhooks, retries, and external systems that do not behave the way the documentation promised.
15_WooCommerce: A category of its own: checkout, hooks, order statuses, payment gateways, VAT, shipping, mail, and plugins on top of plugins.
16_Multilingual: WPML or Polylang, hreflang, translated slugs, canonicals, and content that does not exist in every language.
17_Technical SEO: Redirects, canonicals, sitemap, robots, structured data - and several SEO plugins all wanting to own the contents of <head>.
18_Tracking and consent: Tag Manager, GA4, Google Ads, Consent Mode and cookie consent. Typically where you find that three plugins and the theme all insert tracking.
19_Gutenberg and blocks: Good when it has been thought through. Less good when the editor gets 80 blocks and the means to break the design system.
20_Roles and permissions: Editors should be able to change this but not that - quickly more complicated than WordPress default roles reach.
21_The media library: 12,000 images, 14 generated sizes of each and 40 GB of thumbnails, with nobody knowing which ones the theme uses.
The list is not an accusation against WordPress. It is what happens to systems many people have touched over eight years.
A language is learnable. It is the domain and the codebase that take time – and two machines that cost more attention than the syntax.
After some twenty years with PHP as the language I thought in, I moved partly over to C#. Partly, because it depended on the project: Egon and ebillet ran on Umbraco and required .NET, while the rest of the clients stayed on my usual stack.
Syntax you can read your way into. Types, classes, inheritance, interfaces – the same concepts I have used all along, with different keywords in front of them. A week in, I could solve real tasks in C#.
What actually took time
The domain. What the business actually does, why the numbers are calculated in precisely that way, which rules are written down nowhere because everyone in the office knows them.
And the codebase. Not the language, but this system's version of it: why there are two layers that appear to do the same thing, which one is the new one, and what the old one is still used for. That is learned by reading and asking, not by looking things up.
The platform was Umbraco, not just C#
The structure was recognisable. Helpers, middleware, models, views and services all had parallels to the world I knew from Laravel. I had to learn a new implementation, not a new way of thinking about web applications.
And to be honest, my work fortunately sat mainly in the view layer and in assets – where the distance between the two worlds is smallest. I did not move to .NET across the board; I worked in the end of it where my experience carried over most.
What I had to get used to was having to start the project in order to see it. Behind the little green play button in Visual Studio sit four things:
Starts IIS Express.
Publishes the project to it.
Attaches the debugger.
Opens the browser.
In PHP you save the file and hit refresh – the web server is already running, and there is nothing to publish.
It changes the rhythm of a working day. You stop fixing one thing and looking, and batch several changes instead, because each round costs a startup. In return you have a debugger attached from the first second, which is not nothing.
Two machines
The .NET work happened on a PC in Visual Studio Professional – not VS Code, which I use for everything else, but the full IDE. Whenever design elements were needed, or when the day brought one of the clients still on PHP, I moved back to my Mac. The tools and the workflow live there, and that is faster than rebuilding the same setup on the other machine.
Practically it was solved. The mouse and keyboard could switch between the machines at one press, and both machines used the same monitor. The hardware was not the problem. What did not switch was my hands.
The files did not follow on their own either. Graphics moved between the machines through OneDrive, which was already attached to the project – low-tech rather than elegant, but it worked, and nobody had asked for anything better.
The keyboard shortcuts sit in different places. Copy, paste, switch window, jump to the start of a line – after twenty years they are in the fingers, and one press of that button puts them in the wrong place. Worst are < and >: on a Danish layout they sit in one place on the Mac and another on the PC. Writing markup or generics you reach for them constantly, and the fingers go to the wrong place just as constantly. You do not rewrite anything; you just hit the wrong key and notice a second later. Each time costs nothing. A hundred times a day does.
Several times a day, for months. That is the kind of thing that appears in no account of what changing language costs.
What I took with me
After twenty years with PHP, it was interesting to discover how little of the experience was actually tied to PHP.
Reading unfamiliar code, finding the patterns in a system, asking the right questions about a requirement, and knowing when something is likely to become a problem later – that all came along. It is the part of web development that has nothing to do with the language, and everything to do with understanding what is already built.
C# had to be learned. Of course. But it turned out to be the least interesting part of the change.
The hard part was getting to know one more codebase, one more domain and one more platform.
And remembering whether copy was under Ctrl or Cmd.
Valued at 35 million at its height, bankrupt in December 2023, a new company seven months later. This is what sat in between – and what I took with me.
In December 2023 Lifeguard Health was declared bankrupt. We had run for seven years, employed 40+ people along the way, had Maersk as a client, a joint venture with Dansk Sundhedssikring and investors behind us. At its height the company was valued at 35 million kroner. Then covid came, and we never found our way back.
The last months went on keeping it alive while we waited for the client who was meant to save it. The client pulled out at the 11th hour. There was no plan B, and there rarely is at that point - you have spent everything you had on getting there.
On a CV that reads as a smooth transition. It was not.
It takes longer than the accounts say
A bankruptcy has a date. The administrator sends a letter, the company ceases, and a year appears in the company register. All of that is over in a few weeks.
What takes time is something else. A company you have built over seven years sits in your head as a collection of unfinished thoughts: what should have been done differently, when you ought to have seen it, who you owe an explanation. None of it closes because the administrator is done.
I thought I would spend the time working out what I wanted to do next. That was wrong. The time went on working out what had actually happened.
What actually went wrong
Going through it, it split into what the market did to us and what we did to ourselves. The line between the two is less sharp than I would like it to be.
The first looked like pure timing for a long while. We built a B2B health platform for HR departments and entered an investor world where a company is meant to be sold on within three to five years.
The timeline is worth holding up against that expectation. 2015 and 2016 went on building. From 2016 we ran VitalityGuard as a joint venture with Dansk Sundhedssikring for two years, growing on their sales operation. In 2018 the partnership was dissolved over a disagreement about sales strategy, and we spent the time that followed finding our own direction again - and selling for ourselves, for the first time since the build-up.
There is something here I only saw afterwards. We entered a world that counts in exits without having built towards one. There was no plan for who the company would be sold to, or what it would look like on that day. We built a product we believed in and assumed the rest would follow.
Something I have noticed since about business people who succeed is that they rarely have only one place their income comes from. We had one shot. And it was not built to be sold.
That is where we were when everyone went home in March 2020. And when they came back a year later, HR was buried in logistics: moving workstations back, working out who came in on which days, holding together an organisation that had grown used to something else. Preventive wellbeing was not top of the list.
In 2021 we tried something else: a partnership with the Danish tabloid BT, which we called Reload, an attempt to take the concept from B2B to B2C. It was an attempt to find a way around the market that had just closed - and that did not carry either.
The rest is harder to look at, because it was ours. We could document the value. Better wellbeing, fewer sick days, less stress, higher retention - numbers we could put on the table. And the companies still would not pay for it.
The reason was the price, and the price was our own decision. We developed continuously and our ambitions were large, and on top of that sat the personal coach - the thing that made the product work, and the thing that made it expensive. HR could see the value perfectly well. HR simply did not hold that kind of budget - finance did. And finance actually understood the numbers better: productivity, and two fewer sick days per employee, is a sum they can do. They just did not need a wellbeing product to arrive at it.
There is a question I still have not answered: was the product too complex? We worked constantly to solve every challenge the company and its users had, and each individual decision made sense when it was taken. But we ended up as a Swiss army knife. Something that does everything, and is therefore hard to explain simply.
I do not know whether a smaller product would have sold better. I do know it would have been cheaper to build, cheaper to run and easier to explain to someone outside HR.
That is the mistake I think about most. Not that we built something that did not work, but that we built something large for someone who could not buy it. We built for HR and spoke HR's language, while the decision sat with someone measuring in something else entirely.
In some ways it felt like a car crash in slow motion. You can see what hits what, and you have plenty of time to think about it. You just cannot move out of the way.
What I took with me
The first is obvious and still hard: build the thing that proves the assumption before the thing that rests on it. We had the technology in order long before we knew whether anyone would buy. Building feels productive. It is also the easiest way to postpone the question that decides everything.
The second is about what you say yes to. At Lifeguard I was CTO, co-founder and for long stretches the person writing most of the code. That made sense while we were few. It made less sense with 25 people on the payroll at once, and it is hard to let go of something you built yourself — even when it is the only right decision.
The third is the one I took most of: a technical decision is a financial one. The white-label architecture we built for VitalityGuard was expensive in the week it was decided, and it was the reason the platform could be resold under another name six weeks after founding. The GDPR work with Bech-Bruun was expensive and felt excessive, right up until Maersk arrived with demands we could not otherwise have answered.
You cannot know in advance which of those investments pay off. But you cannot build something that holds without making some of them either.
Why I did it again
When three people approached me in the early summer of 2024 about ESGRapporter, my first answer was not yes.
What made the difference was not the idea. It was being recommended by a former investor from Lifeguard - someone who had watched it fail and still put my name forward.
I also knew what I was walking into this time. Not how it would end, but I had been at the other end of it before. I knew what it costs to build too much, what it costs not to leave things out - and how much has to be in place before you write the first line of code.
What a success does not teach you
There is a great deal written about starting a company. There is vanishingly little about closing one — at least from the person who was standing in it.
Not because it is rare. Most companies close. It is because there is nothing to sell in the story, and because the person who has been through it rarely wants to be the example.
Victory has a hundred fathers, defeat is an orphan. That is why one kind of story gets told over and over, and the other gets told by nobody.
But I think it is the most useful experience I have. Not because it makes me better at avoiding it — it does not — but because I now know what the decisions I advise on cost when they go wrong. That is a different kind of knowledge from reading about it.
When something works, you do not know why. You did a hundred things, and they worked. When it does not, you get that bill itemised.
Lifeguard ran for seven years. That is not a failure lasting seven years. It is seven years that ended in a bankruptcy, and those are not the same thing.
This text will probably never be finished. New realisations turn up over time, and each one shifts what I think happened, a little. That is presumably how it goes with this kind of thing.
When we built ESGRapporter, the competition had heavier calculation engines than we did. We bet somewhere else: on what the user was left holding being worth showing to someone.
The requirements arrived with the CSRD directive and the ESRS standard that comes with it. They hit the large listed companies first, but the effect travelled downwards: a large company has to report on its entire value chain, and suddenly its suppliers found a questionnaire in the inbox.
A manufacturer with 30 employees had neither a sustainability department nor the budget for a consultancy. But it did have a customer demanding the numbers.
That company is who we built ESGRapporter for. I was a co-founder and CTO, and the platform had to make an ESG report possible for someone who neither knew the standard nor had anyone to translate it.
The market was already there. So the question was not whether we could build another calculation engine. It was what to build instead – and the answer came in two halves that belonged together.
The numbers are not the hard part
What users got stuck on was rarely a calculation. It was the descriptive sections.
An ESG report is not only consumption figures. Something has to be said about the company's policy in the area, about how risks are handled, about what was done this year and what is planned. That cannot be computed. It has to be written.
And there sits an operations manager with an empty field and a heading that reads like something out of a statute. They know perfectly well what the company does. They just do not know what one writes.
Saying what should go there
That was one half of the work. Not explaining the standard, but saying what should go in the field.
Every field got its own way in: what this section is about, what usually goes in it, what a reader would want to know. Not a definition of the requirement, but a concrete suggestion of what you might answer. We used AI to help finish the wording from the user's own notes – not to invent the content, but to turn three lines into a paragraph that reads.
The difference is who stands behind it. An ESG report is a document the company answers for. Generated by a model making educated guesses, it falls apart the moment somebody asks where it came from.
The report is a product, not a filing
The other half of the bet was the document itself – what sat on the screen when the work was done.
Most tools in the market delivered data. A spreadsheet, a compliance file, something to pass on and file away. Technically correct, and entirely without value on the day the company would like to use the work for something.
Because when a company has spent a week on this, it does not just want it over with. It wants to show it. To the customer who asked. On the website. To the partner who raises sustainability, because it has become part of the conversation.
So our report had to be printable. 17 A4 pages with a cover, typography and a layout carried through – not a PDF printout of a form, but something that looked like an annual report. Something you could leave in reception.
When design and code are the same problem
It was also why the job suited me. I have done graphic design as long as I have written code, and here the two sat inside the same product.
A report layout that has to stand up to content nobody knows in advance is not a design problem or a code problem. It is both at once: a table has to break across two pages without losing its header, a section of forty words and one of four hundred both have to look as though they were meant that way.
Had a designer drawn it and somebody else built it, we would have ended up in the round where the drawing and reality negotiate. Here there was no round. It is the same thinking I bring into web design and UX: a design has to hold up to reality, not just to the first draft.
The hard part is saying no
Every time a user got stuck, there was a temptation to add: one more field, a note, an exception, a setting. Each of them is reasonable on its own.
Together they are the reason the original problem exists. The enterprise tools for ESG are not complex because somebody wanted them complex. They are complex because every single addition made sense when it was made.
Keeping something simple is not a phase at the start of a project. It is a decision you have to make again every time.
From database and backend to frontend, integrations and hosting.
I develop and maintain web-based solutions end to end. That means I can take responsibility for the whole technical chain – including the parts that sit between systems, and what has to keep working once the solution is in production. I work mainly in PHP, Laravel, MySQL and JavaScript. I reach for frameworks and other tools when they make sense for the solution – not simply because they exist. Where the design side also needs covering, web design and UX is that part.
What it usually covers
Integrations to third-party APIs, payment flows, user administration, permissions and the admin tools editors and support staff use day to day. It is often the part of the solution the user never sees, but the part that decides whether the system works and can be operated efficiently – scheduled jobs, mail flows, logging, data import and export, webhooks, and the hosting and deployment behind it all.
How I work
I take over existing solutions as often as I build new ones. The first step is understanding what has already been built – and why. Including when the documentation is missing. Then I fix what hurts now, while keeping an eye on what should improve over time. The aim is not necessarily to rebuild everything, but to make the solution work better, be easier to maintain, and lay a solid foundation for whatever comes next.
Process and pricing
The starting point is hourly billing, since development work rarely has a fixed scope before it is under way. An integration can turn out to be simple, or surface ten edge cases nobody could have seen coming. When a task is defined tightly enough to estimate with reasonable confidence – a specific feature or a well-defined integration – it can also be quoted at a fixed price.
Delivery does not necessarily mark the end of the collaboration. Fixes, adjustments and further development happen on an ongoing basis, the same way as the rest of the collaboration. Most clients are recurring, and the code keeps living long after the first delivery.
Interface design that has to work for the user and the business alike.
The starting point is what the user has to be able to do, and what the business needs out of it. I work in Figma, from the first wireframes and prototypes through to the finished design and design system. Where it also needs building and running, web development is that part.
What it usually covers
Information architecture, wireframes, interactive prototypes and component libraries that development can work directly from. Where the project allows for it, I test on real users. Finding the problem there is usually cheaper than finding it after launch.
The advantage of my also writing the code
The design becomes easier to build. I have a good feel for which design decisions typically cost development time and which do not, and I deliver specifications a developer can use without guessing. That removes the round where design and development negotiate over what the drawing actually meant.
Process and pricing
Design work starts on hourly billing until the scope is clear – how many screens, how many iterations, and whether it needs testing on real users along the way. Where the task is well defined, such as an update to a component library or a specific flow, it can be quoted at a fixed price.
Delivery does not necessarily mark the end of the collaboration. Adjustments to the delivered design and further iterations, as the product evolves, are billed on an ongoing basis, the same way as the rest of the collaboration.
Visual identity for companies that need to look like something you can rely on.
Logo, colours, typography and the guidelines that hold it all together – including when people other than me carry it on.
What it usually covers
Visual identities, design manuals, print, packaging, signage and presentation material. I work in Photoshop for image work, Illustrator for logos and vector graphics, and InDesign when the material has to be laid out for print – with the specifications and setup a printer can actually use.
Why it connects to the rest
An identity that exists only as a PDF falls apart the moment it has to be used on a website. So I build the identity as a system that can be carried the whole way, from business cards and presentations to digital components and CSS. The identity has to stay recognisable and hold together wherever you meet it.
Process and pricing
A visual identity is often the kind of task that can be scoped in advance – logo, colour palette, typography, a design manual – and can therefore be quoted at a fixed price once the scope is agreed. Ongoing work, such as print material or new assets down the line, is billed hourly.
Adjustments and extensions of the identity – new formats, new applications – are handled on an ongoing basis, the same way as the rest of the collaboration.
Content systems built for the people working in them every day.
I work mainly with WordPress, but also with Umbraco and Magento – and with headless solutions, where the editorial side and the frontend are separated. The starting point is that the editor should be able to look after the content without knowing the system underneath, and without depending on a developer for every small change.
What it usually covers
Themes built from scratch rather than bought off the shelf, custom fields, blocks and components, integrations and migration from older systems – as well as clearing up installations where plugins have been allowed to grow unchecked.
I both build new and take over existing installations. The latter usually starts with working out what is actually in use, what can go, and what not to touch until you know why it is there.
The hard part of WordPress
WordPress is easy to extend. That is also the problem. A plugin solves today's task quickly, but after a few years the result can be a system nobody dares update, because nobody knows any more what depends on what. So I try to keep the installation as simple as the job allows – and make sure the code, the content and the integrations can be maintained by whoever takes over next.
On plugins
Every plugin is code somebody has to maintain. I use them when they solve a real problem, and write the rest myself where it does not need another dependency. Fewer moving parts usually makes maintenance, performance and security easier to keep on top of.
Process and pricing
A new build or a well-defined theme can be quoted at a fixed price once the scope is known. An inherited installation always starts on hourly billing – there is no way to know how much work it needs before you have seen what is actually underneath.
Ongoing maintenance, updates and fixes are billed hourly, the same way as the rest of the collaboration – most WordPress and CMS clients are recurring, rather than one-off jobs.
Websites that load quickly – including on a phone on a poor connection.
The work starts with a measurement, not a guess. Otherwise you risk optimising what is easy to measure rather than what is actually making the site slow.
What it usually covers
Core Web Vitals, image formats and delivery, caching at several layers, database queries, and the amount of JavaScript and CSS the browser has to fetch and run. The SEO side is mainly about the technical part: structured data, canonicals, hreflang, redirects and indexing. The aim is to make it easy for search engines to understand, find and index the content.
What I measure against
Field data over lab numbers, when there is enough traffic for it. Lighthouse is a diagnosis, not a grade. The goal is not 100 in Lighthouse. The goal is a fast website that works well for users.
Process and pricing
A performance review – measurement, diagnosis and a prioritised list of what actually moves the needle – can be quoted at a fixed price, since the work is well scoped. The implementation itself depends on what the measurement shows, and is typically billed hourly.
Follow-up measurements and adjustments, as the site or the traffic changes, are handled on an ongoing basis, the same way as the rest of the collaboration.
For when a technical decision has to be made and you have nobody to test it against.
It might be a choice of technology and architecture, assessing a quote from an agency, or reviewing a codebase you have inherited.
Sometimes the job is to find the right solution. Other times it is to work out whether the solution already on the table is the right one.
What it usually covers
Code review with a written assessment, estimation and risk assessment of projects, technical due diligence ahead of an acquisition, and sparring with in-house teams that need an experienced, independent view of their technical choices.
What I draw on
I have been coding professionally since 1998 and was CTO and co-founder of a digital platform where technical decisions also had to hold up to operations, finances and audit. I have seen the consequences of the choices I advise on – including the wrong ones I made myself. That means my advice does not rest only on what ought to work. It rests on experience of what happens when solutions have to hold up in the real world.
Process and pricing
Consulting is billed hourly – it is hard to put a fixed price on an assessment whose conclusion you do not know in advance. A well-defined deliverable, such as a written code review with a fixed deadline, can be agreed at a fixed price once the scope is known.
Follow-up questions and further sparring, once the decision is made and implementation begins, are handled on an ongoing basis, the same way as the rest of the collaboration.
We use cookies and similar technologies to ensure website functionality, play embedded Vimeo videos and generate anonymised statistics through Google Analytics. You can read more about how we use cookies and similar technologies, and how we process your personal data, in our cookie policy.
If you have any questions about our processing of data or your rights, you are always welcome to contact us. os.
Collects statistics about the use of the website so we can improve content and user experience.
Expiry
Up to 24 months
What is a cookie?
A cookie is a small text file stored on your computer, tablet or mobile phone when you visit a website. Cookies are widely used to make websites work, improve the user experience and provide the website owner with information about how the site is used. A cookie is not a program and cannot contain viruses or other harmful code.
How this website uses cookies
We use cookies to ensure that the website works correctly and to improve your user experience. Cookies may, among other things, be used to remember your choices, such as language settings, consent choices and technical preferences.
In addition, we use statistical cookies to analyse how the website is used, so we can optimise functionality, structure and content.
You can see a detailed overview of the cookies we use, including purpose and expiry, under the categories: Necessary, Functional and Statistics.
How long are cookies stored?
How long a cookie is stored on your device depends on the individual cookie. Some cookies are automatically deleted when you close your browser (session cookies), while others are stored for a longer period.
The lifetime of each cookie is shown in our cookie overview. The storage period is calculated from your most recent visit to the website.
How to reject or delete cookies
You can change or withdraw your consent at any time using the cookie icon at the bottom of the website.
You can also block or delete cookies through your browser settings. Please note, however, that if you reject necessary cookies, certain website functions may not work correctly.
