Imagine this: you’re sitting in a conference room, halfway through a vendor’s presentation. The demo looks solid and the price is within budget. The timeline seems reasonable too. Everyone nods.
You are literally minutes away from saying “yes”.
That’s when someone from your finance team comes in. They see the waist and frown. A few minutes later, they send you a Slack message: “Actually, I made 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 know for a fact that they have never written a line of JavaScript code in their life. But here they are, showing off a working prototype on their laptop that does… almost exactly what the seller proposed. Sure, it has some abrasive edges, but it works. And it didn’t cost six figures. Just two hours of their time.
Suddenly, the assumptions you came in with – about how software is created, who creates it, and how decisions are made around it – start to come apart at the seams.
Aged frames
For decades, every growing company has asked the same question: Should we build it ourselves or should we buy it?
For decades, the answer was quite uncomplicated: Build if it is the foundation of your business; buy if it isn’t.
The logic made sense because building was pricey and required borrowing time from overworked engineers, writing specifications, planning sprints, managing infrastructure, and preparing for long maintenance. Buying was faster. Safer. You paid for support and peace of mind.
However, something fundamental has changed: artificial intelligence has made building accessible to everyone. What once took weeks now takes hours, and what once required proficiency in a programming language now requires proficiency in plain English.
When the cost and complexity of a building collapse dramatically, the aged frames fall with them. It’s no longer a question of build versus buy. It’s something weirder that we haven’t quite found the words for.
When the market doesn’t know what (else) you need
My company never planned to create so many of the tools we apply. We just had to build because the things we needed didn’t exist. Through this process, we developed an instinctive understanding of what we really wanted, what was useful, and what could and could not be done. Not what vendors told us we needed or what analysts reported we should want, but what actually moved the needle in our business.
We learned which problems were worth solving and which were not, where artificial intelligence created real leverage and where it was just noise. And only when we had that hard-won clarity did we start buying.
At this 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 annoyed salespeople because we had already created a basic 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. It’s just a minor customer complaint, nothing stern. At another company this would have triggered a support ticket and they would have waited for someone else to deal with it, but that didn’t happen in this case. They opened Cursor, described the change, and let the AI write the fix. They then submitted a pull request, which engineers reviewed and merged.
Just 15 minutes after the complaint appeared on Slack, the fix was already in production.
The person who did this is not the least bit technical. I doubt they could tell the difference between Python and JavaScript, but they solved the problem anyway.
And that’s the point.
AI has become so good at writing relatively uncomplicated code that it can solve 80% of problems that previously required a sprint planning meeting and two weeks of engineering time. It’s blurring the line between technical and non-technical. Work that was once an engineering bottleneck is now being performed by those closest to the problem.
This is now happening in companies that are actually paying attention.
The inversion that takes place
This is where it gets fascinating for finance leaders, because AI has effectively turned the entire strategic logic of the build or buy decision upside down.
The aged model looked something like this:
-
Define the need.
-
Decide whether to build or buy.
However, defining the need took forever and required deep technical knowledge, otherwise you could waste money implementing trial-and-error vendors. You looked through countless demos, trying to imagine if it actually solved your problem. You would then negotiate, implement and migrate all your data and workflows to the recent tool, and six months and six figures later you would discover whether you were actually right (or wrong).
Now the whole sequence is reversed:
-
Build something lightweight with AI.
-
Employ it to understand what you really need.
-
Then decide whether to buy (and you’ll know exactly why).
This approach allows for controlled experiments. You’ll know if the problem even matters. You’ll discover which features provide value and which just look good in demos. Then you go shopping. Instead of letting some third-party vendor sell you what you need, the first thing you need to do is figure out if you even have a need.
Consider how many software purchases you’ve made that, in hindsight, solved problems you didn’t actually have. How many times after three months of implementation have you wondered, “Wait, is this really helping us or are we just trying to justify what we spent?”
Now, once you’ve made the purchase, you ask yourself, “Will this solve the problem better than what we’ve already proven we can build?”
This one rephrase changes the entire conversation. Now you show up on calls to suppliers informed. You ask tougher questions and negotiate from a position of strength. Most importantly, you avoid the costliest mistake in enterprise software: solving a problem you never actually had.
A trap you must avoid
As this recent opportunity presents itself, I watch companies head in the wrong direction. They know they have to be native AI, so they go shopping. They are looking for AI-powered tools, filling their stack with products with GPT integration, a chatbot UI, or “AI” embedded on the marketing page. They think they are changing, but they are not.
Remember what physicist Richard Feynman called it the science of cargo cult? After World War II, islanders in the South Pacific built imitation airports and control towers, imitating what they had seen during the war, in the hope that planes full of cargo would return. They had all the exterior forms of an airport: towers, headsets, even people posing as air traffic controllers. But no plane landed because form was not function.
This is exactly what is happening with AI transformation in boardrooms around the world. Leaders buy AI tools without asking whether they significantly change the way work is done, permissions and what processes they unlock.
They built a runway, but the planes don’t show up.
And the whole market is set up in such a way that you will fall into this trap. Everything is now being touted as artificial intelligence, but no one seems to care what these products actually do. Every SaaS product has been hooked up to a chatbot or auto-fill feature and labeled as AI, which has lost all meaning. It’s just a checkbox that providers need to tick, whether or not it creates real value for customers.
Fthe recent superpower of the inance team
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 place six-figure bets on the sales deck. You can test things out and really learn something before you spend money.
Here’s what I mean: If you’re evaluating vendor management software, prototype the basic workflow using AI tools. Find out if you’re solving a tool or process problem. Consider whether you need the software at all.
This doesn’t mean you’ll build everything in-house – of course not. In most cases, you will end up making the purchase anyway, and there’s nothing wrong with that because enterprise tools exist for good reasons (scale, support, security, and maintenance). But now you’ll be buying with your eyes wide open.
You will know what “good” looks like. You’ll show up to demos who already understand edge cases, and after about 5 minutes you’ll know if they actually understand your specific problem. You will implement faster. You will negotiate better because you are not completely dependent on the supplier’s solution. And you will choose it because it is truly better than what you can build yourself.
You’ll already have the shape of what you need mapped out, and you’ll just be looking for the best version of it.
A recent paradigm
For years, the mantra was: build or buy.
Now it’s sleeker and much smarter: create to find out what to buy.
And this is not some future state. It’s already happening. Right now, a customer representative is using AI to fix a product issue they noticed a few minutes ago. Elsewhere, the finance team is prototyping its own analytics tools because it realized they could iterate faster than writing down engineering requirements. Somewhere the team realizes that the line between technical and non-technical has always been more cultural than fundamental.
Companies that embrace this change will move faster and spend smarter. They will know your operations more deeply than any other supplier. They will make fewer costly mistakes and buy better tools because they truly understand what makes them good.
Companies that stick to the aged playbook will continue to review vendor offers and nod at budget-friendly proposals. They will debate the schedule and constantly confuse professional decks with real solutions.
Until someone on their team opens their laptop and says, “I built a version of this last night. Want to check it out?” and show them something they built in two hours that delivers 80% of what they’re willing to pay six figures for.
And just like that, the rules change for good.
Siqi Chen is the co-founder and CEO of Runway.
Read more in our guest authors. You might also consider submitting your own entry! See ours guidelines here.