Picture it: You’re sitting in a conference room, halfway through a sales pitch. The demo looks solid, and the pricing fits well under the budget. The timeline also seems reasonable. With everyone nodding along.
You are literally minutes away from saying yes.
Then someone from your finance team walks in. They see decks and showers. A few minutes later, they shoot you a message on Slack: “Actually, I put together a version for this week. Took me 2 hours on Cursor. Want to take a look?”
Wait… what?
This person does not code. You know for a fact that they’ve never written a line of JavaScript in their entire lives. But here they are, showing you a working prototype on their laptop that works…exactly what the vendor pitched. Sure, it’s got some rough edges, but it works. And it didn’t cost six figures. Just two hours of their time.
Suddenly, the assumptions you go with — about how software is developed, who builds it and how decisions are made around it — all start to come apart at the seams.
Old framework
For decades, every growing company has asked the same question: Should we build it ourselves, or should we buy it?
And, for decades, the answer was pretty straightforward: Build if it is the core of your business. If not, buy it.
The logic made sense, since building was expensive and meant borrowing overworked engineers, writing specs, planning spirits, managing infrastructure and bracing yourself for long maintenance tails. Buying was fast. Secure you paid support and peace of mind.
But something fundamental has changed: AI has made building 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 dramatically outpace it, the old framework goes down with them. It’s no longer a build versus a buy. It is a strange thing for which we have not found the right words.
When the Market Doesn’t Know What You Need (Yet)
My company never set out to make many of the tools we use. We just had to make it because the things we needed didn’t exist. And, through this process, we developed a greater understanding of what we really wanted, what was useful and what it could or could not do. It’s not what VanderDeck tells us we need or the analyst reports say we want, but what actually moves the needle in our business.
We assessed which problems were solvable, which weren’t, where AI made real leverage and where it was just noise. And only then, once we had that hard-earned explanation, did we start buying?
By then, 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 vendors nervous because we had already made some early versions that they were selling.
When one can build in minutes
Last week, someone on our CX team saw some user feedback about a bug in Slack. Just a minor customer complaint, nothing major. At another company, he might have opened a support ticket and waited for someone else to handle it, but that’s not the case here. They open the cursor, describe the change and let the AI ​​write fine. They then submitted a bridge application that was reviewed and integrated by engineering.
Just 15 minutes after this complaint popped up in Slack, the fix was live in production.
The person who did this is not a techie at all. I doubt they could tell you the difference between Python and JavaScript, but they solved the problem anyway.
And that’s it.
AI has done such a good job cranking out relatively simple code that it handles 80% of problems that would have required a sprint planning meeting and two weeks of engineering time. It is blurring the line between technical and non-technical. What used to be done by engineering is now being done by the people closest to the problem.
It’s happening right now in companies that are actually paying attention.
The opposite is happening
This is where it gets interesting for finance leaders, because AI has actually flipped the entire strategic logic of building versus buying decisions on its head.
The old model went something like this:
Define the requirement.
Decide whether to build or buy.
But specifying that requirement takes forever and requires deep technical expertise, or you’ll burn through money through trial-and-error vendor implementations. You’ll sit through countless demos, trying to figure out if it actually solved your problem. Then you’ll transfer all your data and workflow to the new device and six months and six figures, implement it, later discover if (or not) you were really right.
Now, the whole sequence is reversed:
Create something lightweight with AI.
Use it to understand what you actually need.
Then decide whether to buy (and you’ll know exactly why).
This approach lets you run controlled experiments. You find out if the problem even matters. You discover which features deliver value and which look good in a demo. Then You shop. Instead of having an outside vendor sell you on what you need, you have to figure out if you even need it in the first place.
Think about how much software you’ve purchased that solved the problems you had. How many times have you implemented and thought three months in, “On execution, is this actually helping us, or are we just trying to justify what we spent?”
Now, when you buy, the question becomes “Does this improve the problem we’ve already proven we can build?”
Its echo changes the whole conversation. You now display notified vendor calls. You ask sharp questions, and communicate 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 need to avoid
As this new capability emerges, I see companies sprinting in the wrong direction. They know they need to become AI native, so they go on a buying spree. They look for AI-powered tools, filling their stacks with products that include GPT integration, chatbot UIs or slapping an “AI” on the marketing site. They think they are changing, but they are not.
Remember what physicist Richard Feynman said Cargo cult science? After World War II, islands in the South Pacific built fake air raid and control towers, simulating what they had seen during the war, hoping to return planes loaded with cargo. They had all the trappings of an airport: towers, headsets, even people impersonating flight controllers. But no planes landed, because form was not function.
That’s exactly what’s happening with AI transforming 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 showing up.
And the entire market is basically set up to trap you. Now everything is branded as AI, but no one cares what these products actually do. Every SaaS product has emphasized a chatbot or autocomplete feature and slapped the AI ​​label on it, and the label has lost all meaning. It’s just a checkbox vendors figure they need to tick, regardless of whether it creates real value for customers.
fThe pineapple team’s new superpower
This is the part that gets me excited about what finance teams can do now. You don’t have to guess anymore. You don’t have to bet six figures on the sales deck. You can test things out, and you can really learn something before you spend.
Here’s what I mean: If you’re evaluating vendor management software, prototype basic workflows with AI tools. Determine whether you are solving a tooling problem or a process problem. Find out if you need the software.
That doesn’t mean you’ll build everything internally – of course not. Most of the time, you’ll still end up buying, and that’s perfectly fine, because enterprise tools exist for good reasons (scale, support, security, and maintenance). But now you will buy with your eyes open.
You know what “good” looks like. You’ll show demos to understand Edge issues first, and know in about 5 minutes whether they really get your specific problem or not. You will implement faster. You will communicate better because you are not completely dependent on the vendor’s solution. And you’ll choose it because it’s genuinely better than what you could make yourself.
You’ve already mapped the shape you need, and you’ll just find the best version of it.
New pattern
For years, the mantra was: build or buy.
Now, it’s prettier and way better: build to learn what to buy.
And this is not some future state. This is already happening. Right now, somewhere, a customer representative is using AI to fix a product problem they saw minutes ago. Elsewhere, a finance team is prototyping their analytics tools because they realize they can iterate faster than they can write engineering requirements. Somewhere, a team is realizing that the boundary between technical and non-technical is always more cultural than fundamental.
Companies that embrace this shift will move faster and spend smarter. They will know their operations more intimately than any vendor. They’ll make fewer costly mistakes, and buy better tools because they actually understand what makes tools good.
Companies that stick to the old playbook will likely sit through vendor pitches on budget-friendly proposals. They’ll debate timelines, and keep mistaking professional decks for real solutions.
Until someone on their own team opens their laptop, says, “I made a version last night. Want to check it out?” , and shows them something made in two hours with 80% paying six figures for it.
And, just like that, the rules change for good.
Ski Chen is the co-founder and CEO of Runway.
Read more from us Guest authors. Or, consider submitting a post of your own! See our Guidelines here.