Adding AI to your SaaS without shipping a sparkle button

Moving beyond 'Lazy AI'

The current SaaS landscape is flooded with what can best be described as "Lazy AI"—superficial features that provide little more than a cosmetic upgrade to existing interfaces. For many founders, the impulse is to simply add a "sparkle" icon next to a text box, enabling a generative capability that feels modern but lacks fundamental utility.

The core problem is a failure to distinguish between a feature that adds novelty and one that delivers a meaningful outcome. A useful AI feature should solve a significant user problem, typically by saving a meaningful amount of time.

A cautionary tale:

eBay provides a perfect example of the "sparkle text box" trap. While eBay could use AI to intelligently automate the tedious parts of listing an item—such as extracting the UPC, manufacturer, and year from a photo—they instead implemented a generative text box. A user might click a button to get a slightly more descriptive paragraph, but the process still requires manual entry for the critical, "nitty-gritty" details. This saves perhaps 30 seconds, which is negligible.

To avoid this trap, builders must shift their mindset from "can we add AI?" to "does this solve a problem that justifies the complexity?" The speaker suggests a heuristic: if a feature only saves a user two minutes, it is likely a "lazy" implementation. A successful, outcome-driven feature should target a much higher threshold—ideally saving a user 15 minutes or more of manual labor or cognitive load.

When building, the goal is to identify where the user is currently experiencing friction and use AI to collapse that friction entirely, rather than just decorating the existing struggle with a generative layer.

The Six Functional Patterns

To move away from amorphous "AI implementation" and toward deliberate product design, builders need a mental model. The speaker proposes that almost all AI utility in a SaaS product falls into one of six distinct functional categories. This framework allows product managers to look at their existing workflows and ask, "Which of these six buckets does this problem fit into?"

Detailed Pattern Breakdown

1. Conversational Interfaces This goes beyond simple "chatting." It is about replacing complex, high-friction UI—like a search screen with 15 to 17 different fields, radio buttons, and complex filtering logic—with a plain-English interface. If a user can say, "Show me all US-based agencies with fewer than 10 employees," and the system executes the complex query, you have moved from a "gnarly" filtering screen to a conversational interface.

2. Generation This is the most common and often the "easiest" pattern. It involves producing text, images, or code. The key to making this successful is avoiding "blank page syndrome." Instead of a single empty text box, successful implementations (like SessionLab) offer suggestions or "auto-completers" that guide the user toward what the AI can actually do.

3. Categorization This pattern focuses on sorting. It takes a mass of data—essays, digital assets, or emails—and applies labels. This is a massive time-saver for users managing large volumes of information, such as 3D animators organizing terabytes of files.

4. Ingestion This is one of the highest-value, underutilized patterns. It involves taking "kludgy" or unstructured data—a screenshot of a whiteboard, a handwritten note, or a WhatsApp voice note—and transforming it into "strongly typed" objects in a database. For example, a contractor saying, "I'm out of nails," via a voice note can be automatically converted into a structured material request in a procurement system.

5. Analysis Analysis moves beyond mere data processing to qualitative evaluation. It mimics a human expert by reviewing information and providing a rationale. This could mean a sales tool analyzing a call to see if a representative addressed a customer's specific goals, or a coding tool providing a summary of a junior developer's patterns and recommendations for improvement.

6. Agentic Interfaces This is the "bleeding edge" of the framework. It involves creating interfaces where an AI can actually do things—interacting with other software or executing workflows. This is currently a highly unsettled technical area, characterized by a divide between Model Context Protocol (MCP) and Command Line Interfaces (CLI).

Architecting for Ingestion and Agents

For builders looking to implement high-value patterns, two areas require specific architectural attention: the transition from unstructured data to structured objects (Ingestion) and the implementation of task-executing interfaces (Agentic).

The Ingestion Workflow: Turning "Dirty" Data into Objects

The highest immediate value often lies in solving the "onboarding" or "data entry" friction. Most SaaS users have "dirty" data: screenshots, handwritten notes, or audio clips.

A robust ingestion primitive should follow this flow:

1. Capture: Accept various formats (PNG, JPEG, MP3, etc.).
2. Extract: Use an LLM to pull out specific, required fields.
3. Transform: Map those extracted values to your application's schema.
4. Validate: Ensure the output is a "strongly typed" object (e.g., a valid Date, a specific Currency amount, or a known Vendor ID) before it hits your database.

An example is the "Maui" app for construction: a foreman sends a WhatsApp voice note; the system ingests the audio, extracts the specific material requested, and matches it against a real-world inventory list. This eliminates the need for the user to ever touch a formal UI.

The Agentic Split: MCP vs. CLI

When building agentic interfaces—where the goal is to let an AI "use" your software—builders face a significant technical crossroads. There is currently no clear winner, and the "correct" choice depends heavily on your target user persona.

The Implementation Debate:

• Model Context Protocol (MCP): This is favored by consumers, prosumers, and enterprises. It integrates natively with tools like Claude Desktop and allows for sophisticated permission management. It is more "user-friendly" for those using existing AI ecosystems.
• Command Line Interface (CLI): This is the preferred path for technical, "mid-market" users and developers. It is highly flexible and behaves similarly to a standard API, but it requires a higher level of technical skill to operate.

The speaker notes that the landscape is "muddy." In recent community discussions, about 33% of builders prefer a "both" approach, 31% prefer CLI only, and 22% prefer MCP only. This suggests that for many, the choice is not binary, but a matter of deciding which persona to prioritize first.

Notably, while there is significant hype surrounding both, the speaker observes that actual user adoption for both MCP and CLI agents remains in a "bleeding-edge" or beta phase for most companies.

Tradeoffs: The Strategic Risks of LLM Dependency

Integrating AI into a SaaS product is not a "free lunch"; it introduces new categories of business risk that can threaten the long-term viability of a company, especially for bootstrapped teams.

The "Steamroll" Risk

There is a fundamental distinction between building on top of an LLM and building the LLM itself. The speaker strongly advises against bootstrapped companies attempting to build their own underlying models.

The risk is being "steamrolled" by foundation model providers like OpenAI or Anthropic. This isn't just a theoretical risk; the speaker notes they witnessed it firsthand when Tinyseed backed a company building its own model. Before ChatGPT hit, it looked like a strong moat, but once the major players released their models, they effectively steamrolled the smaller player. The most successful AI-native SaaS companies treat the LLM as a utility, not the core intellectual property.

Economic Risks: "Eating Money"

AI features can be incredibly expensive to run if the unit economics are not carefully managed. Unmanaged compute costs can quickly turn a profitable SaaS into a loss-making one. There are three primary models for handling these costs:

1. Absorb the cost: The company pays for the compute. This is common for low-frequency tasks like one-time data ingestion.
2. Tiered inclusion: Users get a certain amount of "AI usage" based on their subscription tier. This helps manage predictability.
3. Add-ons (The "SMS Model"): Users pay specifically for AI usage (e.g., "AI Tokens").

While the add-on model is the safest for the business's margins, it carries a usability risk: most non-technical users do not understand what a "token" is or how much it will cost them, leading to a "black box" experience that can frustrate customers.

Compliance and Liability

Finally, there are emerging risks regarding data and law.

• The Opt-Out Challenge: Enterprise procurement teams are increasingly demanding the ability to "opt-out" of AI processing. This means your data model must be designed from day one to allow for "AI-free" workflows, even if those workflows are slightly less efficient.
• Legal Uncertainty: The frameworks surrounding copyright and liability for AI-generated code or content are still being defined. Builders must be deliberate about where they sit in the "human-in-the-loop" spectrum to mitigate potential legal exposure.

What to change on the roadmap, and in the contract

For Product Managers & Builders

• Audit your roadmap: Before approving an AI feature, ask: "Does this solve a problem that requires 15+ minutes of manual work?" If the answer is no, it's likely a "lazy" feature.
• Focus on Ingestion first: If you are looking for immediate, measurable value, look at how users get data into your app. Can you replace a manual form with a photo upload or a voice note?
• Avoid the "Blank Page": When implementing generative features, don't just provide a text box. Use suggestion chips or auto-complete patterns to guide the user toward useful outputs.

For Enterprise Sales & Procurement

• Prepare for "AI Opt-Out" requests: Do not treat AI as an inseparable part of your core data processing. Ensure your architecture allows specific customers to exclude their data from LLM workflows without breaking the entire application.
• Translate AI to Value: Avoid using "AI" as your primary marketing hook unless your customers specifically have "AI budgets." Instead, market the outcome (e.g., "Automated Expense Categorization" instead of "AI-Powered Expense Management").

For Founders & Executives

• Evaluate the "Steamroll" Risk: If your entire moat is based on a specific model capability, you are at extreme risk. Diversify your moat by building deep, proprietary workflows and data integrations that an LLM alone cannot replicate.
• Set up Unit Economic Monitoring: Before a wide rollout, launch AI features to a small subset of users to measure actual compute costs per user. Ensure you have a clear path to profitability for every AI-enabled transaction.