Build vs buy is dead — AI just killed it
Picture this: you’re sitting in a conference room, halfway through a sales pitch. The demo looks solid and the price fits nicely within the budget. The timeline also seems reasonable. Everyone nods along.
You’re literally minutes away from saying yes.
Then someone from your financial team comes in. They see the deck and frown. A few minutes later they message you on Slack: “Actually, I put together a version of this last week. It took me 2 hours in Cursor. Want to take a look?”
Wait… what?
This person doesn’t code. You can be sure they’ve never written a line of JavaScript in their entire life. But here they are, showing you a working prototype on their laptop that does… pretty much exactly what the salesperson pitched. Sure, it has some rough edges, but it works. And it didn’t cost six figures. Only two hours of their time.
Suddenly, the assumptions you came in with – about how software is developed, who creates it, and how decisions are made around it – all start to fall apart.
The old framework
For decades, every growing company asked the same question: Should we build this ourselves, or should we buy it?
And for decades the answer was quite simple: Build if it is the core of your business; buy if that is not the case.
The logic made sense because building was expensive and meant borrowing time from overworked engineers, writing specifications, planning sprints, managing infrastructure, and preparing for a long series of maintenance. Buying was faster. Safer. You paid for the support and peace of mind.
But something fundamental has changed: AI has made construction accessible to everyone. What used to take weeks now takes hours, and what used to require fluency in a programming language now requires fluency in plain English.
When the cost and complexity of building collapse so dramatically, the old framework goes down with them. It is no longer building versus buying. It’s something strange that we haven’t quite found the right words for yet.
If the market does not (yet) know what you need
My company never planned to build so many of the tools we use. We just had to build because the things we needed didn’t exist. And through that process we developed a deep-seated understanding of what we actually wanted, what was useful, and what it could or couldn’t do. Not what vendor decks told us we needed or what analyst reports said we should want, but what actually drove our business.
We found out which problems were worth solving, which weren’t, where AI was creating a real impact and where it was just noise. And only then, when we had that hard-earned clarity, did we start buying.
At that point, we knew exactly what we were looking for and could tell the difference between content and marketing in about five minutes. We asked questions that made salespeople nervous, because we had already built a rudimentary version of what they were selling.
When anyone can build in minutes
Last week, someone on our CX team noticed customer feedback about a bug in Slack. Just a minor customer complaint, nothing major. At another company this would have raised a support ticket and waited for someone else to handle it, but that didn’t happen here. They opened Cursor, described the change, and let AI write the solution. They then submitted a pull request that the engineering reviewed and merged.
Just 15 minutes after that complaint surfaced in Slack, the solution was live in production.
The person who did this is not technical at all. I doubt they could tell you the difference between Python and JavaScript, but they solved the problem anyway.
And that’s the point.
AI has become so good at developing relatively simple code that it solves 80% of the problems that used to require a sprint planning meeting and two weeks of engineering time. It blurs the line between technical and non-technical. Work that used to be hampered by technology is now done by the people closest to the problem.
This is now happening in companies that are actually paying attention.
The inversion taking place
This is where things get fascinating for financial leaders, because AI has essentially turned the entire strategic logic of the build versus buy decision upside down.
The old model went something like this:
-
Define the need.
-
Decide whether you want to build or buy.
But defining the need took forever and required deep technical expertise, otherwise you’d be burning money through trial and error vendor implementations. You went through countless demos trying to imagine if this actually solved your problem. Then you’d negotiate, implement, move all your data and workflows to the new tool, and find out six months and six figures later whether you were (or weren’t) right.
Now the whole series is reversed:
-
Build something lightweight with AI.
-
Use it to understand what you really need.
-
Then decide if you want to buy (and you’ll know exactly why).
This approach allows you to conduct controlled experiments. You’re going to find out if the problem even matters. You discover which features deliver value and which just look good in demos. Than you go shopping. Instead of letting an external supplier tell you what the need is, you can find out whether you even have that need.
Think about how many software purchases you’ve made that, in retrospect, solved problems that you didn’t actually have. How many times are you three months into an implementation and you think, “Wait a minute, is this actually helping us, or are we just trying to justify what we spent?”
If you buy something now, the question becomes, “Does this solve the problem better than what we have already proven we can build?”
That one rephrasing changes the entire conversation. Now you will appear informed about supplier calls. You ask sharper questions and negotiate from strength. Most importantly, you avoid the most expensive mistake in enterprise software, which is solving a problem you never really had.
The pitfall you must avoid
As this new opportunity presents itself, I see companies sprinting in the wrong direction. They know they have to be AI native, so they go shopping. They look for AI-powered tools and fill their stack with products with GPT integrations, chatbot UIs, or “AI” slapped on the marketing site. They think they are transforming, but they are not.
Remember what physicist Richard Feynman mentioned? cargo cult science? After World War II, islanders in the South Pacific built false runways and control towers, mimicking what they had seen during the war, in the hope that planes full of cargo would return. They had all the appearances of an airport: towers, headsets, even people imitating flight controllers. But no planes landed, because form was not function.
That’s exactly what’s happening with AI transformation in boardrooms everywhere. Leaders buy AI tools without asking whether they meaningfully change how work is done, who they empower, or what processes they unlock.
They built the runway, but the planes don’t show up.
And the entire market is actually aimed at making you fall into this trap. Everything is now branded as AI, but no one seems to care what these products actually do. Every SaaS product has a chatbot or an autocomplete feature and has an AI label slapped on it, and the label has lost all meaning. It’s just a checkbox that suppliers have to check, regardless of whether it creates actual value for customers.
The fthe new superpower of the Inance team
This is the part that gets me excited about what finance teams can do next. You don’t have to guess anymore. You don’t have to bet six figures on a sell pile. You can test things and you can actually learn something before you spend any money.
Here’s what I mean: If you’re evaluating vendor management software, prototype the core workflow with AI tools. Find out if you’re solving a tool problem or a process problem. Find out if you need any software at all.
This doesn’t mean you’re going to build everything internally – of course not. Most of the time you’ll buy anyway, and that’s fine because business tools exist for good reasons (scale, support, security, and maintenance). But now you buy with your eyes wide open.
You know what ‘good’ looks like. You’ll be shown demos that already understand the edge cases, and you’ll know in about five minutes if they actually understand your specific problem. You implement faster. You negotiate better because you are not completely dependent on the supplier’s solution. And you choose it because it really is better than what you could build yourself.
You have already mapped out the shape of what you need and you are just looking for the best version of it.
The new paradigm
For years the mantra was: build or buy.
Now it’s more elegant and much smarter: build to learn what to buy.
And it is not a future state. This is already happening. Right now, a customer representative somewhere is using AI to solve a product problem he noticed minutes ago. Elsewhere, a finance team is prototyping their own analytical tools because they’ve realized they can iterate faster than they can write requirements for engineering. Somewhere, a team realizes that the boundary between technical and non-technical has always been cultural rather than fundamental.
The companies that embrace this shift will move faster and spend smarter. They will know their operations better than any supplier ever could. They will make fewer costly mistakes and buy better tools because they actually understand what makes tools good.
The companies that stick to the old playbook will continue to follow salespeople’s pitches and nod along to budget-friendly proposals. They debate timelines and continue to confuse professional decks with actual solutions.
Until someone from their own team opens their laptop and says, “I built a version of this last night. Want to give it a try?”, and shows them something they built in two hours that does 80% of what they’re going to pay six figures for.
And just like that, the rules change forever.
Siqi Chen is co-founder and CEO of Runway.
Read more of our guest writers. Or consider posting yourself! See our guidelines here.
