AI, SaaS, and "Build vs. Buy" Shift Core Competencies

The following blog post analyzes a podcast transcript from ShopTalk, Episode 706: "Can You Vibe Code a Canvas App, Geolocation Part 2, & CodePen v2." It synthesizes key insights through the lens of systems thinking and consequence mapping, highlighting non-obvious implications and the evolving economics of software development and tool creation.

This analysis is crucial for product managers, developers, and business leaders grappling with the changing landscape of AI-assisted development, SaaS economics, and the strategic value of core competencies. By understanding the downstream effects of seemingly simple decisions--from choosing third-party services to leveraging AI for internal tools--readers can gain a strategic advantage in navigating these complex trade-offs, avoiding the pitfalls of short-sighted optimization, and identifying opportunities for sustainable competitive differentiation.

The Shifting Sands of "Build vs. Buy": AI, SaaS, and the New Economic Realities

The conversation on ShopTalk Episode 706 dives deep into a fundamental tension in the tech world: the perennial "build versus buy" dilemma. While AI tools are dramatically lowering the barrier to entry for creating custom software, the episode reveals a more complex reality than a simple cost-benefit analysis. The true implications lie not just in the immediate expense, but in the long-term consequences for maintenance, core competency, and the very economics of the software-as-a-service (SaaS) model.

The speakers explore how AI, or "vibe coding" as it's colloquially termed, is democratizing the creation of micro-utilities and internal tools. This raises questions about the future of specialized SaaS products, particularly those with high price points. The episode highlights how companies like CodePen are re-evaluating their own build-versus-buy decisions, opting to bring WebSocket infrastructure in-house rather than relying on a third-party service, driven by the sheer scale of their operations and the prohibitive cost of external solutions. This shift suggests a future where companies with strong technical foundations might find it more economical and strategically advantageous to build rather than buy, even for components that were once considered commoditized.

Furthermore, the discussion around TL Draw's decision to move its extensive testing suite to a private repository underscores a critical consequence: open-source, while fostering innovation, can also become a liability when it enables competitors or malicious actors to easily replicate or undermine a product. This points to a new strategic consideration where the "technical moat" is no longer solely about code complexity but also about controlling access to the very mechanisms that define product quality and differentiation.

The Economics of "Free" and the Erosion of SaaS Moats

The traditional SaaS model, often built on a freemium strategy with enterprise upselling, is facing unprecedented pressure. As AI makes it easier and cheaper to replicate functionality, the economic justification for high-priced, specialized SaaS products begins to crumble. The episode illustrates this with examples of logging and analytics companies, where the cost for a small company can be astronomical. This economic reality is forcing a reevaluation: if a company can "vibe code" a functional equivalent of a critical tool in days or weeks for minimal cost, why pay a premium for a third-party solution?

"The economics is now like, if I can send Claude off for 30 minutes or Claude bot or whatever to do it over a couple days like and I do have a Monday.com or I do have a, you know fake Salesforce like what does that do?"

This quote encapsulates the core of the problem. The perceived value of established SaaS products is being challenged by the rapid, low-cost creation of alternatives. The implication is that SaaS companies can no longer rely solely on their existing feature set or scale to justify their pricing. Instead, they must increasingly focus on what truly differentiates them--perhaps superior user experience, specialized integrations, or a deeper understanding of a niche market that AI cannot easily replicate. The episode suggests that the "build" side of the equation is becoming increasingly attractive, not just for internal tools but potentially for entire product categories.

The Double-Edged Sword of Open Source and Public Tests

The TL Draw situation serves as a potent case study in the unintended consequences of open-source development. While the project's extensive, publicly available test suite was a testament to its quality and a valuable resource for developers, it also became a blueprint for replication. The decision to move these tests to a private repository signals a strategic shift, acknowledging that in an AI-driven world, the transparency that once fueled innovation can now accelerate commoditization.

"If you have the tests up, you can clone the site like you're saying and get like a one to one on the like quality and all the edge cases they've hit and you're basically like you threw the tests, you can reverse engineer their thing and build your own thing."

This highlights a new paradigm: the "technical moat" is shrinking. For companies like TL Draw, which offer valuable SDKs and open-source tools, the challenge is to maintain a competitive edge when the underlying technology and quality benchmarks are so readily accessible. The episode suggests that the future may involve a more guarded approach to open-sourcing critical components or test suites, forcing developers to either pay for premium versions or invest significant effort in rebuilding functionality from scratch, a task that AI is rapidly making less daunting.

HTML's Evolving Role and the Accessibility Paradox

The discussion around the new HTML <geolocation> element and the evolving capabilities of CSS reveals a fascinating tension between declarative HTML, JavaScript's role, and the critical imperative of accessibility. While the <geolocation> element simplifies the initial permission prompt, its utility is limited without JavaScript to act on the data. This raises questions about the true value of adding such declarative elements if they don't fundamentally change the interaction model.

More intriguingly, the episode touches upon CSS styling constraints applied to interactive elements like the geolocation button. The browser's behavior--either preventing certain styles that compromise legibility or disabling the element entirely if styles are applied that break its functionality--introduces a new class of "bugs" or, more accurately, design constraints.

"It either doesn't allow you to do it at all like translate truncates what you're able to do to keep it in quote unquote accessible ranges... or lets you do it and then disables the button. It's so weird."

This paradox is significant. The intention is to prevent accessibility failures, such as invisible buttons or unreadable text. However, the implementation--where styles are applied but the functionality is disabled--can be confusing for developers. It suggests a future where HTML and CSS are not just about presentation but also about enforcing functional and accessibility guardrails, sometimes in ways that are not immediately intuitive. This forces developers to think not just about how an element looks, but how the browser interprets its styling and its impact on user interaction, adding a new layer of complexity to front-end development.

The Dopamine Hit of AI vs. the Grind of Maintenance

The episode touches upon a common pitfall of AI-assisted development: the intoxicating ease of generating code versus the often-overlooked reality of maintenance and long-term support. The example of someone using AI to "poach" data from Jeremy Keith's Session website for a fiddle tune app illustrates the "dopamine hit" of instant gratification. The AI can quickly generate a functional version, but the hard questions--where does new data come from? How is it maintained? How is it kept up-to-date?--remain.

"What's the plan for getting new stuff? How does it keep it updated? How do you keep it, you know, like all that stuff's hard questions and like the maintenance stuff."

This is where the "build versus buy" math becomes critical. While AI dramatically lowers the upfront cost of building, it doesn't eliminate the ongoing cost of maintenance, updates, and support. For businesses, especially those without a clear core competency in the area being built, the long-term burden of maintaining AI-generated code can quickly outweigh the initial savings. This suggests that while AI is a powerful tool for rapid prototyping and creating micro-utilities, it doesn't negate the fundamental principles of product development, where sustained effort and strategic focus are paramount for long-term success.

Key Action Items

• Re-evaluate SaaS Subscriptions: Conduct a quarterly review of all third-party SaaS subscriptions, especially those with high costs or essential functionality. Assess the feasibility and long-term cost-benefit of bringing any of these capabilities in-house, particularly if core technical expertise exists.
  • Immediate Action: Identify the top 1-2 most expensive or strategically critical SaaS tools for re-evaluation.
• Assess AI Tooling for Internal Utility: Explore and pilot AI tools for generating internal utilities, scripts, or boilerplate code. Focus on areas where current workflows are inefficient or where custom tools could provide significant productivity gains.
  • Immediate Action: Identify one repetitive or manual task that could be automated with AI-generated scripts.
• Develop a "Technical Moat" Strategy: Beyond code, identify unique data, proprietary algorithms, or deep domain expertise that AI cannot easily replicate. Articulate how these differentiators will be protected and leveraged.
  • This pays off in 12-18 months: Begin documenting and strategizing around unique company assets.
• Prioritize Maintenance in AI-Assisted Projects: For any internal tools or prototypes built with AI, explicitly budget and allocate resources for ongoing maintenance, testing, and updates from the outset.
  • Over the next quarter: Establish a process for reviewing and maintaining AI-generated code.
• Embrace Declarative HTML for Permissions: When implementing features requiring user permissions (like geolocation or camera access), leverage new declarative HTML attributes where available to simplify user interaction and improve the permission flow.
  • Immediate Action: Research and implement declarative HTML for any new features requiring user permissions.
• Understand Browser-Enforced CSS Constraints: Be aware that browsers may enforce styling limitations on interactive elements to ensure accessibility. Test styles thoroughly and be prepared for functionality to be disabled if styles compromise legibility or integrity.
  • Immediate Action: When styling interactive HTML elements, test common accessibility scenarios (e.g., contrast ratios, button visibility).
• Foster a Culture of Long-Term Value: Encourage teams to consider the downstream effects of their technical decisions, prioritizing durable solutions and core competency development over short-term gains from readily available AI solutions.
  • This pays off in 12-18 months: Integrate long-term consequence analysis into project planning and review processes.