Picture this: You’re sitting in a conference room in the middle of a salesperson pitch. The demo looks solid, and the pricing fits well within the budget. The time limit also seems reasonable. Everyone is nodding along.
You’re literally minutes away from saying yes.
Then someone from your finance team walks in. They look at the deck and frown. A few minutes later, they send you a message on Slack: “Actually, I made a version of this last week. The cursor took me 2 hours. Want to take a look?”
What are you waiting for?
This person doesn’t code. You know for a fact that he has never written a single line of JavaScript in his entire life. But here they are, showing you a working prototype on their laptop that… does exactly what the seller said it would. Sure, it has some flaws, but it works. And it didn’t cost six figures. Just two hours of his time.
Suddenly, the assumptions you were carrying around – how software is developed, who makes it and how decisions are made around it – all begin to rapidly break down.
old structure
For decades, every growing company asked the same question: Should we make it ourselves, or should we buy it?
And, for decades, the answer was pretty straightforward: If this is the core of your business then build; If it is not then buy it,
The logic made sense, because construction was expensive and meant borrowing time from overworked engineers, writing specifications, planning sprints, managing infrastructure, and bracing themselves for the long tail of maintenance. Shopping was fast. Safe. You paid for support and peace of mind.
But something fundamental has changed: AI has made building accessible to everyone. Work that once took weeks now takes hours, and work that once required fluency in a programming language now requires fluency in plain English.
When the cost and complexity of buildings collapse so dramatically, the old structures go with them. It is no longer a case of build versus purchase. It’s something strange for which we can’t find the right words.
When the Market Doesn’t Know What You Want (Yet)
My company never planned to make so much of the equipment we use today. We just had to build because the things we needed didn’t exist. And, through that process, we developed this internal understanding of what we really wanted, what was useful and what it could or couldn’t do. Not what the vendor deck told us we needed or what the analyst reports said we needed, but what really moved the needle in our business.
We explored which problems were worth solving, which weren’t, where AI brought real benefits and where it was just noise. And only then, once we had that hard-earned clarity, did we start shopping.
By that point, we knew exactly what we were looking for and could tell the difference between substance and marketing in about five minutes. We asked questions that made the salespeople nervous because we had already created some early versions of what they were selling.
When anyone can build in minutes
Last week, someone on our CX team saw some customer feedback about a bug in Slack. Just a minor customer complaint, no big deal. At any other company, this would have triggered a support ticket and they would have waited for someone else to handle it, but that didn’t happen here. They opened the cursor, described the change, and let the AI write the solution. They then submitted a pull request which was reviewed by engineering and merged.
Just 15 minutes after that complaint surfaced in Slack, the fix 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 nonetheless.
And this is the point.
AI has become so good at understanding relatively simple code that it can handle 80% of the problems that used to require a sprint planning meeting and two weeks of engineering time. It is blurring the boundary between technical and non-technical. Work that used to be hampered by engineering is now being done by the people closest to the problem.
It’s happening right now at companies that are really paying attention.
the upheaval that is taking place
This is where this becomes attractive to finance leaders, because AI has essentially turned the entire strategic logic of the make vs. buy decision on its head.
The old model was like this:
- Define the need.
-
Decide whether to build or buy.
But defining the requirement took forever and required deep technical expertise, or you would spend money through trial-and-error vendor implementation. You’ll sit through countless demos to try to see if it really solves your problem. Then you’ll negotiate, implement, move all your data and workflows to the new tool and six months and six figures later find out that you were actually right (or not).
Now, the whole sequence changes:
- Build something lighter with AI.
-
Use this to understand what you really need.
-
Then decide whether to buy or not (and you’ll know exactly why).
This approach lets you run controlled experiments. You figure out if the issue matters. You find out which features provide value and which look good in demos. Then you go shopping. Instead of allowing an outside seller to sell you what you need, you first need to figure out whether you even need it.
Think about how much software you’ve purchased that, in hindsight, solved problems you didn’t actually have. The implementation took three months and how many times did you think, “Wait, is this actually helping us, or are we just trying to justify what we spent?”
Now, when you make a purchase, the question becomes “Does this solve the problem better than what we’ve already proven we can build?”
That one reframe changes the entire conversation. Now show you the informed seller call. You ask more pointed questions and talk from a place of strength. Most importantly, you avoid the most expensive mistake in enterprise software, which is solving a problem you never really had.
the trap you have to avoid
As this new capability emerges, I see companies running in the wrong direction. They know they need to master AI, so they go on a buying spree. They look for AI-powered tools, filling their stack with products that have GPT integration, chatbot UI, or “AI” on the marketing site. They think they are changing, but they are not.
Remember what physicist Richard Feynman said cargo cult scienceAfter World War II, islanders in the South Pacific built fake airstrips and control towers replicating what they had seen during the war, in the hopes that planes loaded with cargo would return. They had all the external trappings of an airport: towers, headsets, even people imitating flight controllers. But no plane landed because the form was not useful.
This is exactly what is happening with AI transformation in boardrooms everywhere. Leaders are buying AI tools without asking whether they meaningfully change how work is done, who they empower, or what processes they unlock.
They have built an airstrip, but the planes are not visible.
And the entire market is basically designed to lure you into this trap. Now everything is branded as AI, but no one cares what these products actually do. Every SaaS product has bolted on a chatbot or auto-complete feature and slapped an AI label on it, and the label has lost all meaning. It’s just a checkbox that sellers have to tick, regardless of whether it creates real value for customers or not.
FInans team’s new superpower
This is part of what excites me about what finance teams can do now. Now you don’t have to guess. You don’t have to bet six figures on a sell deck. You can test things out, and you might actually learn something before you spend.
What I mean is this: If you’re evaluating vendor management software, prototype the key workflows with an AI tool. Figure out whether you’re solving a tooling problem or a process problem. Find out if you need the software at all.
This doesn’t mean you’ll build everything internally – not at all. Most of the time, you’ll still be making a purchase, and that’s totally fine, because enterprise appliances exist for good reasons (scale, support, security, and maintenance). But now you will shop with open eyes.
You’ll know what “good” looks like. You’ll show up to demos already understanding edge cases, and know in about 5 minutes if they really understand your specific problem. You will execute faster. You will negotiate better because you are not completely dependent on the seller’s solution. And you’ll choose it because it’s actually better than something you could make yourself.
You’ll already have the shape of what you need, and you’re just looking for the best version of it.
new paradigm
For years, the mantra was: build or buy.
Now, it’s prettier and smarter: Build to know what to buy.
And this is not a future situation. This is already happening. Right now, somewhere, a customer representative is using AI to fix a product problem they noticed a few minutes ago. Elsewhere, a finance team is prototyping their own analytical tools because they realized they can iterate faster than engineering can write requirements. Somewhere along the way, a team is realizing that the boundary between technical and non-technical was always more cultural than fundamental.
Companies that embrace this change will grow faster and spend better. They will know their work more deeply than any salesman. They’ll make fewer costly mistakes, and buy better tools because they really understand what makes tools good.
Companies that stick to the old strategy will sit in vendor negotiations, nodding their heads at budget-friendly offers. They’ll argue over deadlines, and mistake professional decks for real solutions.
Until someone on their own team opens their laptop and says, “I made a version of this last night. Do you want to check it out?” And shows them something they built in two hours that does 80% of the work they’re getting paid for in six figures.
And, just like that, the rules change for good.
Sikki Chen is the co-founder and CEO of Runway.
Read more from us guest authorOr, consider submitting a post of your own! see our guidelines here,
<a href