Bandits Inc.

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.

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

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.

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.

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 we had to declare Lifeguard 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.

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.

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.

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.

The days were long, but the culture was strong.

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.

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.

Curriculum Vitae ↓

Paul Nybo Andersen

Profile_

8 years with Lifeguard

My experiences

2024-2026, CTO & Co-founder

ESGRapporter

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

Revolvo

2015-2023, CTO & Co-founder

Lifeguard

2016-2018, CTO & Co-founder

Vitalityguard

2010-2015, Senior Digital Wizard

ContentCPH

2009-2010, Freelance developer

BOCCA WIRED

2008-2010, Inhouse Freelance developer

EuroRSCG

2001-2026, Sole proprietorship

My qualifications

Rating

Adobe

Adobe Firefly

Adobe Flash (EOL)

Alpine JS

Amazon AWS

Android Studio

Angular

Apache/ NGINX

App Store

Apple iWork

Apple Xcode

Axure RP

Bitbucket

Bootstrap

C#

ChatGPT

Claude

Composer

CSS/ CSS3

Data compliance (GDPR)

Digital Ocean

Docker

DPO

Drupal

Figma

Final Cut Pro

Forge

Foto (DSLR) + Billed behandling (RAW)

Gemini

Git

GitHub

GitHub Copilot

Google Ads

Google Analytics

Google Play Console

Google Search Console

Google Tag Manager

HTML/ HTML DOM/ HTML5

Hubspot

Illustrator

InDesign

Ionic

Jira

Joomla

jQuery

JSON

Laravel

LinkedIn Marketing Solution

Liquid (Ruby)

Lovable

Magento 2

Mailchimp

Meta Business Suite + Manager

Microsoft 365

Microsoft Azure

MySQL

.NET