A CEO asked me this last month over coffee in Sydney.
Manufacturing business, around 60 staff, profitable, no CTO. He’d been quoted $180K by a systems integrator, $2,400 a month by a SaaS vendor, and had a very keen 26-year-old on his team volunteering to “just build it with Cursor.”
He wanted me to tell him which one to pick.
I told him he was asking the wrong question, which is a rude thing to say to someone who has just bought you a coffee. But he was. All three quotes were answers to a question he hadn’t defined yet, and the gap between those numbers — $2,400 a month versus $180K — wasn’t a pricing difference. It was three vendors guessing at three completely different scopes.
Here’s the framework I use, across PADISO’s client work and inside my own companies. It starts by throwing out the assumption underneath the question.
This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber.
The old logic is inverted
For twenty years, the buy-versus-build decision ran on one dominant variable: construction cost. Building software was expensive and slow, so you built only what was strategically essential and bought everything else. That was correct advice. I gave it myself for most of my career.
That variable has collapsed.
Roughly 25% of the SearchFit codebase is written by agents — Claude Code and Codex, running against a spec I write and a review I do. Features that would have required three or four engineers now require me and an afternoon of supervision. I’m running three companies from Sydney with a technical team you could fit in a small lift.
So building is cheap now. Which means, counterintuitively, build is no longer the expensive option — and buy is no longer the safe one.
What hasn’t got cheaper is everything around the code:
Integrating with the booking system that hasn’t been updated since 2019
Cleaning the data in the CRM that four different sales managers have used differently
Deciding what the thing should actually do
Owning it when it breaks on a Tuesday
That’s where the money goes now. Every AI project I’ve seen fail — and I’ve been called in to rescue several — failed at integration, data quality, or ownership. Not one failed because the model wasn’t smart enough.
So stop asking “what’s cheapest to build.” Ask “who owns this in eighteen months, and what happens the first time it’s wrong?”
Question one: is it a differentiator or a utility?
The cleanest cut in the whole decision.
Utilities are the things every business in your category needs and none of them win on. Transcription. Email drafting. Meeting notes. Document search. Support ticket deflection. Basic forecasting.
Buy these. Always. Do not let anyone build them for you, in-house or otherwise. There are funded companies with fifty engineers competing to make these cheaper and better every quarter, and you will never out-run them. If someone quotes you $80K to build an internal meeting-notes tool, that’s not an AI project, that’s a hobby with an invoice attached.
Differentiators are the things that encode how your business specifically makes money. The pricing logic your ops director keeps in her head. The way you triage inbound leads because you know which postcodes convert. The compliance workflow that’s specific to your licence. The quoting process that takes your estimator three days.
Nobody sells this. It doesn’t exist as a product, because the market for it is exactly one company. If you try to buy it, you’ll buy a generic platform and spend nine months and a change-request budget bending it into a shape it was never designed to hold.
Most executives get this backwards. They buy a big platform to handle the differentiated work and then build a scrappy internal tool for a utility, because the platform vendor had better sales collateral.
Question two: does it touch your mess?
This is the question that decides more outcomes than any other, and it never appears on a vendor comparison matrix.
Every real business runs on a substrate of legacy systems, half-documented processes, and data that’s technically wrong in ways everyone has quietly agreed to work around. At PADISO we wire agents into that reality — revenue tracking across booking platforms, self-updating Power BI dashboards, email pipelines, orchestration through N8N and custom agent architectures. The AI part is genuinely the easy part now. The hard part is that your “customer” table has three spellings of the same company name and a field called notes2.
If a proposed solution has to touch that mess, you cannot buy your way out of it. No vendor is going to reconcile your data model for a monthly subscription. They’ll give you an API and a Zapier connector and a smile.
If it doesn’t touch the mess — if it’s a standalone tool sitting at the edge of your operation — buying is almost always right.
Ask any vendor one question: “Show me exactly what happens when this reads from our systems and the data is wrong.” Their answer tells you whether they’ve deployed into a business like yours or only into slide decks.
Question three: who gets paged?
An AI system isn’t a purchase. It’s a dependency, and dependencies need owners.
Answer this before you sign anything:
When the agent makes a wrong decision, who finds out — and how fast?
When your CRM vendor changes an API in six months, who fixes it?
When the person who understood the workflow leaves, what’s left behind?
Build in-house only if you have — or are willing to hire — someone who can hold that ownership. Not someone who can write code. Agents write the code. Someone who can specify clearly, evaluate whether the output is correct, and architect systems that don’t collapse under load. That’s a different profile from the one you’re used to hiring for, and it’s rarer than a good developer, not more common.
If you don’t have that person and you’re not ready to hire them, in-house build is how you acquire an unmaintained system with your logo on it.
Buy when the vendor owns the pager, and price the subscription as what it actually is: rent for not having to think about it.
Hire an agency when you need the capability faster than you can hire it, and you have a specific outcome in mind rather than a general desire to “do something with AI.”
The fourth option nobody quotes you for
Most businesses I work with don’t land on any of the three. They land on the combination, which is:
Buy the platform. Build the workflow. Hire someone to wire it together and then leave.
You buy the model access and the infrastructure — you are not training a foundation model, please do not let anyone tell you that you should. You build the thin, specific layer that encodes how your business works, because that layer is the whole point. And you bring in outside help for the twelve weeks it takes to get it into production, with a hard requirement that they hand you documentation, tests, and a runbook on the way out.
That last part is the bit to negotiate hard on, because the agency incentive runs directly against it.
How to buy an agency without getting burned
Since I run one, treat this as a confession rather than a sales pitch.
Buy outcomes, not hours. “Reduce quote turnaround from three days to four hours” is an outcome. “Two senior engineers for six months” is a staffing arrangement with extra steps, and it transfers all the risk to you.
Get IP assignment in writing. Not a licence. Assignment. If the workflow encodes how your business makes money, you own it — including prompts, agent definitions, and configuration, not just source code.
Demand a handover artefact. Documentation, tests, and a written runbook for what to do when it misbehaves, delivered as a milestone, not a favour at the end.
Ask what they run internally. Any agency selling AI transformation should be visibly running on it. If they can’t show you their own agents, their own automations, their own numbers, you’re buying a deck. We fund product bets at SearchFit and Capitaly off PADISO’s consulting revenue, and increasingly the consulting itself is delivered by agents — I’m using AI to build the AI consultancy that funds the AI products. That’s the standard I’d hold any agency to, including mine.
Start with one workflow. Anyone who wants to sell you an eighteen-month transformation programme before proving a single process in production is selling you optionality on their own revenue.
The ninety-day test
Before committing capital in any direction, run this:
Pick one workflow with a number attached to it — hours, error rate, turnaround time, cost per unit.
Measure the baseline for two weeks. If you can’t measure it, you’ve picked the wrong workflow, and you also can’t prove ROI later.
Ship something narrow into production in six weeks. Production, not a demo. A demo proves the model works. Production proves your business works.
Run it for six weeks with a human checking every output.
Then decide buy, build, or agency — with actual evidence about where the difficulty lives.
Ninety days and a contained budget buys you a real answer to a question that no vendor comparison, analyst report, or LinkedIn framework can give you: where in your specific business the friction actually is.
Almost every organisation is wrong about this before they test. They think the problem is the AI. The problem is nearly always the data, the integration, or the fact that nobody wrote down how the process really works.
The one-line version
If it’s a utility, buy it. If it’s how you make money, build it. If you need it faster than you can hire for it, bring in help — but own the output and take the pager back at the end.
And if you genuinely can’t tell which category something falls into, that’s not a procurement problem. That’s a strategy problem, and no amount of spend will fix it.
The company that spends $50K on the right workflow will beat the one that spends $500K on the wrong platform. Every time. I’ve watched it happen from both sides of the invoice.
I’m Kevin — CEO of PADISO and SearchFit, running three companies from Sydney with a two-person engineering team. I write about what the AI-native operating model actually takes, and what breaks. If this was useful, subscribe.