Build vs Buy Is Dead. Swedish CTOs Still Paying for the Funeral.

The Question Itself Is the Problem

If you are a CTO in Stockholm, Gothenburg, or anywhere in the Nordics and you are still framing software decisions as "build vs buy software," you are asking the wrong question. And it is costing you. Not in some abstract strategic sense. In actual money, right now, this quarter.

I watch this from Jönköping. We at HEIMLANDR work with companies across Sweden and Europe. The pattern is consistent: a Swedish company commits to an 18-month custom SaaS development project, staffed at Western European rates that run 2x what you would pay for equivalent talent in parts of Asia or Eastern Europe. Somewhere around month nine, the underlying AI capabilities they are building around shift so fundamentally that half their architecture is already legacy. They ship. It works. And within a year the functionality is available as a composable service from Microsoft, Google, or a well-funded startup that did not exist when the project started.

This is not a hypothetical. This is Tuesday.

Apple Just Showed You What Replaces It

InformationWeek is reporting today on how Apple's AI strategy reveals a hybrid model that obliterates traditional build-vs-buy logic. Apple is not building its own foundation models from scratch for everything. It is not buying off-the-shelf solutions either. It is composing. It takes capabilities from multiple sources, wraps them in its own integration and experience layer, and ships something that feels native. The foundation model might be partly internal, partly partnered. The on-device inference is custom silicon. The orchestration layer is proprietary. The data governance is baked in.

This is what I call the compose pattern. You do not build. You do not buy. You compose disposable scaffolding around AI capabilities that you neither own nor rent in the traditional sense. You treat software as temporary structure. The AI capability underneath is what matters. The code around it is meant to be replaced.

If Apple, a company with effectively unlimited engineering resources, has decided that pure build is stupid, why is your 200-person SaaS company in Linköping still doing it?

The Swedish Custom Dev Trap

Sweden has a cultural relationship with quality software development. It is deep. We build things properly here. We architect them. We test them. We take pride in clean code and solid infrastructure. I respect this. I share this instinct.

But this instinct is now working against us.

The Swedish market's traditional preference for high-quality custom development is colliding with a reality where Google and Microsoft are making the "buy" layer so AI-native that custom-built alternatives depreciate before they ship. EQT and Google are actively accelerating AI adoption for Nordic businesses. The infrastructure layer is being commoditized faster than any software development company in Sweden can write code against it.

Here is the math that nobody wants to do. A senior fullstack developer in Stockholm bills at 1200-1500 SEK per hour. A comparable developer in Lisbon or Kraków bills at 600-800 SEK. A team of five in Stockholm running for 12 months on a custom SaaS development project costs you roughly 10-12 million SEK. That same project, if approached as a compose problem, using AI-native services as the core and building only the integration and experience layer, might cost 3-4 million and ship in four months.

The gap is not just cost. It is time. And in 2026, time is the only resource that matters, because the capabilities available to you in September will be meaningfully different from what is available today.

What Swedish Companies Get Right

Data governance. Privacy. Security thinking. These are genuine strengths. When VentureBeat flags that enterprise governance is years behind AI adoption speed, they are describing most of the US market. Swedish companies, shaped by GDPR and now the EU AI Act, actually have muscle memory for thinking about data flows and compliance. This matters. It is a competitive advantage. But only if you stop using it as an excuse to build everything from scratch "because we need control."

You do not need to build the model. You need to govern the data that flows through it. Those are very different problems requiring very different investments.

Software Development in Sweden Needs a New Mental Model

Let me be specific about what the compose pattern looks like in practice, because I am tired of strategy talk that never gets concrete.

Say you need an internal tool that processes customer support tickets, categorizes them, routes them to the right team, and drafts initial responses. Old build-vs-buy thinking says: "Do we build a custom NLP pipeline, or do we buy Zendesk?" The compose answer is neither. You take a foundation model API. You build an AI agent layer that handles the orchestration. You connect it to your existing ticketing system via API. You build a thin UI, maybe using something like Streamlit, that gives your team visibility and override capability. Total build time: weeks, not months. Total custom code: minimal. Total cost: a fraction of either the build or buy alternative.

The key shift is that the custom code you write is explicitly disposable. You know it has a shelf life. You design for replacement. When the model capabilities improve in six months, you swap the core and keep the integration layer. When a better orchestration framework appears, you migrate. The scaffolding is cheap because you expected to tear it down.

This is how we think about MVP development at HEIMLANDR now. Not "what is the minimum viable product" but "what is the minimum viable composition that lets us test this idea before the underlying capabilities shift again."

The Compliance Cost Nobody Is Counting

Here is where it gets really uncomfortable for Swedish CTOs who want to build. The EU AI Act is not a future problem. It is a current one. And the compliance overhead for custom AI systems is significantly higher than for using established, pre-audited AI services from major providers.

If you build a custom ML pipeline for anything classified as high-risk under the Act, you are on the hook for conformity assessments, technical documentation, human oversight mechanisms, transparency requirements, and ongoing monitoring. If you compose using a service from a provider that has already done that compliance work, your regulatory burden drops dramatically.

This is not an argument for blindly trusting big tech providers. It is an argument for being honest about total cost. When a Swedish company tells me their custom build costs 8 million SEK, I ask: "Did you include the 2-3 million in compliance work that the EU AI Act requires for that classification level?" The answer is almost always no.

Swedish regulators at Integritetsskyddsmyndigheten (IMY) are doing their best, but the gap between regulatory ambition and practical guidance for companies is real. If you are building custom AI systems, you are navigating ambiguity with expensive lawyers. If you are composing with pre-compliant services, you are inheriting someone else's compliance investment. The economic choice is obvious.

Where This Goes: 2027-2030

Let me tell you what I think is coming and what builders should prepare for.

By 2028, the majority of custom business software written today will be functionally obsolete. Not because it stops working. Because the capabilities it took twelve months to build will be available as API calls that did not exist when the project started. The trajectory toward more capable AI systems, whether you call it AGI or just "better models," means the depreciation rate of custom software is accelerating. It is not linear. It is compounding.

The companies that win in this environment are not the ones with the best code. They are the ones with the best data, the best understanding of their domain, and the fastest ability to recompose their software layer when new capabilities appear. The code is the cheapest, most replaceable part of the stack. The data and the domain knowledge are the moat.

For Sweden specifically, this means the entire software development industry needs to pivot. The consulting model of billing hours for custom development is dying. Not dead yet. But the trajectory is clear. The value shifts to architecture, integration design, data strategy, and compliance engineering. The actual code writing becomes something you do with AI assistance in a fraction of the time, or something you do not do at all because a composable service already exists.

I think within three years, a serious SaaS development company will spend more time on data architecture and AI orchestration than on writing application code. That is where we are heading at HEIMLANDR. That is where the market is going.

What to Look At

If you are a CTO or technical founder rethinking your build-vs-buy (or rather, compose) strategy, here are things worth your attention right now:

OpenHands (77k+ stars on GitHub). AI-driven development that lets you build the scaffolding layer faster. This is the kind of tool that makes disposable code actually practical. You can spin up integration layers quickly, test them, and throw them away when the underlying capabilities change.

Daytona (72k+ stars). Secure, elastic infrastructure for running AI-generated code. When your software is disposable scaffolding, the infrastructure it runs on needs to be just as flexible. Daytona gets this right.

rtk (62k+ stars). A CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies. When you are composing rapidly and iterating with AI tools daily, token costs add up fast. This is a practical tool that addresses a real cost center.

VentureBeat's ongoing coverage of the AI governance gap. Required reading for anyone trying to understand why "just build it" costs more than the sticker price in an EU AI Act world.

Stop Asking Build or Buy

The question is not build or buy. The question is: what is the thinnest possible layer of custom work that lets me deliver value to my customers while staying flexible enough to recompose when the ground shifts again in six months?

If you are a Swedish company paying premium rates for 18-month custom development projects, I am not saying fire your developers. I am saying redirect them. Point them at data problems, integration architecture, AI orchestration, compliance frameworks. Let the AI tools write the scaffolding code. Let the composable services handle the commodity functionality. Put your expensive, talented Swedish engineers on the problems that actually require human judgment and domain expertise.

The build-vs-buy binary is dead. The companies that figure this out first will eat the ones that do not. From where I sit in Jönköping, watching both the Swedish market and the global one, I can tell you: the window for figuring this out is not years. It is months.

Build things that matter. Compose everything else. And for the love of god, stop starting 18-month projects in a world that reinvents itself every quarter.

Fredrik Brunnberg is the CEO of HEIMLANDR.IO, building AI and software solutions from Jönköping, Sweden. This is the daily HEIMLANDR briefing. If you found this valuable, share it with someone who builds things.