When a leadership team asks me today "should we build this or buy it?", I answer differently than I did a few years ago. Not because I changed my mind on the framework. The world around it changed.
In the article Buy vs Build: SaaS or Custom AI Investment? (Part 1) I framed the choice between renting packaged software and building custom in essentially binary terms. That framework still holds. What shifted is the economics of one side of the decision. Building used to be expensive: a team, months, capital upfront. For simpler solutions that no longer holds. It sounds like a simplification, but it actually made the decision harder, not easier.
This part is about what AI did to the buy-vs-build choice. In short: the entry cost of building dropped for a slice of solutions, packaged software absorbed AI in the meantime, and that moved both the tipping point and what the real trap is. The point is not that "everything is now cheap and fast." The point is that the line where each path pays off has moved, and so has what to watch out for.
Two things moved at once, not one: the entry cost of building simpler solutions, and what packaged software can do. When only one side of a choice moves, deciding is easier. When both move, each in a different direction, it is harder. Take them one at a time.
The entry cost of building simpler solutions dropped
Start with what is genuinely cheaper. A simple internal tool, an integration between systems, or a pilot version is far faster and cheaper to build than before. AI tooling helps: no-code assistants like Claude.ai or its Cowork mode for people who do not want to write code, AI app generators like Base44 or Lovable, automation platforms like n8n for wiring up processes, and AI-assisted development (vibe coding: you describe the intent, AI generates the code, you correct it) where real software is needed.
The key point: none of these options is a universal answer. The choice depends on the brief. A no-code assistant covers user-facing tasks and quick prototypes. An automation platform handles system-to-system wiring over APIs and process flows. Custom software with AI-assisted development steps in where the solution is too specific for any packaged tool to cover. I will come back to splitting by situation in the decision section.
The other side holds too. Some things that used to take months still take months. Complex AI diagnostics, serious data management, or anything mission-critical are not a weekend job, and technically specialized work is still worth delegating externally. A cheaper entry point does not mean you can do everything in-house and immediately.
This is where many articles would stop, with "so build it yourself." That would be a mistake.
Many SaaS tools absorbed AI
While building got cheaper for simpler solutions, packaged software got AI baked in natively. A lot of SaaS tools now ship with what you had to build a custom layer for two years ago. That moves the line the other way.
Example: "we want smarter search and summarization across our documentation" was a decent custom-build candidate in 2024. Today many off-the-shelf tools do it out of the box, and a custom build only makes sense when that knowledge base is itself your competitive advantage. Where custom used to win, an off-the-shelf AI solution often wins now. The shift runs both ways, which is why the decision got sharper, not simpler.
The hidden debt after cheap solutions land
Cheap to build does not mean cheap to own. This is the part the hype around vibe coding leaves out, and it is the part that decides.
AI generates working code fast. What it does not generate as reliably is code that is secure and code a human other than the model that wrote it will still understand a year from now. The more code is produced this way, the more rides along unseen: vulnerabilities, unhandled dependencies, decisions nobody documented. For an internal tool over your own data that is fine. For anything touching customers, billing, or sensitive data, it is a risk that stays invisible until it blows up.
Add maintainability to security. From what I see at firms, the most expensive part is not building it, but keeping it running, handing it over, and fixing it when it breaks and the original author is gone. A solution nobody in the firm can maintain is not an asset. It is a future problem with a low purchase price.
That writing code is only the smaller part of the work, and that the bulk of the cost sits in operating, maintaining, and transferring risk, was also argued by INSEAD finance professor Lily Fang in her analysis of why firms will not start building everything in-house just because AI lets them.
How to actually decide
When to buy a license
- The problem is standard and proven, and you hold no competitive advantage in how you solve it.
- An off-the-shelf AI solution now covers what used to need a custom layer and makes more economic sense.
- You have no one internally to maintain a custom solution long term. Then a license or a partner is cheaper than a cheap build nobody will fix.
When to build custom
- The solution is specific, wired into your data or processes, and part of your competitive advantage.
- An off-the-shelf tool would force you to bend your own processes hard into its template, with negative consequences.
- You expect someone in the firm to take it over and operate it. Logic, methodology, and prompts are portable between tools, but operations and maintenance need an owner.
That is the decision on the technical and business axis. Just as important is how much of your know-how is in the solution, the kind you would struggle to hand outside.
- Technically simple but process-non-transferable: a plain ERP or CRM bent to your own processes that you would spend weeks explaining to a vendor. Build it in-house, even if it is technically trivial. Not for the engineering, for the non-transferable know-how.
- Technically hard but domain-light: smart categorization over a broad data base. Hard to solve, but no deep process know-how is in it. Delegate it out, straight through the technical complexity; the vendor need not understand your business, only the problem.
So the question is not just "is it hard," but "how much of our non-transferable know-how is in it, and who keeps it running after us."
A case from practice: an agent for inbound leads
Take an illustrative but realistic case. A construction firm gets inquiries by email and wants an agent that captures the inquiry, looks up matching items in its own service-and-product catalog, and generates a PDF quote with a personalized reply.
Technically that is nothing remarkable today. What decides is the second axis: this firm has its own catalog structure, its own pricing logic, and its own quote format. That is exactly the "technically simple but process-non-transferable" case. Explaining that know-how to a vendor would take longer than building the whole thing. So this calls for a custom solution, built on an automation platform plus an AI tool, a matter of days, not months.
But the other side holds just as strongly. If that firm had a fully standard quoting process with no proprietary logic, it falls into the "buy off-the-shelf" quadrant. And even in the winning variant the maintenance condition applies: once the agent touches prices and goes out to a customer, someone in the firm has to own it. "Worth building custom" does not mean "build it over a weekend and forget it."
What to take away
The framework from the article Buy vs Build: SaaS or Custom AI Investment? (Part 1) still holds. AI moved the line where each path pays off and added a hidden cost to custom that you do not see on the invoice. But the main distinction is not "how hard is it." It is "how much of our non-transferable know-how is in it, and who keeps it running after us." That is what shifts whether you build in-house, delegate out, or buy off-the-shelf.
For the wider map of AI decisions, see the article What decisions usually wait for you when deploying AI. A structured comparison of the options and a recommended path is what solutions architecture delivers.
If you are weighing exactly this decision and want an independent read on whether to build, delegate out, or buy, I am happy to talk it through.
Schedule a 30-min discovery call →
/ Terms in this article /
