Maybe Before We Buy Another Platform, We Try Building It?
Build vs. Buy is missing a third option: Try. Sometimes spending the money is absolutely the right decision — I'd just like us to find that out before we spend it.
I’ve noticed a funny pattern in technology.
Someone identifies a problem.
We talk about the problem.
We have a meeting about the problem.
Maybe a second meeting to make sure we all agree that yes, this is definitely a problem.
And then someone says:
“We should look at vendors.”
And suddenly we’re on a demo with a company selling us a $100,000-a-year solution.
And I’m sitting there thinking:
“Wait. Did we ever figure out if this is actually hard to build?”
I’m Not Anti-Vendor
Let me get this out of the way.
There are a lot of things companies should buy instead of build.
There are mature platforms solving complicated problems that would be completely ridiculous to recreate internally.
Nobody needs me disappearing for a weekend and announcing:
“Good news. I built us an ERP.”
Please stop me.
But I’ve also encountered the opposite.
Problems where the assumption that we need to buy something happens before anyone seriously asks whether we could just… solve it.
Sometimes with tools and infrastructure we already have.
Build vs. Buy Needs a Third Option
We usually talk about this decision as:
Build vs. Buy.
But I think there’s something missing between those two.
Try.
Don’t commit to building it.
Don’t commit to buying it.
Just see what’s possible.
Give someone a couple of days to poke at the problem.
Connect the API.
Pull the data.
Build the ugly interface.
Automate the annoying part.
See how far you get.
Maybe the answer becomes incredibly obvious:
“Yeah, absolutely not. Buy the software.”
Great!
That’s useful information.
But sometimes the answer might be:
“Wait. This is basically it?”
Also useful information.
AI Has Made “Try” Really Cheap
This is one of the biggest changes AI has created for me.
The cost of finding out whether something is possible has dropped dramatically.
Not the cost of building good production software.
That’s different.
But the cost of answering:
“Could this work?”
That’s gotten really cheap.
You can prototype the workflow.
Test the integration.
See whether the data exists.
Build enough of the interface to put it in front of someone.
And suddenly you’re not having an abstract conversation about whether something could work.
You’re clicking it.
That’s a pretty big shift.
Sometimes We Buy a Battleship Because We Needed a Canoe
I’ve seen companies look at giant platforms when the actual problem they’re trying to solve is relatively small.
And, naturally, the platform does everything.
Analytics!
Automation!
AI!
Workflows!
Dashboards!
Probably makes toast!
Then you actually look at what the business needs from it and realize:
We’re going to use four features.
Maybe five if everyone gets ambitious.
That doesn’t automatically mean buying it is wrong.
Maintenance matters.
Security matters.
Support matters.
Engineering time matters.
But the size of the solution should probably have some relationship to the size of the problem.
Sometimes we genuinely need the battleship.
Sometimes we just need to get across the lake.
Internal Context Is Worth Something
There’s also an advantage to building a prototype internally that doesn’t get talked about enough.
You already know the weird stuff.
Every company has it.
The process documented in the SOP isn’t quite the process people actually follow.
One system calls something a “client.”
Another calls it an “account.”
Someone has a spreadsheet that nobody is supposed to need but the entire operation will apparently collapse if it disappears.
There’s always a:
“Oh yeah, except when this happens…”
A vendor has to learn all of that.
Someone internally already lives in it.
That context can make it surprisingly easy to prototype something that fits the actual workflow instead of the theoretical one.
And No, Vibecoding Doesn’t Replace Engineering
This is where I think the conversation needs some sanity.
Being able to prototype something quickly does not mean:
“Great! Fire the engineers!”
Please don’t.
A prototype proves the idea.
Engineering makes the idea trustworthy.
Those are different jobs.
I can get something surprisingly close to an MVP using AI, existing systems, APIs, and enough determination.
That doesn’t mean I should be responsible for every architectural decision required to run it at scale for the next ten years.
The prototype can answer:
Does this solve our problem?
Then engineering gets a much better starting point.
Not:
“Here’s a vague requirement. Good luck.”
But:
“Here’s the workflow. Here’s what we tested. Here’s what users actually need. Here’s what worked. Here’s what definitely needs to be rebuilt.”
That’s a much more interesting version of Build vs. Buy.
Maybe We Still Spend the Money
And that’s completely fine.
Sometimes the experiment proves exactly why the vendor costs $100,000.
You start pulling on the thread and discover:
Security.
Compliance.
Permissions.
Audit logging.
Edge cases.
Integrations.
Support.
Scaling.
Suddenly the price starts looking a lot more reasonable.
But now you know why you’re buying it.
You’re not buying software because buying software was the first idea.
You’re buying it because you tested the alternative and made an informed decision.
Just Try First
That’s really the lesson I’ve taken from encountering this over and over.
Before assuming a problem requires another platform, another license, another implementation, and another recurring line item…
Try.
See how complicated the problem actually is.
See what you already have.
See what your internal people can prototype.
See what AI makes possible that wasn’t practical three years ago.
Maybe you build it.
Maybe you buy it.
Maybe you discover you didn’t actually need half of what you thought you needed.
Any of those outcomes are better than starting with:
“So, when can the vendor give us a demo?”
Sometimes spending the money is absolutely the right decision.
I’d just like us to find that out before we spend it.