Build vs Buy in the AI Era: Why… | The VC Corner Summary

1. Key Themes

Theme 1: AI collapsed the cost of making software, not the cost of owning it

"Software has 2 costs: making it and owning it. AI coding tools cut the first one, so owning the tool is now the bigger bill."

Ownership costs are large, recurring, and human-dependent

The article lists six recurring ownership jobs (security patches, dependency upgrades, 3 a.m. fixes, feature requests, audits, UI refreshes) and anchors them in survey data.

"In Stripe's Developer Coefficient survey with Harris Poll, developers estimated that their teams spend 17.3 hours of a 41.1-hour week on maintenance work like debugging and refactoring. That's about 42% of their time, and the survey dates from 2018, so it's the baseline AI coding tools started from."

AI only helps at the margins because accountability is a human job:

"A tool can flag a newly announced vulnerability, but a person still has to decide whether it matters to your business, and a person has to take responsibility when something goes wrong."

AI productivity gains are easy to overestimate

"In METR's 2025 randomised trial, 16 experienced open-source developers took 19% longer on real tasks when they used AI tools, while believing AI had made them 20% faster."

The author caveats that METR says the tools have likely improved since, but notes the perception gap "still deserves a line in your spreadsheet."

Theme 2: Internal builds look cheap because their costs are invisible

Licenses are visible, maintenance is buried

"A software licence is a visible budget line that the finance team reviews at every renewal."

"The maintenance of an internally built tool, on the other hand, gets buried inside other budget lines. It stays invisible until something breaks."

SaaS budget pressure is real and pushes teams toward building

"In Zylo's 2026 index, 78% of IT leaders reported unexpected charges tied to AI features or usage-based pricing, and 61% cut projects because of unplanned SaaS cost increases."

"The average organisation in Zylo's 2026 SaaS Management Index spends $55.7 million a year on SaaS, up 8% in a year."

Theme 3: Vendors keep a structural advantage through amortization and track record

Vendors get the same AI discount and spread upkeep across customers

"Vendors use the same AI tools their customers do, so their costs fall too. And they spread the cost of maintaining their product across their whole customer base. HubSpot, for example, reported 306,446 customers at the end of June 2026. A company building its own CRM carries that same upkeep alone."

Bought AI tools succeed about twice as often as internal builds

"In MIT NANDA's The GenAI Divide: State of AI in Business 2025, AI tools bought from specialised vendors succeeded about 67% of the time, while internal builds succeeded about a third of the time."

The figures are self-reported, and the report's lead author observed that "almost everywhere we went, enterprises were trying to build their own tool."

Many internal builds will be cancelled

"Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, with escalating costs and unclear business value among the reasons."

Theme 4: SaaS will bifurcate between "convenience" and "liability"

"Where a product is mostly code, cheap AI development will probably bring lower prices and new, cheaper competitors, which makes building your own even less attractive."

"Where a product is mostly about carrying risk, such as login and identity systems or payment processing, cheap code changes very little. The expensive part of those businesses is absorbing the consequences when something goes wrong."

The investment implication:

"Software that takes on someone else's liability is likely to become more valuable, because the more custom glue companies build, the more they need the dangerous parts to be someone else's problem."

Theme 5: Comprehension debt is a new, measurable risk of AI-written code

"AI-assisted building adds a related problem that Addy Osmani calls comprehension debt: the growing gap between how much code exists in your system and how much of it any human genuinely understands."

Evidence from Anthropic's randomised trial

"52 mostly junior engineers learned a new Python library, half of them with an AI assistant. The AI group scored 50% on a quiz about the code they had just written, and the hand-coding group scored 67%. The biggest gap was on debugging questions, which is the exact skill you need the day your internal tool breaks."

How you use AI matters

"Participants who handed the coding over to it averaged below 40%, while those who used it to ask conceptual questions or explain the code scored 65% or higher."

2. Contrarian Perspectives

"Cheap code" makes buying more attractive, not less

The consensus view is that if AI makes building cheap, the case for buying software weakens. The article argues the reverse: build costs fell, but the larger, recurring ownership cost did not.

"For most business software, the second bill is now far larger than the first, because AI tools have cut the first one sharply."

Supporting evidence: vendors amortize maintenance across thousands of customers, and bought tools outperform internal builds in MIT NANDA's data (about 67% vs. about a third).

The bull case for "convenience" SaaS is weaker than the bull case for "liability" SaaS

Rather than "SaaS is dead" or "SaaS is fine," the article splits the category.

"Weak horizontal tools that mostly organise information or route simple tasks are the ones facing a harsher buyer question. Software that sells convenience is exposed."

"The more custom glue companies build, the more they need the dangerous parts to be someone else's problem."

Internal builds may be the more dangerous financial choice because their costs hide

"That's why building tends to win: its costs are harder to see. And an invisible cost rarely gets questioned."

The argument is that build-vs-buy decisions are biased by accounting visibility rather than economics, since a SaaS renewal is reviewed every year while engineer time spent on upkeep never gets a line item.

3. Companies Identified

Hyphenate

Description: Autonomous finance platform for the office of the CFO
Why mentioned: Sponsor; just raised a Series A; positioned as an example of finance work where DIY gets expensive
Quotes:

"Hyphenate just raised $45 million in Series A funding to scale autonomous finance for the office of the CFO." "Finance is where 'we'll build it ourselves' gets expensive fast, because every reconciliation needs someone accountable for it."

HubSpot

Description: CRM and marketing software vendor
Why mentioned: Case study of amortizing maintenance across a large customer base
Quotes:

"HubSpot, for example, reported 306,446 customers at the end of June 2026. A company building its own CRM carries that same upkeep alone."

Zylo

Description: SaaS management platform that publishes an annual SaaS index
Why mentioned: Source for SaaS spend growth and AI-related pricing surprises
Quotes:

"The average organisation in Zylo's 2026 SaaS Management Index spends $55.7 million a year on SaaS, up 8% in a year."

Stripe

Description: Payments infrastructure company
Why mentioned: Its Developer Coefficient survey (with Harris Poll) is the source for the maintenance-time statistic
Quotes:

"Developers estimated that their teams spend 17.3 hours of a 41.1-hour week on maintenance work like debugging and refactoring."

METR

Description: AI evaluation research organization
Why mentioned: Randomised trial showing experienced developers were slower with AI while believing they were faster
Quotes:

"16 experienced open-source developers took 19% longer on real tasks when they used AI tools, while believing AI had made them 20% faster."

MIT NANDA

Description: MIT research initiative behind The GenAI Divide: State of AI in Business 2025
Why mentioned: Data on success rates of bought vs. built AI tools
Quotes:

"AI tools bought from specialised vendors succeeded about 67% of the time, while internal builds succeeded about a third of the time."

Anthropic

Description: AI lab
Why mentioned: Ran the randomised trial on AI assistance and coding comprehension
Quotes:

"In a randomised controlled trial by Anthropic, 52 mostly junior engineers learned a new Python library, half of them with an AI assistant."

Gartner

Description: Research and advisory firm
Why mentioned: Forecast on agentic AI project cancellations
Quotes:

"Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027."

Fortune

Description: Business media outlet
Why mentioned: Reported on the MIT NANDA findings and interviewed its lead author
Quotes:

"AI tools bought from specialised vendors succeeded about 67% of the time... as Fortune reported."

4. People Identified

Addy Osmani

Description: Engineer and writer who popularised the term "comprehension debt"
Why mentioned: Coined or popularised the concept central to the article's risk argument
Quotes:

"AI-assisted building adds a related problem that Addy Osmani calls comprehension debt: the growing gap between how much code exists in your system and how much of it any human genuinely understands."

Aditya Challapally

Description: Lead author of MIT NANDA's The GenAI Divide report
Why mentioned: Observed the widespread enterprise tendency to build rather than buy AI tools
Quotes:

"Aditya Challapally, the report's lead author, told Fortune that 'almost everywhere we went, enterprises were trying to build their own tool.'"

Ruben Dominguez

Description: Author of related VC Corner pieces on startup costs and the SaaS debate
Why mentioned: Wrote the linked articles on startup costs approaching zero and why "SaaS is dying" is overstated
Quotes:

"The Cost of Starting a Startup Is Approaching Zero" "The 'SaaSpocalypse' Was a Panic, Not a Prophecy"

5. Operating Insights

Give every internal tool a "shadow budget line"

Counter the accounting bias toward building by making the hidden cost visible.

"If you decide to build, give every internal tool that replaces a paid product a shadow budget line. Set it at a reasonable estimate of its maintenance cost, and review it on the date the licence would have renewed."

Ask four questions before writing code

"How much breaks if it fails or gets hacked?... Who, by name, will maintain it three years from now?... At what point will the company switch to a commercial product?... Who has the authority to shut it down?"

The author flags the last one as most often forgotten: "Internal tools rarely die on their own, and owning something includes the right to end it."

Build selectively, buy anything catastrophic, and use AI to learn rather than delegate

The article names four good build candidates: small low-risk internal tools, tools matched to a team's unique workflow, glue between unconnected systems, and temporary bridges.

"Build selectively: bridges and experiments with a written exit. Buy anything whose failure would be catastrophic."

On usage, the Anthropic data suggests asking AI conceptual questions and for code explanations (65%+ quiz scores) rather than handing over the coding entirely (below 40%).

6. Overlooked Insights

AI-built code's comprehension problem appears immediately, not years later

The usual worry is a departing author leaving behind unreadable code. The article notes the issue is already present on day one.

"Forget two years later. With AI-built tools this risk shows up almost immediately, because the code can be hard to follow even while its own author is still at the company."

Internal builders may be sitting on unrecognized startup ideas

A brief aside suggests the build-vs-buy question can double as a source of venture-scale ideas.

"You could argue that engineers who figure out solutions to problems this big internally should just go and build their own startup. And you'd be right. Plenty of great startups began exactly that way."