
Build vs Buy Is Dead. Build vs Buy vs Prompt Is What's Left
Here's a question I got from a Swedish CFO last week: "Should we build our own CRM add-on or just buy Salesforce's module?" I told him he was asking the wrong question. The right question in July 2026 is whether he needs to build anything at all, or whether he can prompt his way to the same outcome in an afternoon. He looked at me like I'd suggested something illegal.
That reaction is the problem. Most leadership teams in Sweden, and honestly most in the US too, are still running a two-column decision tree. Build or buy. Cost per developer hour in Jönköping versus Krakow versus Bangalore. RFPs, vendor comparisons, six-week evaluation cycles. That whole apparatus was built for a world that stopped existing about eighteen months ago.
The Old Math Just Died
Goodfirms released their 2026 survey this month and the number should stop every CTO mid-coffee: 91% of software companies now use AI to cut development costs. Not "exploring AI." Using it. In production. Daily. That means the outsourcing arbitrage everyone built their sourcing strategy around, the spreadsheet comparing a Swedish senior dev's hourly rate to an Eastern European team's, is comparing numbers that don't matter anymore.
When an AI-assisted team in Jönköping and an AI-assisted team in Krakow are both shipping at three to five times their 2023 velocity, the geographic cost delta shrinks to almost nothing relative to total project cost. The bottleneck moved. It's not "who can I hire cheapest," it's "what actually needs a team at all."
Clockwise Software's ERP cost breakdown, published this month, makes the same point from a different angle: the line items in a traditional ERP build (integration, customization, maintenance) are exactly the categories AI agents are eating first. And Thailand's software sector is having its own reckoning right now, with local firms publicly repositioning from "buyers of Western software" to "builders," because the cost of standing up something custom dropped faster than the cost of licensing something generic went down. Same pattern in Bangkok as in Jönköping. This is not a regional story. It's a category-level shift in what software procurement even means.
Buy Is the New Default. Build Is the New Exception. Prompt Is the New Middle
Here's the mental model I'm using with my own team and with clients right now:
Buy, for the 80%
If it's HR software, expense tracking, basic CRM, generic analytics dashboards, standard e-commerce plumbing: buy it. This was already true in 2022 and it's even more true now because SaaS vendors are themselves AI-accelerated, meaning their products got better and cheaper faster than you could have built an equivalent internally. Anyone still running a six-month internal build for something Notion, HubSpot, or a vertical SaaS already does well is burning runway on a solved problem. This is 2022 procurement logic wearing a 2026 costume.
Prompt, for the messy middle
This is the category that didn't exist as a real option two years ago and now eats a huge chunk of what used to be "build." Internal tools, one-off automations, data pipelines that glue two systems together, a dashboard your ops team needs for exactly one quarter, a scraper, a report generator. You don't buy this (too niche, no vendor will build it for you at the price point) and you don't build this in the traditional sense (hire a team, write a spec, six sprints). You prompt it. An agent harness like ECC, which is currently sitting at the top of GitHub's trending list with skills, memory, and research-first workflows built for Claude Code and Cursor, is the kind of tooling that turns a two-week internal tool into a two-day one, sometimes a two-hour one. We use variants of this exact pattern inside HEIMLANDR's own AI Agents work. The output isn't a product you sell. It's infrastructure you'd never have justified building the old way, and now you don't have to justify it, because the cost of getting it wrong is an afternoon, not a quarter.
Build, for the 20% that's your moat
This is the part everyone gets wrong in both directions. Some teams still build too much (ego, control issues, "not invented here"). Others have overcorrected into buying or prompting everything, including the thing that's actually their competitive advantage. If the software IS the business, if it's the product your customers pay for, if it encodes proprietary logic, workflows, or data relationships nobody else has, you build it properly. Custom SaaS development for your core product isn't optional just because AI made everything else cheap. If anything, the fact that commodity software got commoditized means your moat has to be sharper, not softer. This is exactly the work we do through SaaS Development and Rapid MVP, because even a proper build in 2026 should move at a speed that would have looked reckless in 2022.
Sweden's Blind Spot: We're Great at Building, Slow at Deciding
Here's where I'll be direct about my own backyard. Swedish engineering culture is genuinely excellent. Consensus-driven, quality-obsessed, low ego relative to Silicon Valley. That's real and it's why companies like Klarna, Spotify, and a wave of Nordic B2B SaaS players punch so far above our population size.
But that same consensus culture is exactly what's slowing down the build-vs-buy-vs-prompt decision. American teams, for all their chaos, will spin up five prompted prototypes before lunch and kill four of them without a meeting. Swedish teams want a workshop, a stakeholder map, and a Confluence page before anyone touches a keyboard. That instinct made sense when a wrong build decision cost six months and a real team. It makes much less sense when the wrong decision now costs an afternoon of agent time.
Breakit and DI have both covered the Swedish AI adoption gap this year, and the pattern is consistent: Swedish companies are buying AI tools at a healthy clip but restructuring almost nothing about how decisions get made. Same procurement committees, same RFP timelines, same "let's get three vendor quotes" reflex, applied to a category of decision that often shouldn't take longer than the meeting called to discuss it.
Compare that to what's happening in Asia right now with Thailand's buyer-to-builder shift, or to how fast US mid-market companies are collapsing their tooling stacks. The Nordic advantage in trust and quality is real. The Nordic disadvantage in decision speed, in a market where the cost of experimentation just fell 90%, is becoming a real drag on competitiveness. EU AI Act compliance work adds another layer, real and necessary, but it's often used as an excuse to slow everything down rather than a framework to move fast inside.
Where This Goes: 2028 and the Procurement Department That Isn't
Push this forward two to three years and the shape gets clearer. As we get closer to genuinely general-purpose AI systems, the "prompt" category doesn't stay a middle tier, it swallows most of what's currently "build" too. The 20% that remains truly build-worthy shrinks to whatever requires proprietary data, regulatory trust, or a relationship no model can replicate. Everything else becomes something you specify in natural language and verify, not something you architect from scratch.
That has three consequences Swedish leadership teams should be planning for now, not in 2028:
Procurement as a function shrinks or disappears for a huge category of software spend. The people whose job is comparing vendor quotes for things that can now be prompted into existence in a day need to be redeployed toward the 20% decisions that actually matter, evaluating build partners, owning architecture, protecting the moat.
Regulation is not ready, and Sweden is not leading here despite what we tell ourselves. The EU AI Act was written for a world of discrete AI products. It says very little about a world where every employee with a laptop and a Claude subscription is generating production software on demand. Who owns liability when a prompted internal tool that nobody formally "built" leaks data? Swedish regulators, and frankly EU regulators generally, have not caught up to agentic development at the scale Goodfirms' 91% number implies. This is a gap founders should watch closely, because the first real enforcement case is coming and nobody wants to be the example.
Talent value inverts. The developer who was valuable for typing code fast becomes less valuable than the one who's excellent at judgment: knowing which of the three buckets a given problem belongs in, and saying no to the wrong one. That's a harder skill to hire for and Swedish companies, with our flat hierarchies, are actually well positioned to develop it if we stop treating AI adoption as a tooling question and start treating it as an org design question.
What to Look At This Week
If you're rethinking your own build/buy/prompt split, four things worth your actual attention, not just a bookmark:
- ECC (affaan-m): currently the most-starred repo on GitHub this week for good reason. It's an agent harness with skills, memory, and security baked in for Claude Code, Cursor, and Codex. This is the infrastructure that makes "prompt it" a serious option for internal tooling rather than a toy.
- Graphify: turns your existing codebase, docs, and SQL schemas into a queryable knowledge graph with deterministic parsing, no vector store required. If you're worried prompting will create technical debt nobody understands, this is the counterweight, it makes any codebase (human or agent-built) actually legible.
- OpenHands: for teams that want to see what fully AI-driven development looks like end to end before committing headcount to a build decision. Good way to pressure-test whether something belongs in the "build" bucket at all.
- Daytona: secure, elastic infrastructure specifically for running AI-generated code safely. If your org is scared of prompted tools because of security exposure, this is the kind of sandbox that removes the excuse.
And if you're staring at a decision right now and genuinely don't know which bucket it belongs in, that's a conversation worth having before you spend a single hour on it either way. We help teams sort exactly this at HEIMLANDR, through AI Solutions and Fullstack Development, and half the value isn't the code, it's telling a client honestly that they don't need us for this one.
The Actual Thing to Do Monday Morning
Stop running one decision tree. Run three parallel filters on every software request that lands on your desk this quarter:
Is there a mature vendor already solving this well? Buy it, today, don't schedule a meeting about it. Is this a one-off internal need, glue code, a report, an automation? Prompt it with an agent harness and see what you get before you write a single line of spec. Is this the thing customers actually pay you for, the logic nobody else has? Build it properly, with real architecture and real people, and don't let anyone talk you into prompting your moat into existence over a weekend.
The Swedish instinct toward careful, deliberate decision-making isn't wrong. It's aimed at the wrong decisions. Save the deliberation for the 20%. Move at agent speed on the other 80%. That's the whole update.
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.
VD & Skribent
VD för HEIMLANDR.IO. Punk rock-teknik från Jönköping, Sverige. Bygger AI-system, blockchain-infrastruktur och skriver om vart branschen faktiskt är på väg — inget ekokammare, ingen hype.