Picture this: You're sitting in a conference room, halfway through a vendor pitch. The demo looks solid, and pricing matches nicely under budget. The timeline seems reasonable too. Everyone’s nodding along.
You’re literally minutes away from saying yes.
Then someone out of your finance team walks in. They see the deck and frown. Just a few minutes later, they shoot you a message on Slack: “Actually, I threw together a version of this last week. Took me 2 hours in Cursor. Wanna have a look?”
Wait… what?
This person doesn't code. You realize for a fact they've never written a line of JavaScript of their entire life. But here they’re, showing you a working prototype on their laptop that does… just about exactly what the seller pitched. Sure, it's got some rough edges, nevertheless it works. And it didn’t cost six figures. Just two hours of their time.
Suddenly, the assumptions you walked in with — about how software is developed, who makes it and the way decisions are made around it — all start coming apart on the seams.
The old framework
For many years, every growing company asked the identical query: Should we construct this ourselves, or should we buy it?
And, for many years, the reply was pretty straightforward: Construct if it's core to your corporation; buy if it isn’t.
The logic made sense, because constructing was expensive and meant borrowing time from overworked engineers, writing specs, planning sprints, managing infrastructure and bracing yourself for an extended tail of maintenance. Buying was faster. Safer. You paid for the support and the peace of mind.
But something fundamental has modified: AI has made constructing 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 fee and complexity of constructing collapse this dramatically, the old framework goes down with them. It’s not construct versus buy anymore. It’s something stranger that we haven't quite found the appropriate words for.
When the market doesn’t know what you would like (yet)
My company never planned to construct so most of the tools we use. We just had to construct since the things we wanted didn’t exist. And, through that process, we developed this visceral understanding of what we actually wanted, what was useful and what it could or couldn't do. Not what vendor decks told us we wanted or what analyst reports said we should always want, but what actually moved the needle in our business.
We discovered which problems were price solving, which of them weren’t, where AI created real leverage and where it was just noise. And only then, once we had that hard-earned clarity, did we start buying.
By that time, we knew exactly what we were searching for and will tell the difference between substance and marketing in about five minutes. We asked questions that made vendors nervous because we'd already built some rudimentary version of what they were selling.
When anyone can construct in minutes
Last week, someone on our CX team noticed some customer feedback a few bug in Slack. Only a minor customer criticism, nothing major. In one other company, this is able to’ve kicked off a support ticket they usually’d have waited for another person to handle it, but that’s not what happened here. They opened Cursor, described the change and let AI write the fix. Then they submitted a pull request that engineering reviewed and merged.
Just quarter-hour after that criticism popped up in Slack, the fix was live in production.
The one who did this isn’t technical within the slightest. I doubt they may let you know the difference between Python and JavaScript, but they solved the issue anyway.
And that’s the purpose.
AI has gotten so good at cranking out relatively easy code that it handles 80% of the issues that used to require a sprint planning meeting and two weeks of engineering time. It’s erasing the boundary between technical and non-technical. Work that was once bottlenecked by engineering is now being done by the people closest to the issue.
This is occurring right away in firms which might be actually being attentive.
The inversion that’s happening
Here's where it gets fascinating for finance leaders, because AI has actually flipped all the strategic logic of the construct versus buy decision on its head.
The old model went something like:
-
Define the necessity.
-
Determine whether to construct or buy.
But defining the necessity took ceaselessly and required deep technical expertise, otherwise you'd burn through money through trial-and-error vendor implementations. You'd sit through countless demos, attempting to picture whether this actually solved your problem. You then’d negotiate, implement, move all of your data and workflows to the brand new tool and 6 months and 6 figures later discover whether (or not) you were actually right.
Now, the entire sequence gets turned around:
-
Construct something lightweight with AI.
-
Use it to grasp what you really need.
-
Then determine whether to purchase (and also you'll know exactly why).
This approach enables you to run controlled experiments. You determine whether the issue even matters. You discover which features deliver value and which just look good in demos. Then you buy groceries. As a substitute of letting some external vendor sell you on what the necessity is, you get to determine whether you even have that need in the primary place.
Take into consideration what number of software purchases you've made that, in hindsight, solved problems you didn't even have. How over and over have you ever been three months into an implementation and thought, “Hang on, is that this actually helping us, or are we just attempting to justify what we spent?”
Now, whenever you do buy, the query becomes “Does this solve the issue higher than what we already proved we will construct?”
That one reframe changes all the conversation. Now you show as much as vendor calls informed. You ask sharper questions, and negotiate from a spot of strength. Most significantly, you avoid the most costly mistake in enterprise software, which is solving an issue you never really had.
The trap it is advisable avoid
As this latest capability emerges, I’m watching firms sprint within the fallacious direction. They know they must be AI native, in order that they go on a shopping spree. They give the impression of being for AI-powered tools, filling their stack with products which have GPT integrations, chatbot UIs or “AI” slapped onto the marketing site. They think they’re transforming, but they’re not.
Remember what physicist Richard Feynman called cargo cult science? After World War II, islanders within the South Pacific built fake airstrips and control towers, mimicking what they'd seen through the war, hoping planes stuffed with cargo would return. They’d all of the outward types of an airport: Towers, headsets, even people miming flight controllers. But no planes landed, since the form wasn’t the function.
That’s exactly what’s happening with AI transformation in boardrooms in all places. Leaders are buying AI tools without asking in the event that they meaningfully change how work gets done, who they empower or what processes they unlock.
They’ve built the airstrip, however the planes aren’t showing up.
And the entire market's mainly set as much as make you fall into this trap. The whole lot gets branded as AI now, but no person seems to care what these products actually do. Every SaaS product has bolted on a chatbot or an auto-complete feature and slapped an AI label on it, and the label has lost all meaning. It’s only a checkbox vendors figure they should tick, no matter whether it creates actual value for patrons.
The finance team’s latest superpower
That is the part that gets me enthusiastic about what finance teams can do now. You don’t must guess anymore. You don’t must bet six figures on a sales deck. You may test things, and you possibly can actually learn something before you spend.
Here's what I mean: When you’re evaluating vendor management software, prototype the core workflow with AI tools. Work out whether you’re solving a tooling problem or a process problem. Work out whether you would like software in any respect.
This doesn’t mean you’ll construct the whole lot internally — in fact not. More often than not, you’ll still find yourself buying, and that's totally high quality, because enterprise tools exist for good reasons (scale, support, security, and maintenance). But now you’ll buy together with your eyes wide open.
You’ll know what “good” looks like. You’ll show as much as demos already understanding the sting cases, and know in about 5 minutes whether or not they actually get your specific problem. You’ll implement faster. You'll negotiate higher since you're not completely depending on the seller's solution. And also you’ll select it since it's genuinely higher than what you may construct yourself.
You'll have already mapped out the form of what you would like, and also you'll just be searching for the very best version of it.
The brand new paradigm
For years, the mantra was: Construct or buy.
Now, it’s more elegant and way smarter: Construct to learn what to purchase.
And it's not some future state. That is already happening. Without delay, somewhere, a customer rep is using AI to repair a product issue they spotted minutes ago. Some other place, a finance team is prototyping their very own analytical tools because they've realized they will iterate faster than they will write up requirements for engineering. Somewhere, a team is realizing that the boundary between technical and non-technical was at all times more cultural than fundamental.
The businesses that embrace this shift will move faster and spend smarter. They’ll know their operations more deeply than any vendor ever could. They'll make fewer expensive mistakes, and buy higher tools because they really understand what makes tools good.
The businesses that follow the old playbook will keep sitting through vendor pitches, nodding along at budget-friendly proposals. They’ll debate timelines, and keep mistaking skilled decks for actual solutions.
Until someone on their very own team pops open their laptop, says, “I built a version of this last night. Want to envision it out?,” and shows them something they in-built two hours that does 80% of what they’re about to pay six figures for.
And, identical to that, the foundations change for good.
Siqi Chen is co-founder and CEO of Runway.
Read more from our guest writers. Or, consider submitting a post of your personal! See our guidelines here.
