Picture this: You’re sitting in a conference room in the middle of a vendor pitch. The demo is solid and the price is within your budget. The timeline also seems reasonable. Everyone is nodding along.
You are literally minutes away from saying yes.
Then someone from the finance team comes in. They look at the deck and frown. A few minutes later, you receive the following message in Slack: “I actually put together a version of this last week. It took me two hours on Cursor. Would you like to take a look?”
Wait…what?
This person doesn’t code. In fact, you know they’ve never written a single line of JavaScript in their lives. But here they show a prototype running on a laptop that works almost exactly as the vendor proposed. Sure, there are some rough edges, but it works. And it cost less than six figures. They only have 2 hours.
Suddenly all the assumptions you had about how software is developed, who writes it, and how decisions are made about it start coming apart at the seams.
old framework
For decades, every growing company has been asking the same question. Should I make this myself or buy one?
And for decades, the answer was very simple. Build it if it’s core to your business. If not, buy it.
It was expensive to build, because you had to write specs, plan sprints, manage infrastructure, and prepare for long maintenance, and you had to borrow the time of overworked engineers. Purchasing was faster. It’s safer. You paid for support and reassurance.
But something fundamental has changed. AI has made buildings accessible to everyone. Tasks that once took weeks now take hours, and tasks that once required fluency in a programming language now require fluency in plain English.
When the cost and complexity of buildings collapses so dramatically, so does the old framework. It doesn’t matter whether you build or buy anymore. It’s a strange thing, for lack of a better word.
When the market doesn’t understand what you need (yet)
My company never intended to build this many tools. What we needed didn’t exist, so we had to build it. And through that process, we’ve come to understand intuitively what we actually want, what’s helpful, and what we can and can’t do. What actually moved the needle for our business, rather than what the vendor documentation told us we needed or what the analyst report told us we needed?
We now know which problems are worth solving and which ones aren’t, where AI can really be used and where it’s just noise. And only after we had that hard-earned clarity, did we start making purchases.
At that point, we knew exactly what we were looking for and could tell the difference between substance and marketing in about 5 minutes. We asked questions that made vendors nervous because they had already built a rudimentary version of what they were selling.
A time when anyone can build something in minutes
Last week, someone on our CX team noticed customer feedback about a bug in Slack. There are no major issues, just minor complaints from customers. At another company, this would have resulted in a support ticket and a wait for another person to respond, but that wasn’t the case here. They opened a cursor, explained the change, and let the AI write the fix. I then submitted a pull request that engineering reviewed and merged.
Just 15 minutes after the complaint appeared in Slack, the fix went into production.
The person who did this is not technical at all. I doubt they’ll tell you the difference between Python and JavaScript, but problem solved anyway.
That’s the point.
AI has gotten so good at writing relatively simple code that it can now handle 80% of problems that previously required a sprint planning meeting and two weeks of engineering time. The boundaries between technical and non-technical are disappearing. Work that was once an engineering bottleneck is now performed by the people closest to the problem.
This is what’s actually happening right now with the companies we’re paying attention to.
Reversal phenomenon occurring
This is where it gets interesting for finance leaders. Because AI is actually upending the entire strategic logic of build-versus-buy decisions.
The old model looked like this:
-
Define your needs.
-
Decide whether to build or buy.
However, defining the needs took forever and required deep technical expertise. Otherwise, you’ll end up wasting money experimenting with vendor implementations. I had to sit through countless demos and imagine if this would actually solve the problem. Then you negotiate, implement, and migrate all your data and workflows to the new tool, and six months and six figures later, you’ll find out if you were actually right.
This is where the entire sequence switches.
-
Build something lightweight with AI.
-
Use it to understand what you actually need.
-
Then decide whether to buy or not (and you’ll know exactly why).
This approach allows you to perform controlled experiments. You can also tell if the issue is important or not. Discover which features bring value and which ones look great in a demo. after that you go shopping. Instead of relying on external vendors to sell you your needs, you’ll be able to figure out if you even have those needs in the first place.
Think about how many times you’ve purchased software that, in hindsight, solved a problem you didn’t actually have. How many times, three months into implementation, have you thought to yourself, “Wait a minute, is this actually helping or am I just trying to justify the money spent?”
Now, when you actually buy, the question becomes, “Does this solve the problem better than what we’ve already proven we can build?”
That one framework changes the entire conversation. Now you can answer vendor calls and get notified. Ask sharper questions and negotiate from a position of strength. Most importantly, you can avoid the most expensive mistake in enterprise software: solving a problem you’ve never actually experienced.
Traps to avoid
As this new capability emerges, I’m seeing companies run in the wrong direction. They know they need to become AI natives, so they go shopping. They are looking for AI-powered tools and are filling their stacks with products that have GPT integrations, chatbot UIs, or “AI” built into their marketing sites. They think they are transforming, but they are not.
Remember what physicist Richard Feynman called it? cargo cult scienceAfter World War II, islanders in the South Pacific imitated those they had seen during the war, building fake runways and control towers in the hope that planes full of cargo would return. It had all the trappings of an airport: towers, headsets, and even people imitating flight controllers. However, the plane did not land because the shape was not working.
That’s exactly what is happening with AI transformation in boardrooms everywhere. Leaders are buying AI tools without asking if they will make sense of how work gets done, who they empower, and what processes they free up.
A runway has been built, but no planes appear.
And the whole market is basically set up to get you into this trap. Everything is branded as AI now, but no one seems to care what these products actually do. Chatbots, autocomplete features, and AI labels have been added to every SaaS product, making those labels completely meaningless. It’s just a checkbox number that vendors need to check whether or not it brings real value to their customers.
finance team’s new superpower
This is the part that excites me about what finance teams can do now. No more guessing. You don’t have to bet six figures on a sales deck. You can test things and actually learn something before spending money.
In other words, if you’re evaluating vendor management software, use AI tools to prototype your core workflows. Determine whether you are solving a tool problem or a process problem. Decide if you really need the software.
This doesn’t mean building everything internally. Of course not. In most cases, you’ll end up buying it, and that’s perfectly fine because there are good reasons for enterprise tools (size, support, security, maintenance). But from now on I will buy with my eyes wide open.
You can find out what “good” looks like. If you come to the demo with an understanding of the edge cases already, you’ll know in about 5 minutes if it actually solves your specific problem. Implementation is faster. Negotiations are better because you are not completely dependent on the vendor’s solution. And you’ll choose it because it’s really better than anything you could build yourself.
The shape of what you need is already planned out, so all you have to do is find the best version of it.
new paradigm
For years, the mantra was “make it or buy it.”
Now more elegant and smarter. Build to learn what to buy.
And it’s not a future state. This is already happening. Now, somewhere, a customer representative is using AI to solve a product problem they discovered minutes ago. Elsewhere, finance teams are prototyping their own analytical tools. Because we realized that iterating was faster than writing engineering requirements. Somewhere along the line, teams are beginning to realize that the line between technical and non-technical has always been more cultural than fundamental.
Businesses that embrace this change will move faster and spend more wisely. They will have a deeper understanding of your business than any other vendor. Because they actually know what the tools are good for, they make fewer costly mistakes and are able to buy better tools.
Companies that stick to old strategies will continue to sit through vendor sales pitches, nodding to budget-friendly proposals. They argue about schedules and keep mistaking professional decks for real solutions.
Until someone on my team opens up their laptop and says, “I created a version of this last night. Would you like to check it out?” and shows me something they created in two hours that delivers 80% of what they’re paying six figures for.
And just like that, the rules change forever.
Siqi Chen is the co-founder and CEO of Runway.
read more guest writer. Or consider submitting your own post. See our Click here for guidelines.
