By Marty Cagan · svpg.com · LinkedIn
Cagan argues that the build-versus-buy question, long familiar in IT and product teams, is being reshaped by generative AI and user-programming tools like Lovable and Bolt. Despite hype that everyone will build and SaaS will die, he contends enterprise software is hard to replace because of thousands of embedded business rules and logic that most non-technical builders don't understand. He expects a future of 'yes to both': companies keep buying valuable component services, but those services will be accessed by both humans and AI agents, enabled by protocols like Anthropic's MCP. He closes by stressing that the hard part of software has always been discovering the right thing to build, not building it.
01Key takeaways
- Treat build-versus-buy as a spectrum, since most purchased tools still need customization to fit your business.
- Before replacing enterprise software, map the business rules and logic it encodes, which are often undocumented.
- Expect business services to be consumed by both humans and AI agents, so design integrations accordingly.
- Watch for protocols like MCP that let software discover and use business services programmatically.
- Invest in problem discovery; building and shipping is rarely the hardest part of creating a solution.
02Key sections
- Build vs buy, historically
- The classic trade-off weighs core competency, cost, and maintenance, and in practice most buys end up requiring customization. Non-technical staff long depended on IT backlogs.
- User programming's rise
- From VisiCalc and spreadsheets through Visual Basic and low-code tools, end-user programming has steadily expanded, and generative AI now makes English the programming language.
- Why SaaS isn't doomed
- Enterprise software encodes thousands of business rules covering policy, compliance, and finance that are hard to discover and rarely documented, so replacing it is far harder than it looks.
- Software used by agents too
- Future business services will be consumed by AI agents and custom workflows, enabled by a standard protocol such as MCP that lets computers read and act on business services.
- The real lesson for non-technical builders
- As people build more ambitious tools, they will need the discipline product teams already have, because discovering the right problem and solution is the hard part, not building.
03From the post
“A partnership dedicated to teaching best practices to product teams and product leaders”
04Frameworks mentioned
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.