Contact
Available for consulting, development, digital products and technical leadership.
Available for consulting, development, digital products and technical leadership.
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.
Scroll to read more →
Robust web solutions in PHP, JavaScript and modern technologies.
User-centred design focused on experience, function and conversion.
Visual identities and design work focused on clarity and usability.
Tailored solutions in WordPress and other content systems – easy to maintain.
Technical sparring and digital strategy that produces value and results.
Faster websites, better SEO and tuned performance across devices.
Case: Lifeguard Health ApS_
CTO & Co-Founder
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.
Lifeguard presentation_1_4_
Employment_history_
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.
Experiences_
Now: ESGRapporter ApS.
We built the ESG reporting platform in Laravel, and I carried the technical responsibility for the direction, the reporting side and everyth ..
Now: Revolvo Aps. + BmyGuest ApS.
I handled development, UI/UX and graphic identity. 60% of my time went to BmyGuest and IDoMeetings, which Revolvo co-owned.
Now: Lifeguard Health ApS.
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 desi ..
Now: FIDIMI
We ran the Lifeguard platform white-labelled through a joint venture with Dansk Sundhedssikring. Maersk was the biggest client.
Now: Charlie Tango
I built 60+ Facebook apps in PHP for Samsung, IKEA and H&M. The Nik & Jay campaign for Samsung won Danish Internet Awards 2014.
Now: BOCCA
I built campaign sites for Movia and the Danish Heart Foundation, among them Overraskende hurtig, which took bronze at the Creative Circle A ..
Now: Havas Danmark
I won the agency's digital work back from the competitors and built an iPhone site and interactive product tools for GN/Jabra.
Now: Audiotracking v/Paul Nybo Andersen
My own sole proprietorship since 2001. Through it I have sold web development to agencies that had the graphics but lacked the developer.
Skills + Stack_
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.
- " 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".
Writing_
AI will never be worse than it is right now. That does not change what I know – it changes where in the work I stand.
A language is learnable. It is the domain and the codebase that take time – and two machines that cost more attention than the syntax.
When I'm not working_
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.
TT38 profil
Period: 2024-2026
Link: app.esgrapporter.dk
Now: ESGRapporter ApS.
CTO & Co-founder
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 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 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.
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.
Period: 2024-2026
Link: www.revolvo.dk
Now: Revolvo Aps. + BmyGuest ApS.
Senior Developer • UI/UX • Design
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Period: 2015-2023
Now: Lifeguard Health ApS.
CTO & Co-founder
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.
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.
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.
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 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.
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.
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.
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.
LifeGuard was far more than training; we also offered sleep and stress guidance with podcasts, videos, exercises, and coach dialog. At our peak, we had more than 25 employees – the Facebook page still stands as an archive of what we built. We had financial backing from the Growth Foundation and several investors, and were a part of the entrepreneurial environment of Health Tech Hub Copenhagen.
It was covid that broke the business. The market shut, and converting customers became close to impossible: budgets were uncertain, appetite for investment had gone, and the HR departments we sold to were busy holding together an organisation that had suddenly gone home. We had stretches of four to five months with no sales worth the name.
And when companies came back, they were somewhere else. Working from home had become normal, budgets had been rewritten, and wellbeing was something you discussed on Teams rather than something you invested in.
We kept it running for three years after the lockdown but never found our way back to growth. In December 2023 we had to declare Lifeguard bankrupt.
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.
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.
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.
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.
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.
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.
Period: 2016-2018
Now: FIDIMI
CTO & Co-founder
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.
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 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.
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.
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.
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.
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.
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.
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.
Now: Charlie Tango
Senior Digital Wizard
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.
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.
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.
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.
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.
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.
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.
Now: BOCCA
Freelance developer
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.
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.
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 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 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.
The days were long, but the culture was strong.
Period: 2008-2010
Now: Havas Danmark
Inhouse Freelance developer
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.
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.
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.
Period: 2001-2026
Now: Audiotracking v/Paul Nybo Andersen
Sole proprietorship
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.
2026-05_
AI will never be worse than it is right now. That does not change what I know – it changes where in the work I stand.
A good friend and former business partner, Lars Nielsen, said to me recently: “AI will never be worse than it is right now.”
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.
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.
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. You need to recognise 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.
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.
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.
Lars Nielsen, who set the thought going, writes regularly about AI on LinkedIn.
2025-07_
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#.
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 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. My work sat mainly in the view layer.
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: it starts IIS Express, publishes the project to it, attaches the debugger and 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.
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 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. 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.
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.
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.
PHP • Laravel • MySQL • JavaScript_
Robust web solutions in PHP, JavaScript and modern technologies.
I build and maintain web solutions end to end – database, backend, frontend and the environment they run in. Most of it is PHP and Laravel with MySQL, and JavaScript on the frontend without a framework wherever a framework does not pay for itself.
Integrations against third-party APIs, payment flows, user administration, role management and the admin tools editors and support staff use daily. Often this is the work nobody sees from outside, but it decides whether the system can be operated at all.
I take over an existing codebase as often as I start a new one. The first step is understanding what has been built, and why – including when the documentation is missing. Then I fix what hurts now and lay out a plan for the rest.
UX • Figma • Prototypes • Testing_
User-centred design focused on experience, function and conversion.
Design of websites and user interfaces, starting from what the user needs to accomplish and what the business needs out of it. I work in Figma and deliver both prototypes and the finished design system.
Information architecture, wireframes, interactive prototypes and a component library that can be built from directly. I test on real users where there is an opportunity – it is usually cheaper than correcting afterwards.
The design becomes buildable. I know what is expensive to implement and what is free, 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.
Identity • Design systems • Print_
Visual identities and design work focused on clarity and usability.
Visual identity and graphic design for companies that need to look like something you can rely on. Logo, colours, typography and the guidelines that hold it together once people other than me start using it.
Identity programmes, design manuals, print, packaging, signage and presentation material. I work in Photoshop and Illustrator for image work and drawing, and in InDesign when the material has to be laid out for print – with the setup a printer can actually use.
An identity that exists only as a PDF falls apart the moment it has to be used on a website. I deliver it as a system of tokens and components, so the same identity holds in print, on screen and in the code.
WordPress • Umbraco • Magento_
Tailored solutions in WordPress and other content systems – easy to maintain.
Editorial systems the editors can actually work out how to use. Mostly WordPress, but also Umbraco and Magento, and in some cases a headless setup where the editorial side and the frontend are separated.
Themes built from scratch rather than bought, custom field types and blocks, migration from an old system, and clearing up installations where plugins have been allowed to grow unchecked.
Every plugin is code somebody else maintains – or does not. I use them where they solve a real problem, and write it myself where a plugin would drag in thirty times more than needed. That is usually where the security holes come from, too.
Architecture • Stack choice • Sparring_
Technical sparring and digital strategy that produces value and results.
Technical sparring for people who have a decision to make and nobody to test it against. Choice of stack, architecture, assessing a quote from an agency, or reviewing a codebase you have inherited.
Code review with a written assessment, estimation and risk assessment of a project, technical due diligence ahead of an acquisition, and sparring with an in-house team that lacks someone to try things out on.
I have been coding professionally since 1998 and was CTO and co-founder of a health platform where decisions also had to survive audit and operations. I have seen the consequences of the choices I advise on – including the wrong ones I made myself.
Core Web Vitals • SEO • Caching_
Faster websites, better SEO and tuned performance across devices.
Websites that load quickly, including on a phone on a poor connection. The work starts with a measurement, not a guess – otherwise you optimise what is easy to measure rather than what is slow.
Core Web Vitals, image delivery and formats, caching at several layers, database queries, the size of the JavaScript and CSS being shipped, and the technical side of SEO: structured data, canonicals, hreflang and indexing.
Field data over lab numbers wherever there is enough traffic for it. Lighthouse is a diagnosis, not a grade – a green number on a simulated connection does not necessarily say anything about what users experience.
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.
Service
Bandits Inc. Cookie Consent
Privacy policy
Name
BanditsincCookieConsent
Purpose
Stores and documents your cookie consent choices.
Expiry
Up to 12 months
Service
Vimeo
Privacy policy
Name
vuid
player
__cf_bm
Purpose
Used to play embedded Vimeo videos and ensure the functionality of the video player.
Expiry
Session to up to 24 months depending on the cookie
Service
Google Analytics 4
Privacy policy
Name
_ga
_ga_*
Purpose
Collects statistics about the use of the website so we can improve content and user experience.
Expiry
Up to 24 months
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.
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 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.
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.
If you specifically want to opt out of Google Analytics, you can do so here:
Opt out of Google Analytics
Cookies you have previously accepted can be deleted through your browser settings. The process depends on which browser and device you use.
You can change or withdraw your consent at any time by reopening the cookie settings using the link or icon at the bottom of the website.
If you have any questions about our use of cookies or processing of personal data, you are welcome to contact us at dpo@banditsinc.net.