Build vs Buy Is Dead. Now It's Build vs Rent vs Own the Model

Somewhere in Stockholm right now, a CTO is signing a Salesforce renewal. Three years, price locked in with a nice 6% annual "market adjustment" clause, the kind that always goes up and never down. He thinks he's being prudent. He's actually agreeing to overpay for the next decade for something his own team could build in six weeks, better, and own outright. Nobody told him the math changed. I'm telling him now.

I've spent fifteen years in this industry, first as an engineer, now running HEIMLANDR out of Jönköping, and I've watched build vs buy get taught the same way in every business school case study since 2005. Buy is safe. Build is risky and expensive. Rent from a SaaS vendor, keep your team lean, focus on "core competency." That framework was correct when it was written. It is dead now. Not dying. Dead.

The Old Framework Assumed Software Was Expensive

Every build vs buy software decision tree you've ever seen has the same hidden assumption baked in: building custom software costs a fortune in engineering time, takes 12-18 months, and carries real delivery risk. Buying a SaaS subscription costs a predictable monthly fee and ships today. Under those conditions, buying almost always wins for anything that isn't your core differentiator. AI broke that assumption at the foundation. Spiceworks called it directly this week: "AI changes everything" in the build vs buy calculus for 2026, and they're not exaggerating for a headline. When an AI-assisted engineering team can spec, build, test, and ship a working internal tool or customer-facing product in weeks instead of quarters, the cost side of "build" collapses. Meanwhile the cost side of "buy" hasn't moved. SaaS pricing keeps climbing, seat-based models punish growth, and vendor lock-in is still vendor lock-in. Harvard Business Review's read this week is more careful, and I think it's the more useful one for actually making decisions. They're warning the SaaS impact from AI will be "uneven." Some vendors keep pricing power because they own genuinely hard infrastructure, proprietary data, or network effects you can't replicate. Others get commoditized fast because their entire value proposition was "we built the boring CRUD app so you didn't have to," and now every team can build that boring CRUD app themselves, over a weekend, with an AI agent doing the scaffolding. That's the real skill now: telling the difference between the two categories before you sign the contract.

The $30 Million Signal Nobody in Sweden Is Talking About

The story that should be keeping Swedish CTOs up at night this week isn't really about Sweden at all. An Indian tycoon just committed $30 million of his own money to build an AI-native alternative to Microsoft Office. Not a startup pitching VCs on a dream. A wealthy operator personally funding a direct assault on one of the most entrenched, moated, "nobody ever builds against this" incumbents in enterprise software. Think about what that actually signals. If Office, arguably the single most defensible SaaS franchise in existence, is now considered a buildable target by someone with capital and conviction, what does that say about your Salesforce instance? Your HubSpot subscription? Your bespoke-feeling-but-actually-generic internal ops platform that costs you six figures a year and does maybe 40% of what your team actually needs? I'll say the quiet part out loud: most of the "core" enterprise software stack running Swedish mid-market companies right now is not defensible the way Office used to look defensible. It's defensible because switching is annoying and because nobody has run the real math on custom SaaS development costs since AI-assisted engineering became normal. That's a habit problem, not an economics problem.

Rent, Build, or Own the Model: The Real Decision Tree

Here's where I diverge from most of what's being written about this right now. The framework isn't build vs buy anymore. It's a three-way decision, and most people are still only looking at two of the options. Rent. You pay monthly, you get zero ownership, you get whatever roadmap the vendor decides you get, and you accept whatever price increases they push. This is correct for genuinely commodity infrastructure where you have no competitive reason to differentiate. Your accounting software. Your email provider. Nobody should build their own Gmail. Build. You own the code, the data model, the roadmap. This used to mean a 12-month engineering project and a team of eight. With AI-assisted development, serious internal tools and even customer-facing products now realistically ship as a rapid MVP in weeks, not quarters. This is correct when the software touches your actual differentiation, your customer data, your workflow that makes you faster or cheaper than competitors. Own the model. This is the option almost nobody in the Swedish mid-market is even considering yet, and it's the one that matters most going forward. It's not about owning a SaaS app. It's about owning the AI layer that runs your business logic, trained or fine-tuned on your own data, running on infrastructure you control, instead of renting intelligence from a vendor API that can change pricing, change policy, or get acquired out from under you. This is the difference between building an AI agent that calls someone else's black box model forever, and building AI Solutions where the reasoning capability itself is something you architect, not just something you consume. Most Swedish companies I talk to are stuck evaluating option one against option two using a cost model from 2018. Nobody's asking the third question at all.

Sweden's Blind Spot: We're Good Builders Who Keep Choosing Not to Build

Here's what's strange about the Swedish market specifically. We are not a country short on engineering talent. Jönköping, Linköping, Stockholm, we produce serious technical people. Spotify, Klarna, Northvolt (whatever you think of how that ended) all came out of a culture that knows how to build hard technical things. And yet the default instinct in most Swedish boardrooms is still "buy the SaaS, it's the safe choice." Breakit has covered the funding slowdown for Nordic software startups extensively this year, and part of what's driving that isn't lack of ideas. It's that too many Nordic teams are still building thin SaaS wrappers around other people's infrastructure, competing on features against companies with ten times the capital, instead of using AI-native development to build defensible internal capability or genuinely differentiated products. Compare that to what's happening in the US right now, where the $30 million Office challenger story is one of dozens. American founders with capital are treating "buy this incumbent's product" as an insult to their engineering ambition. Compare it to China, where AI-native tooling gets adopted into internal workflows faster than almost anywhere, because nobody's waiting for a procurement committee to bless it. Sweden's advantage has always been trust, quality, and a workforce that doesn't need to be managed like children. Our disadvantage right now is a lingering "buy don't build" instinct that made sense in 2015 and is actively costing companies money in 2026. Dagens Industri has run several pieces this year on Swedish enterprise IT spend continuing to climb even as AI tooling gets cheaper and more capable. That gap between spend and value is the opportunity.

Where This Goes: 2026 to 2030

Here's my honest read on the trajectory, not the hype version. Over the next 18 months, the AI-assisted build cost for a serious business application keeps dropping toward near-zero marginal engineering cost for anything that isn't genuinely novel. That means the SaaS vendors HBR is right to warn about, the ones without real moats, either get commoditized into pure infrastructure plays or they pivot hard into being AI-native themselves. You'll see a wave of "we rebuilt our product with AI agents doing 80% of the work" announcements from incumbents defending market share. Some of that will be real. Most of it will be marketing dressed as a product update. Over the 2-5 year horizon, as models get closer to genuine agentic capability (not AGI in the sci-fi sense, but "reliable autonomous execution of multi-step business processes" which is the actual milestone that matters commercially), the "own the model" option stops being a niche play for well-capitalized enterprises and becomes standard practice for any mid-market company with a real data asset. The company that owns its trained model, its fine-tuned reasoning layer, its proprietary agent stack, has a durable advantage that a SaaS subscriber simply cannot replicate by paying more money. That's the actual moat conversation nobody's having loudly enough yet. And the regulatory side is nowhere near ready for this. The EU AI Act is a compliance framework, not a competitiveness strategy. It tells you what you can't do with AI. It says almost nothing useful about how European companies should be positioned to own AI capability rather than rent it from American hyperscalers. Sweden's own AI strategy documents are still largely about "responsible adoption" language, which is fine as far as it goes, but I don't see anyone in Swedish policy circles asking the harder question: are we creating conditions for Swedish companies to own their AI infrastructure, or are we quietly accepting a future where every Nordic business is a permanent tenant on American model infrastructure, paying rent forever on the most important layer of the business? That's a strategic dependency question, and right now it's not being asked at the level it needs to be.

What to Actually Look At

If you're a CTO or founder trying to make this decision this quarter, not in theory, here's where I'd point you. Start with tooling that makes the "build" side of the equation concrete instead of abstract. OpenHands is worth running internally to see what AI-driven development actually produces on a real ticket from your backlog, not a demo. If your team hasn't tried building against a codebase knowledge graph, Graphify turns your existing SaaS integrations, docs, and schemas into something queryable, which is genuinely useful when you're scoping what a custom replacement would actually need to cover before you commit engineering time to it. For API-heavy migrations off SaaS vendors, and most build vs buy decisions eventually become an integration problem, tools like Bruno or Hoppscotch give you an open-source way to map exactly what your current vendor's API surface looks like before you decide whether replicating it is trivial or genuinely hard. Do that mapping exercise honestly and you'll be surprised how often "trivial" wins. And if you're specifically weighing whether to rent intelligence or own it, that's not a tooling question, that's an architecture conversation. That's the one we have with clients directly through AI Solutions and AI Agents, because the honest answer depends on your data, your differentiation, and your five-year horizon, not a generic framework.

What to Actually Do This Quarter

Stop renewing SaaS contracts by default. Before your next renewal, run the real exercise: what does this vendor actually do that's hard to replicate, versus what does it do that's just CRUD with a nice UI and a sales team. Price out a rapid MVP for the second category. You'll be uncomfortable with how cheap and fast the answer comes back. If the tool touches your core differentiation, your customer relationship, your actual competitive edge, stop renting it. Build it through proper custom SaaS development or full fullstack development, own the code, own the roadmap, stop being a tenant in your own business. And start asking the third question, not just the first two. Where in your stack are you renting intelligence that you could be owning? That's the conversation that actually matters in 2026, and almost nobody in the Swedish mid-market is having it yet. Be early.

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.