18) Vipps: Fra app til verb til nordisk infrastruktur
Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · podcast · 2026-06-01 source ↗ Reader 🖥️
mixed — primarily practical (engineering/leadership lessons from a decade of platform evolution) but with theoretical undertones about how shared national infrastructure gets built, scaled and governed · narrative-expository — chronologically structured technical/organizational case history told in dialogue, with the guests reconstructing a ten-year arc from internal DNB project to Nordic platform — Two Vipps insiders (Kristian Skjønberg-Løvik, Head of Strategy and Architecture; Alf Thomas Nilsen, Head of Apps) are interviewed by the Heis hosts. Kristian carries the long-arc strategy/architecture narrative (he's been there since the project's beginning inside DNB). Alf Thomas joined ~2019 from FINN/Schibsted and carries the app-platform and engineering-organisation narrative. Hosts probe with short questions; guests answer at length.
Structure
| Part | Role |
|---|---|
| Origins inside DNB (2014–2017): the P2P app as an exception to the IT freeze | Origin narrative — establishes Vipps as a fast-track strategic project carved out of a frozen, tollgate-bound DNB IT organisation, racing MobilePay to market on an IBM WebSphere monolith in a Copenhagen datacenter, built partly with TCS as a brand-new outsourcing partner |
| From DNB project to standalone company (2017–2018): MCash merger, carve-out, and Azure migration | First inflection — MCash fusion turns Vipps into a joint Norwegian bank vehicle (orange replaces DNB green), an independent tech organisation is built from one DNB person plus eight from MCash, and Vipps becomes DNB's first regulated public-cloud workload, going onto Azure largely because Microsoft could deliver the compliance paperwork fastest |
| Maturation as a Norwegian platform (2018–2023): app rewrite, services, weekly releases, daytime deploys | Engineering-culture chapter — the monolith is decomposed into 'service-oriented (call it microservices if you want)' components, the app is rewritten from scratch in 2018 along with the orange rebrand, weekly fixed-cadence app releases replace ad-hoc cycles, and a deliberate culture shift moves all deploys from night to daytime with everyone on the job |
| The MobilePay merger (2023–2024): the big-bang cut-over | Climax narrative — two large companies doing the same thing in different markets merge; a long pre-approval wait keeps teams legally apart; a 36-month plan is compressed to 12; scope is cut hard, MobilePay API traffic is fronted by façades onto the Vipps platform, and Finland and Denmark are cut over in dramatic nighttime big-bangs (with everyone awake and cake on the table) |
| Post-merger present (2024–2026): tap-to-pay, AI, sovereignty, and what's next | Forward-looking close — Tap to Pay becomes the second major product success (after netthandel), the EU regulatory win against Apple is reframed as critical infrastructure leverage, AI tooling moves fast in code generation but lags in operations, and the conversation turns to European payments sovereignty and the fragility of trans-Atlantic cables |
Key terms
- verb-status / 'å vipse'
The condition where a product name has displaced the generic category verb in everyday Norwegian (and partly Danish for 'mobilepay'). Treated as both a marketing achievement and a strategic liability — it raises the bar on availability, scams sensitivity and brand neutrality across markets. - nordisk infrastruktur
The current self-conception: Vipps is no longer a Norwegian app or even a Nordic product family, but a piece of cross-border payments infrastructure spanning Norway, Denmark and Finland, integrated to BankAxept locally and to international card schemes globally, and increasingly framed as part of European payment sovereignty. - fast track
The DNB-internal carve-out that let the original Vipps project bypass the bank's tollgate-based IT governance — a deliberate organisational hack that depended on top-management sponsorship (Rune Bjerke) and an external threat (MobilePay) to legitimise the exception. - carve-out
The technical and organisational separation of the Vipps platform out of DNB and into Vipps AS — described as the decisive structural advantage that made Vipps's platform (rather than MobilePay's, which was 'more integrated into Danish banks' private cloud') the chosen survivor of the 2023 merger. - big bang (cut-over)
A planned, dated, all-at-once switch — explicitly named as the correct shape for integration projects where 'you know where you are going', as opposed to product development where you don't. The Finland and Denmark cut-overs are recounted as the most magical, team-uniting engineering events of the speakers' careers. - fasade (façade)
An API translation layer placed in front of MobilePay's legacy integration endpoints so that thousands of merchant integrators could keep calling their old APIs while traffic was rerouted to the Vipps platform underneath. Crucial pillar of the big-bang because it decoupled the platform cut-over from the integrator-migration timeline. - fokus-flex
A planning rhythm Vipps adopted in the pre-MobilePay-merger period: focused build weeks alternating with shorter synchronisation/dependency weeks. Mentioned as an attribution to Oda (the grocery delivery company). - deploys på dagtid / 'alle på jobb' Trunk-Based & Continuous Delivery
An explicit cultural shift away from night deploys to daytime deploys with all responsible engineers present — framed as both a safety practice (smaller changes, designed to be safe) and a forcing function (you can't ship risky things in-hours, so you redesign your system until you can). - samfunnskritisk / 'det kan bare ikke gå ned'
Implicit but pervasive: the recognition that Vipps is now a piece of national life and any downtime echoes in TV-aksjonen, 17. mai, public transit ticketing, the local loppmarked. This recognition is described as the lever that bought every subsequent investment in robustness, isolated payment flows, and the in-hours deploy culture. - presence of mind
Used (in English, by the guests) as the strategic objective behind tap-to-pay: making sure Vipps is available in every payment situation, not just where it dominates, so that it stays the user's first-reach option even where it isn't economically optimal. - humanize ser på koden Pull Requests & Async Code Review
A Whisper-mangled but extractable concept: the regulator-mandated practice that humans (mennesker) review code going to production. Vipps's AI-coding agenda is partly the open question of whether 'four eyes' remain the right safeguard or whether AI review can substitute and, perhaps, surpass it.
Propositions
- explicitVipps exists because of a specific 2014 timing: DNB was in an IT freeze, MobilePay was about to enter Norway, and CEO Rune Bjerke chose to race rather than join MobilePay's family.conf: high
- implicitBecoming a separate company (carved out of DNB) was the decisive structural choice — without it, neither the Azure migration nor later mergers could have happened on Vipps's terms.conf: high
- explicitThe cloud choice (Azure) was driven by regulatory paperwork readiness, not technical fit — Microsoft could deliver finance-sector compliance documents fast enough; the platform deep-dive was secondary.conf: high
- explicitVipps has never run a top-down architecture project — every architectural change in ten years has been triggered by a concrete product or integration need.conf: high
- explicitIntegration projects and product projects require different methodologies: integration is big-bang (you know where you are going); product is iterative (you don't).conf: high
- explicitOnce Vipps was recognised as critical national infrastructure, in-hours deploys with everyone on the job became not only safer but a forcing function: engineers redesign their systems until risky changes can be made safely during the day.conf: high
- explicitWeekly fixed-cadence app releases broke a death-spiral where rushed last-minute features destabilised releases, which made product managers more aggressive about getting features in, which destabilised the next release.conf: high
- explicitiOS and Android app codebases at Vipps share essentially nothing — not even shared low-level libraries — because past attempts to share have not been worth the cost, and AI tooling makes language differences increasingly cheap.conf: high
- explicitVipps consciously moved from a 'one bug, fix everywhere' app architecture (side-effects as a growth hack) to a 'copy and let things diverge slightly' architecture as the developer count grew beyond the can-know-everything threshold.conf: high
- explicitThe merger with MobilePay was the largest single decision-and-execution challenge in Vipps's history, both because of pre-approval communication restrictions and because Vipps was suddenly doubled in headcount doing the same work in different markets.conf: high
- explicitSuccessful integration cut-overs depend on willingness to ship a temporarily worse user experience for one side's customers, in exchange for a single platform to build on afterwards.conf: high
- explicitcorroboratedFaçades over legacy MobilePay APIs were the structural pillar that made the platform big-bang feasible: they decoupled the platform migration from the multi-year merchant-integrator migration.conf: highsupports ←The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices · p7 — Both use an API façade/gateway as the seam that decouples client-visible contracts from the underlying platform migration, letting the migration proceed without client-side changes.
- implicitBig-bang cut-over is a uniquely team-uniting engineering event in an era of small continuous changes — it restored a kind of shared release ritual the speakers say they had lost.conf: high
- explicitTap to Pay raised Vipps's reliability bar permanently: in-store payment must work the first time, because the alternative (Apple Pay) is one swipe away and the user will not retry Vipps.conf: high
- explicitVipps's EU regulatory campaign to open Apple's NFC stack was won partly because Apple themselves cited QR-code workarounds — including Vipps's failed 'Vipps i terminal' product — as evidence of alternatives, which became 'one of the key proofs' that the NFC monopoly had to be broken.conf: high
- explicitAI coding-tool adoption at Vipps is much further along on code generation than on production operations and monitoring, but the operational side is starting to catch up via OpenTelemetry-querying agents and screenshot-fed incident analysis.conf: high
- explicitCode-writing speed was never Vipps's bottleneck; AI coding tools make this more obvious, not less, so the real productivity question is the rest of the engineering value stream.conf: high
- explicitEuropean payments sovereignty — a Europe-wide card scheme not dependent on the international (American) card schemes — is becoming a natural strategic frame for Vipps's next decade, alongside cross-border P2P.conf: medium
- explicitComfort wins over principle for almost all users, so building sovereign European infrastructure as a competitor to deeply convenient US-controlled rails is structurally uphill.conf: high
- implicitMonopoly position lets Vipps tolerate temporary brand and UX dips (e.g., the forced Danish app upgrade at MobilePay cut-over) that a contested-market player could not survive.conf: medium
Arguments
- MobilePay's platform was more integrated into Danish banks' private cloud and not yet structurally independent
- Vipps's platform was already 'ferdig carved ut' (cleanly separated) and running in public cloud
- The chosen platform had to be the one that could absorb new markets quickly
- Organisational separability is a stronger architectural property than codebase quality in M&A
- Speed of integration after merger close was the dominant constraint, not eventual technical excellence
- Norwegian/Nordic tech companies entering Europe should optimise for organisational carve-out first, technical excellence second
- MCash veterans saying their tech was 'objectively better' could both be right and irrelevant — wrong axis of merit
- Product development requires iteration because you don't know where you're going
- Integration projects are different — you know the destination (one common platform)
- Iterative migration would have extended the 'parallel platforms' phase indefinitely and drained the company
- The actual cut-overs went well, the team experience was uniquely positive, and post-merger the company is now financially in the black
- Methodological pluralism is necessary inside one company — different work types call for different process shapes
- The post-cut-over story of leadership wanting to 'do everything this way' was a category error worth naming
- Engineering leaders should explicitly distinguish 'integration / migration work' from 'product discovery work' in their planning vocabulary
- A team that has never done a big-bang cut-over may be missing a tool, not just a risky habit
- Night deploys to 'hide risk' encode the assumption that changes are unsafe
- Forcing in-hours deploys forces engineers to design changes that are safe enough to do in-hours
- Once the system supports safe in-hours changes, nobody wants to go back
- Cultural and technical constraints co-evolve — changing one forces the other
- Reliability work is rarely budgeted; it has to be smuggled in via a non-negotiable practice
- Other critical infrastructure operators may be holding back robustness by tolerating night deploys
- The 'in-hours deploy' practice is a cheap test for whether an org has actually internalised modern reliability culture
- Apple's EU defence relied on showing alternative in-store payment paths existed
- Vipps i terminal was one such alternative
- The EU regulatory victory opened the door to Tap to Pay, which then became Vipps's second-largest product success after netthandel
- Failed products can produce strategic optionality far beyond their commercial value
- Building things 'so that we can prove they aren't enough' is a legitimate, if unstated, reason to ship
- Norwegian fintech competing with platform owners should treat failed-but-published products as exhibits in future regulatory cases
- There is an underexplored strategy of 'shipping bad alternatives so the good one can be regulated open'
- International card schemes are American and irreplaceable for cross-border in-store payments
- BankAxept solves Norwegian-domestic cost but doesn't work abroad
- The geopolitical climate is forcing payments-dependency conversations to surface
- Vipps's MobilePay-era plumbing already crosses three Nordic countries and is therefore the closest existing seed for a European answer
- Sovereignty conversations create regulatory tailwinds — like the Apple NFC case — that Vipps is uniquely positioned to harvest
- European fintech consolidation may be steered by sovereignty narratives more than by pure product/market fit
- Vipps's verb-status across Nordic languages may be a soft-power asset in that consolidation
Narratives
- Rune Bjerke and the MobilePay invitation: instead of joining MobilePay's family, the DNB CEO launches an internal counter-project on a fast track around the bank's tollgate IT governance, while the rest of DNB's IT is frozen for a datacenter consolidation into Green Mountain.
→ Frames Vipps's origin as a strategic refusal of foreign infrastructure — establishes the 'national-platform-as-deliberate-choice' theme that returns at the end with EU sovereignty - The Copenhagen IBM WebSphere monolith: a launch architecture set up in a Danish datacenter because DNB's own facilities were frozen, sized down as much as IBM would allow because nobody knew if Vipps would survive, and 'kraglet med den leverandøren for å skalere det minst mulig'.
→ Concretises 'constraint-driven architecture' — the founding monolith was the smallest thing IBM would sell, in the only datacenter available - Growth-hack SMS: early Vipps sent 'click here to receive money' SMS to non-users, which 'wouldn't fly today' due to scams/phishing concerns but kickstarted the hockey-stick adoption.
→ Shows how regulatory/security maturity has closed off the very techniques that built the platform's user base — implicit comment on how 'samfunnskritisk' status changes what you're allowed to do - 17. mai and TV-aksjonen as load-test events: school brass band loppmarked donations and NRK telethon five-minute donation stunts that 'utfordrer oss med trafikkbønstre' — the speakers' personal trauma of going down during a son's korps fundraiser is treated as the turning point that made robustness non-negotiable.
→ Grounds the 'samfunnskritisk' frame in concrete moments — these are the events where a fintech becomes infrastructure - The Vipps i terminal QR experiment (2021): a product that required the right bank, the right terminal software, and that the cashier press '5' on the terminal to summon the QR code — visibly confusing to baristas, used by under 1% of users, killed after a year — that then surfaces years later as the cornerstone of Apple's failed EU defence.
→ Supports the argument that failed products can be strategically priceless; also a wry self-deprecating set-piece — 'jeg har aldri brukt det' / 'du brukt det da' - The pre-approval limbo with MobilePay: months of 'lawyers in every room', a year of working on internal Vipps features (mobile abonnement, Vipps SIM-kort) that never shipped, racing to get pre-merger product debt out the door, and then the moment approval lands — MobilePay's exhausted engineers banking on the door demanding documentation Vipps doesn't have, while Vipps is mid-fokus-flex cycle and asks them to 'wait three weeks'.
→ Vivid texture for the methodological argument about integration projects — also a portrait of organisational tempo mismatch between two large engineering organisations forced into sudden cohabitation - The Finland and Denmark cut-overs: nighttime big-bang releases with shift rotations, cake, 'team spirit through the whole night', explicitly recalled as the most magical engineering events in years and as something the small-frequent-change era had eroded.
→ Emotional anchor of the methodological argument — the speakers are not just intellectually defending big-bang, they miss it - The Danish forced app upgrade: instead of an automatic upgrade, all Danish MobilePay users had to install a new app from the App Store the morning of cut-over, with marketing/comms teams building a narrative around it, customer satisfaction dipping visibly, and the brand recovering 'fordi det er fint å være monopol'.
→ Concrete case for the implicit-monopoly proposition — what brand damage you can survive is a function of market structure - The Anders Sveen / OpenTelemetry-via-AI demo: a Vipps engineer touring talks on how AI reading OpenTelemetry data can produce hypotheses about what a code change actually did in production, transferring formerly-human know-how into automatable feedback loops.
→ Concretises the argument that AI's bigger payoff is in operations, not code production — and ties back to the daytime-deploy culture (you can only let AI participate in operations if you've already made operations observable in-hours) - The trans-Atlantic cable thought experiment: 'hva hvis man fjernet alle kablene som går over Atlanterhavet?' — followed by a self-deprecating digression about whether the cables are buried, under the seabed, or over the sea, that the speakers use to land the sovereignty point with humour.
→ Closes the strategic frame — payments sovereignty is concrete infrastructure dependency, not abstract policy
Questions addressed
- ✅ How does an internal bank project become national infrastructure?
Through a sequence of structural choices: carve-out into a joint-bank vehicle (MCash 2017), independent company with its own tech organisation, regulator-acceptable public cloud (Azure), and progressively cross-bank ownership — each step expanded both the obligation and the political legitimacy to be infrastructure. - ✅ When is big-bang the right release strategy?
When the work is integration/migration rather than product discovery — i.e., when the destination is known, not unknown. The 2023–2024 Finland/Denmark cut-overs are offered as proof. - ✅ How do you keep critical infrastructure available while changing it constantly?
Weekly fixed-cadence app releases, all deploys in-hours with engineers present, backward-compatible API versioning with parallel endpoints, kill-switch and per-endpoint forced-upgrade as soft guardrails, and explicit isolation of the most critical flows (tap-to-pay) from the rest of the platform. - ⭕ What does AI change about a regulated fintech's engineering practice?
Open question — the speakers explicitly say they 'have not concluded' on whether four-eyes human code review remains the right safeguard or whether AI review can substitute. Bigger payoff seen in operations than in code production. - ⭕ Should Vipps see itself as Nordic or European?
Gestured at but not committed to. Speakers acknowledge a European card-scheme sovereignty conversation is becoming natural, but stop short of declaring Vipps's role in it ('Nei, den svære den da.' — explicitly deflected). - ✅ How should an engineering organisation handle the coexistence of two tech stacks (Go and .NET) after a merger?
Don't. The conscious decision was to keep both stacks and let AI tooling absorb the language-difference cost over time; the speakers half-jokingly note that this is the kind of choice strategy people who 'don't think about programming language' make at the M&A level.
Gaps
- incompleteVendor positioning is conspicuous: the story is told entirely from the survivors' chair. MobilePay engineers are quoted only as having insisted their tech was 'objectively better', MCash veterans get one similar line, and no failures are attributed to Vipps leadership specifically. The MCash 2017 carve-out is treated as smoothly inevitable; the operational chaos is named ('brannslukningsarbeid') but never traced to a decision.
Read next: MobilePay engineering blog posts from 2023–2024; the Danish fintech press's coverage of the merger; Kristian Pinsel Halvorsen interviews (his name is dropped as the host's 'old boss' from FINN, suggesting a counter-perspective on big-bang migrations in Schibsted/FINN territory) - incompleteThe role of DNB through the entire history is underexamined. Vipps was DNB's first public-cloud workload, DNB's CEO drove the founding, MCash brought the other Norwegian banks in, and yet the bank-shareholder governance — including how decisions like 'use Vipps's platform, not MobilePay's' actually get taken — is essentially a black box.
Read next: Norwegian financial press on Vipps AS ownership changes; Rune Bjerke's memoir/interviews; the prior Heis episode with Kari Olrud Moen (ep 15, 'strategi tydelig og skråsikker') — Moen is Vipps's CEO context - incompleteTap to Pay is celebrated as a success, but the speakers stop short of explaining what economic margin Vipps captures from international card schemes vs. domestic BankAxept on in-store transactions. Given that the entire European sovereignty argument hinges on dependency on American card schemes, the cost/risk picture matters strategically.
Read next: Norwegian card-scheme regulator (Finanstilsynet) cost analyses; EU Digital Markets Act / Payment Services Directive 3 documentation; ECB reports on European payments sovereignty - incompleteThe 'verb-status' achievement is mentioned but not problematised. Mobilepay is also a verb in Danish; both verbs are now inside one company. What happens to brand neutrality and to user expectations when a Norwegian verb is owned by a Nordic company that wants to be European? The speakers laugh it off ('det tror jeg ikke vi skal prøve å spørre' about Finnish usage).
Read next: Sociolinguistics of brand-verb status; comparable post-merger brand consolidations in payments (Klarna, Wise); MobilePay marketing material from the merger announcement - incompleteAI in regulated production code is left as an open problem. The 'humanize ser på koden' (humans review code) regulatory expectation is named, but the speakers don't engage with how Norwegian Finanstilsynet, the EU AI Act, or DORA-style governance frameworks will actually treat AI-generated code in financial production.
Read next: Finanstilsynet guidance on AI in financial services; EU AI Act high-risk system requirements for payments; DORA 2025 findings on AI-assisted development in regulated industries - incompleteArchitecture is described as never planned ('aldri hatt et stort arkitekturprosjekt') but the result is a mature multi-cloud, multi-region, regulated platform with 35 product teams and 170+ engineers. The gap between 'we never planned it' and 'we ended up here' is unexamined — what is the actual feedback mechanism that lets a no-architecture-project culture not drift into mush?
Read next: Cutler's writing on emergent architecture and operating-system design; Beck's Tidy First essays on iterative architecture; the prior Heis episode with Greger Teigre Wedel (ep 12, 'når sjefen har svaret') for a Norwegian counter-perspective on top-down architecture - incompleteThe speakers describe weekly releases and trunk-based-ish development for the app, but back-end deploy cadence and the cross-team coordination model when 35 product teams plus a payments backbone plus an AI platform team all ship at different speeds is not described in detail.
Read next: DORA 2024–2025 reports on deploy frequency and change-failure rate in financial services; NAV's 'fast flow' writeup that Kjetil has already saved (per persona)
Related documents
- Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers
- AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action
- Pair Programming Fixed Our Pull Request Bottlenecks
- Four Eyes Without Pull Requests
- Mob Programming – key issues it can solve, benefits, and learnings
- Software Engineering at Google
- Why your team doesn't need to use pull requests
- On Pair Programming
- Post-Commit Reviews != Post-Deployment Reviews