Build vs Buy Is Dead. The Real Question Is Build vs Wait.

The $150/hr question nobody in Stockholm wants to ask

Right now, as I write this from Jönköping, Bridgepoint and Polaris are closing an acquisition of a Swedish software developer at a premium valuation. Penske just announced they are boosting custom software engineering through AI-augmented assembly with Capgemini. And Dagens industri is running profiles on Swedish AI companies "everyone is talking about."

Three signals. One conclusion that nobody in Swedish tech wants to say out loud: the build vs buy software debate is already obsolete, and most of the custom code being written in Sweden today will be disposable within 24 months.

I run a SaaS development company in Sweden. I have skin in this game. And I am telling you: if your entire strategy is still framed as "build vs buy," you are solving last year's problem with last decade's thinking.

The Swedish custom development religion

Sweden has a cultural relationship with custom SaaS development that borders on religious. We build things. It is part of the national identity. Spotify built its own everything. Klarna rebuilt its stack multiple times. The message filtered down: real companies build, everyone else buys.

The numbers reflect this. Swedish companies spend 2-4x the European average on custom builds. The logic is always the same: avoid vendor lock-in, maintain competitive advantage, own the IP. And for a decade, that logic was sound.

It is not sound anymore.

Here is what changed. Swedish dev shops charge $150/hr. Good ones. Worth it, historically. But AI copilots now do significant portions of what those developers do for roughly $0.02/hr in compute cost. Eastern European shops at $45/hr are adopting those same copilots fastest. Not next year. Right now. Today.

The premium you pay for software development in Sweden is increasingly a premium for human judgment, architecture decisions, and domain knowledge. The actual code production? That part of the value chain is collapsing.

Why "build vs buy" is the wrong frame entirely

The old framework assumes two options: build it yourself (expensive, slow, but you own it) or buy a SaaS product (fast, cheaper, but lock-in risk). Every CTO I talk to still frames decisions this way. It made sense when code was expensive to produce and cheap to maintain.

We are entering the inverse world. Code is becoming cheap to produce and the real cost is in maintenance, integration, and organizational complexity. When AGI-capable code generation arrives, and serious people now put that at 18 months out, not 18 years, the production cost of code approaches zero.

Think about what that means. You spend 18 months and 4 million SEK building a custom platform. Eighteen months later, an AI agent can regenerate something functionally equivalent in a weekend. Your "competitive advantage" was not the code. It was the understanding of what to build. The specification. The domain model. The integration architecture.

The winning move is not build OR buy. It is architecting for replaceability. Treat every software decision as a 24-month lease.

What "architecture for replaceability" actually looks like

This is not abstract philosophy. Here is what we practice at HEIMLANDR and what I recommend to every founder and CTO who asks.

1. Thin integration layers, fat domain models

Your domain knowledge, your business rules, your data models: those are the real IP. The code that implements them is a temporary expression. Invest in documenting and formalizing your domain model like it is the product. Because soon, it will be. The code around it will be regenerated, swapped out, replaced. The domain model endures.

2. Contract-first everything

Every service boundary gets a formal contract. OpenAPI specs. Event schemas. Strict interfaces. Not because it is "best practice" but because when you replace a service (and you will), the contract is what keeps the rest of the system running. This is what we build into every SaaS development engagement. The contracts outlast the code.

3. 24-month mental models

Before greenlighting any custom build, ask: "What happens when this can be regenerated by AI in 2028?" If the answer is "we wasted 4 million SEK," the architecture is wrong. If the answer is "we swap out the implementation and keep the integrations," you are building correctly.

4. MVP as a strategy, not just a phase

The Rapid MVP approach is no longer just for startups testing ideas. It is the correct posture for any software investment in 2026. Build the minimum. Validate. Expect to replace. Repeat. Permanent MVP mentality. Not because you are cheap. Because you are smart about where the world is heading.

Sweden vs the world: a honest comparison

From Jönköping, I watch three different realities play out simultaneously.

In the US, big tech companies are already treating internal tooling as disposable. Google, Meta, and Amazon have teams whose entire job is regenerating internal tools with AI agents. The build vs buy question is being replaced by "generate, test, deploy, discard." The speed is staggering.

In Eastern Europe and Southeast Asia, dev shops are not fighting AI. They are fusing with it. A team of five developers in Kraków with AI copilots is now outproducing a team of fifteen in Stockholm without them. Not in quality yet. But the quality gap is closing quarterly.

In Sweden, we are having a different conversation. Dagens industri spotlights Swedish AI companies, and Swedish dev shops still rank in top-10 European lists. There is genuine talent here. But there is also a dangerous complacency. The assumption that Swedish quality always justifies Swedish prices. It does. For now. For certain things. But the surface area where that is true is shrinking fast.

What Sweden gets right: deep engineering culture, strong domain expertise in fintech, medtech, greentech. High trust environments that make complex integrations work. These are real advantages that AI does not erase.

What Sweden gets wrong: treating custom code as a moat. It is not a moat. It is a sandcastle, and the tide of AI-generated code is coming in. The moat is your data, your domain knowledge, your customer relationships, and your ability to move fast when the tools change.

The Bridgepoint deal and what it signals

Bridgepoint acquiring a Swedish software developer at a premium valuation right now is fascinating. It might look like a vote of confidence in custom development. I read it differently.

Private equity buys at peaks. That is the business model. They see a market that is about to be transformed by AI, they buy in at peak revenue, they plan to restructure around AI-augmented delivery, and they exit to someone who does not see the shift coming. This is not cynicism. This is how PE works. The premium valuation signals peak custom-dev market. Not the beginning. The peak.

The Penske/Capgemini deal tells the real story. They are not building from scratch. They are doing AI-augmented assembly. Taking existing components, using AI to customize and integrate them, shipping faster. That is the enterprise direction. That is where this goes.

Where this goes: 2027-2030

I will be specific because vague futurism helps nobody.

By late 2027: AI agents can generate, test, and deploy full-stack applications from natural language specifications. Not perfectly. Not for every edge case. But for 70-80% of business software, the code generation will be good enough. OpenHands (github.com/OpenHands) already has 75,000+ stars and is pushing AI-driven development hard. This is not fringe. This is mainstream open source.

By 2028: The value of a software development company shifts entirely from code production to architecture, domain expertise, and AI orchestration. Companies that still sell hours of coding are dead. Companies that sell system design, AI agent configuration, and domain modeling thrive. This is exactly why we at HEIMLANDR are building our AI agents practice now, not later.

By 2029-2030: The path toward AGI means that even architecture decisions start getting automated. At that point, the human value is in asking the right questions, understanding business context, and making judgment calls that require real-world experience. The CTO's job becomes more important, not less. But it becomes a fundamentally different job.

The regulatory gap: EU regulators, including Sweden's, are not ready. The AI Act focuses on risk classification of AI systems. Nobody is thinking about what happens when the entire software supply chain is AI-generated. Who is liable when AI-written code fails in a medical device? In a financial system? In critical infrastructure? Swedish regulators need to start thinking about this now. They are not. I see zero indication from IMY or any Swedish authority that this is on their radar.

What to look at right now

If you are a founder, CTO, or senior engineer, here is what I would spend time on this week.

OpenHands (75K+ GitHub stars). AI-driven development that is pushing the boundary of what autonomous coding agents can do. If you have not tried pointing an agent at a real codebase and asking it to implement a feature, do it this week. The gap between what you expect and what it delivers will recalibrate your planning horizon.

Daytona (72K+ stars). Secure, elastic infrastructure specifically designed for running AI-generated code. The fact that this exists, and is this popular, tells you everything about where the industry assumes code production is going. Code becomes ephemeral. Infrastructure for running ephemeral code becomes essential.

rtk (57K+ stars). A CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies. Practical, fast, solves a real cost problem in AI-augmented development. This is the kind of tool that makes AI coding assistants economically viable at scale. Pay attention to the infrastructure layer around AI coding, not just the AI itself.

Hoppscotch (79K+ stars). Open-source API development ecosystem. In a world where you architect for replaceability, your API contracts are your real product. Tools like this, the open-source alternative to Postman, are how you formalize those contracts without adding another SaaS dependency.

The actual playbook

Stop asking "build or buy." Start asking these questions instead:

What is our domain model? Can we express it formally, independent of any implementation? If not, fix that first.

What are our integration contracts? If we replaced every internal service tomorrow, would the contracts be clear enough for an AI agent to rebuild the connections?

What is our 24-month assumption? For every piece of software we run, what do we assume will be true about AI capabilities in 24 months? Does our architecture survive that assumption?

Where is the human value? For every team member, is their primary value in producing code, or in understanding the domain and making judgment calls? Invest in the latter. The former is a depreciating asset.

This is not about fear. It is about timing.

I am not arguing that custom software development in Sweden is dead. I run a company that builds custom software. What I am arguing is that the mental model needs to change. Today. Not in 2028 when it becomes obvious to everyone.

The companies that win the next five years are not the ones who build the most software or buy the most SaaS. They are the ones who architect for a world where code is cheap and disposable, where the real asset is domain knowledge and integration design, and where every technical decision is made with a 24-month expiration date in mind.

From Jönköping, I can see this clearly. Maybe because we are far enough from the hype machines of San Francisco and Stockholm to think straight. Maybe because building things in a small Swedish city forces you to be pragmatic about where you spend your resources.

Either way, the build vs buy framework had a good run. It is time to retire it. Welcome to build vs wait. The answer, most of the time, is: build thin, build replaceable, and be ready to regenerate everything when the tools catch up to the vision.

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.