Skip to content
Back to blog
Build vs Buy Is Dead. The Real Question Is Build vs Wait.
Privacy & Security

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

F
Fredrik BrunnbergCEO & Writer
June 9, 20267 min read

The €500K ERP That a Solo Engineer Will Rebuild in 2028

Right now, as I write this from Jönköping, a Swedish mid-market company is signing a €400K contract for a custom ERP build. Another one is locking into a five-year Salesforce agreement at €180K per year. Both decisions will look absurd within 24 months. Not because the software will be bad. Because the cost to reproduce it will collapse so fast that the contract itself becomes the liability.

The entire build vs buy software debate is dead. It assumes something that is no longer true: that the cost curves of building software are stable enough to make a meaningful long-term comparison. They are not. What I see in the market right now, in Sweden and globally, is a capability curve so steep that every software decision should be treated as a short-term lease, not a long-term investment.

The real question in 2026 is not build vs buy. It is build vs wait.

The Numbers That Kill the Old Framework

Let me lay this out plainly. Current reporting puts ERP development costs at €150K to €500K+. Swedish developer rates run €80 to €150 per hour. Eastern Europe is €30 to €55. India is €15 to €35. These are real numbers from real rate guides published this month.

But these comparisons are already obsolete. They measure human labor hours. And human labor hours are no longer the dominant variable in software development in Sweden or anywhere else.

Here is what is actually happening. An AI-augmented senior engineer today ships what a team of four shipped 18 months ago. Tools like OpenHands, which has 76,000+ stars on GitHub, give a single developer AI-driven development capabilities that were science fiction in 2024. RTK, a Rust-based CLI proxy, reduces LLM token consumption by 60-90% on common dev commands. These tools are not experimental. They are being used in production right now.

When I see listicles like "Best Custom Software Development Companies 2026" flooding tech publications this month, I see an industry desperately selling billable hours into a market where the unit cost of software creation is in freefall. The agencies and consultancies publishing these guides have an existential incentive to pretend the old model still works. It does not.

What "Architecting for Disposability" Actually Means

The smartest founders I talk to, both here in Sweden and in the wider Nordics, are doing something the market has not named yet. I call it architecting for disposability.

It works like this. Instead of asking "should we build this or buy this?", they ask: "What is the minimum commitment we can make to solve this problem for the next 18-24 months, knowing that the cost to rebuild or replace it will be dramatically lower by then?"

This is not about building bad software. It is about building appropriately scoped software with clear interfaces, modular architecture, and zero emotional attachment to the codebase itself.

Practically, this means:

  • MVP development first, always. Ship the smallest thing that solves the problem. Not because you are cheap, but because the version you would build today with a €300K budget will be reproducible at a fraction of that cost in 18 months. We built our Rapid MVP service around exactly this thinking.
  • Short contracts. If you are buying SaaS, negotiate 12-month terms. Yes, you will pay more per month. No, you will not be locked into a product whose competitive advantage evaporates when a solo developer with an AI copilot can rebuild its core functionality.
  • API-first everything. Every component should be replaceable. If your vendor does not offer clean API access to your data, walk away. You are not buying software. You are renting a prison.
  • Invest in architecture, not in code. The code is disposable. The architecture, the data model, the integration patterns: those survive the rebuild cycle. Spend your money on senior architects, not on junior developers writing code that an AI agent will write better next year.

Sweden's Specific Problem: Over-Indexed on Premium SaaS

Let me talk about Sweden specifically, because we have a particular vulnerability here.

Swedish companies are over-indexed on premium SaaS subscriptions. Salesforce. SAP. Microsoft Dynamics. We love our enterprise software. We pay top dollar for it. And we lock into multi-year agreements because the procurement departments are optimized for stability, not for adaptability.

The pricing models of these platforms assume the old build-cost floor. They assume that the alternative, building it yourself, is so expensive that their subscription price looks reasonable by comparison. That floor no longer exists. And Sweden has no specific policy response to this shift.

Compare this to what is happening in the US, where VC-backed startups are aggressively building AI-native replacements for every major SaaS category. Or look at Asia, where the combination of lower labor costs and aggressive AI adoption is compressing timelines even further. Swedish companies are sitting in the most expensive seat in the house and the show is about to change.

Meanwhile, the EU AI Act focuses on risk classification and compliance frameworks but says nothing about the economic disruption hitting the software industry itself. Regulators are worried about AI safety. Fine. But nobody is asking what happens to the Swedish tech services sector when the labor multiplier that justifies €100+/hour rates gets compressed by 5x in three years. Nobody is asking what happens to procurement when "custom SaaS development" goes from a six-month, €300K project to a six-week, €40K project.

Swedish policy is not keeping up. Not because the people are bad, but because the frame is wrong. They are regulating AI as a product category when they should be preparing for AI as an economic force that restructures how all software gets made and sold.

Where This Goes: 2027-2030

Let me be specific about what I think the trajectory looks like.

By late 2027: A competent engineer with AI tooling builds in a week what a team of five builds today in a quarter. The €500K custom ERP becomes a €60-80K project. Most SaaS companies that sell commodity functionality (CRM, project management, basic analytics) face existential pricing pressure as customers realize they can have bespoke versions built for less than a year of subscription fees.

By 2028-2029: Agent-based development platforms, the next evolution of what projects like Agno and ECC are building right now, handle not just code generation but testing, deployment, monitoring, and iteration. The concept of a "SaaS development company" shifts from "we write code for you" to "we design systems and supervise AI agents that write code." This is already the direction we are moving at HEIMLANDR's AI Agent practice.

By 2030: If capability curves continue, and I believe they will, we approach a point where the distinction between custom software and off-the-shelf software dissolves. Every deployment is effectively custom. Generated for your specific use case, your data model, your workflow. The build vs buy question is not just dead. It is incomprehensible to the next generation of founders.

The path toward AGI-adjacent capabilities does not mean everything gets easy. It means the hard problems shift. Building software stops being the bottleneck. Knowing what to build, understanding the domain, designing the right system, getting the data strategy right: those become the entire game. The code is just the output.

What to Look At

If you are a CTO or founder processing this, here are the specific things I would put on your radar this week:

OpenHands (76K+ GitHub stars). AI-driven development that is not a toy. If you have not had your team experiment with this, you are behind. It gives you a real sense of where solo-developer productivity is heading.

Daytona (72K+ stars). Secure, elastic infrastructure for running AI-generated code. This is the infrastructure layer that makes disposable builds practical. When your code is generated, you need an environment that treats it as ephemeral. Daytona does that.

RTK (60K+ stars). A single Rust binary that cuts LLM token costs by 60-90% on dev commands. This is the kind of tool that makes AI-augmented development economically viable at scale, not just for experiments.

Hoppscotch (79K+ stars). Open-source API development ecosystem. If you are serious about API-first architecture, and you should be, this is the open-source Postman alternative that does not lock you in.

So What Do You Actually Do?

Stop making five-year software commitments. Full stop. If someone is asking you to sign a contract that assumes today's cost structure will hold through 2030, they are either not paying attention or hoping you are not.

Audit your SaaS stack. Every subscription over €50K/year deserves a build-cost estimate using current AI-augmented development rates, not 2024 rates. You will be surprised how many subscriptions no longer make economic sense. We do this kind of analysis with our AI Solutions consulting.

Hire for architecture taste, not for coding speed. The code generation problem is being solved by machines. The system design problem is not. The best investment you can make right now is in people who know what to build and how the pieces fit together.

Build your MVP development muscle. Whether you use an internal team or a partner, get comfortable with fast, scoped builds. Ship in weeks, not quarters. Treat the output as disposable. Invest in what survives: your data, your domain knowledge, your customer relationships.

And stop reading those "Best Custom Software Development Companies 2026" listicles. They are advertisements disguised as journalism, selling a model that is already dying.

The Bottom Line

I am not saying software does not matter. It matters more than ever. I am saying that the code itself is rapidly becoming the cheapest part of the equation. And every framework, every procurement process, every vendor evaluation model that does not account for that is leading you toward overspending today for something that will be trivially reproducible tomorrow.

Build vs buy was a good question when both options had stable, predictable costs. That world is gone. The new question is simpler and harder: What is the minimum commitment you can make right now to solve this problem, knowing that the tools to solve it better and cheaper are arriving in months, not years?

From Jönköping, where we are building the future one disposable system at a time.

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.

#build vs buy#software development sweden#custom saas development#mvp development#ai-augmented development
F
Fredrik Brunnberg

CEO & Writer

CEO of HEIMLANDR.IO. Punk rock tech from Jönköping, Sweden. Building AI systems, blockchain infrastructure, and writing about where this industry is actually heading — no echo chamber, no hype.