__Basware __CEO Jason Kurtz points to an automotive manufacturer that spent 18 months building a custom AI system for expense reporting. He estimates a specialist product could have solved the same problem in about 12 weeks, at one-tenth the cost.
Companies should be getting less patient with projects like that one. Capable models are now widely available, so “we built it ourselves” only holds up when owning the technology gives the business an advantage.

Adoption has moved faster than that discipline. __McKinsey’s 2025 State of AI survey __found that 88% of respondents said their organizations regularly use AI in at least one business function. Thomson Reuters’ 2025 Future of Professionals research found that only 22% of organizations had a visible, defined AI strategy.
Kurtz argues that companies need to draw a harder line before they spend: develop AI when it contributes directly to what makes the business competitive, and deploy specialist software when the goal is to make a standard business function work better.
Netflix has good reason to own and keep improving the technology behind its recommendation system. What viewers discover affects engagement and retention, which puts that capability close to the product customers pay for. An automotive manufacturer gains no comparable advantage from inventing its own expense-reporting system.
“The real risk in the AI investment story isn’t that companies are spending too little, it’s that they’re spending in the wrong places,” Kurtz said.
Why Building AI for Standard Work Costs More Than the Pilot Shows
There are legitimate reasons to build internally. A company may hold proprietary data no one else has, or a use case closely tied to its product. In those cases, owning the system protects knowledge competitors can’t easily reproduce.
The math changes when the work is something thousands of other businesses also have to do.
Accounts payable is one example. Processing an invoice hardly sounds like it calls for deep specialist technology. But once the system has to handle ERP integrations, supplier records, tax requirements and the exceptions that break simple automation, the engineering problem grows considerably.
A general-purpose model doesn’t come knowing those processes. Building internally means creating the surrounding workflow too, then maintaining it as regulations change and as production data behaves differently from the clean dataset used in the pilot.
“The quickest path to value is picking processes that are highly manual and repetitive and where lots of data exists to be leveraged to educate AI,” Kurtz said. “Often, the fastest path is using AI embedded into processes and systems already used by teams.”
The second half of that advice tempers much of the enthusiasm around custom AI. A proof of concept can make internal development look cheap. Production adds integration work and monitoring, and someone has to own the failures when the model makes a decision the business can’t defend.
Process Data, Not the Model, Is the Competitive Advantage
As foundation models become easier for competitors to access, one more in-house AI implementation counts for less. The assets that are harder to copy are the data around a specific process and the accumulated knowledge of how that process fails inside real organizations.
Finance shows the difference clearly. A model can produce an answer that looks right, but the business still needs to know why a financial decision was made and whether an auditor can reconstruct it later. Accuracy alone doesn’t cover that.
So the build-versus-buy decision is also a question of what a company wants to be responsible for.
If AI defines the customer experience or turns proprietary information into something competitors can’t match, the time spent developing it can be justified. If the project exists because every company has to process expenses, route invoices or produce financial reports, rebuilding specialist software in-house deserves much closer scrutiny.
Owning more code is not a strategy on its own. Sometimes the better AI decision is recognizing which code someone else should already have built.
