When Not to Use AI: Two Approaches to Building AI-Powered Products

Every tech startup is racing to add AI to their product. LLMs, image generation, video synthesis - the tools are accessible, the APIs are simple, and the demos are impressive. But there’s a pattern I keep seeing: teams reach for generative AI when traditional techniques would deliver better UX, lower costs, and more reliable systems.

I recently compared two versions of the same product with radically different technical approaches. One leaned heavily on real-time AI generation. The other used a curated library of AI-generated assets combined with traditional web techniques. The difference in user experience, cost structure, and system reliability was stark.

Good design is as little design as possible.

— Dieter Rams

This principle applies to AI too. Sometimes the best AI-powered product is one that uses AI sparingly, strategically, and invisibly.

Pattern A: Real-Time AI Generation

The first approach follows what I’ll call the “AI-first” pattern: when a user creates something, kick off a real-time generation request to an external AI service, wait for results, and display them.

The Architecture

Here’s how it worked:

1. User submits a request (text prompt, style preferences, optional reference image)
2. Backend constructs detailed prompt and calls AI generation API
3. API returns a job ID immediately, actual generation happens async
4. Frontend polls server every 2 seconds checking job status
5. After 15-30 seconds for images (or 1-2 minutes for video), job completes (or times out)
6. Download generated content from AI service, store in database
7. User proceeds to next step

Simple, right? Just a few API calls.

The User Experience

Here’s what users actually experienced:

• 15-30 second wait times for images (1-2 minutes for video) staring at loading spinners with vague progress messages (“gathering information…”, “checking website…”, “generating image…”)
• No visibility into actual progress (50% done? 90% done? who knows)
• Unreliable outputs - AI would generate incorrect elements, wrong styles, or bizarre artifacts requiring regeneration
• Timeout failures if generation took longer than expected
• Blocking flows - can’t navigate away or edit while waiting
• No retry mechanism - failures or bad outputs meant starting the 30-second wait over

For a user trying to quickly create content, even 20 seconds felt like an eternity. Worse, after waiting, they might get an unusable result and have to try again. The conversion funnel suffered because impatient users would abandon mid-generation, and frustrated users would give up after bad outputs.

The Cost Structure

The economics were unsustainable:

• Pay-per-generation model with external API (no bulk discounts)
• No rate limiting initially - guests could generate unlimited content
• Zero reuse - same prompt from different users generated twice
• No caching layer - every request hit the expensive API
• Unbounded scaling costs - 10x users = 10x API bills

Worse, there was no way to predict monthly costs. A viral week could mean thousands in unexpected AI API charges.

The Reliability Problem

The system had multiple failure modes:

• Service outages: When the external AI service went down (or got slow, or rate-limited us), the entire product became unusable
• Output quality: No control over what the AI would generate - sometimes perfect, sometimes nonsensical
• Consistency: Same prompt could yield wildly different results between attempts
• Safety filter rejections: Video models reject perfectly legitimate content (family photos with children, certain objects, innocuous scenes) - making core features unusable for common use cases
• No graceful degradation: Without AI, there was no fallback - just error messages

Users couldn’t trust the system to deliver what they needed, when they needed it. Worse, they’d wait 30 seconds only to get a vague “content policy violation” error for a photo of their kids at a birthday party.

Pattern B: Curated Library + Traditional Techniques

The second approach flipped the model: use AI for creation, not delivery.

The Architecture

Instead of generating content on-demand:

1. Pre-generate a curated library of AI assets organized by style and use case
2. Store and version these assets in cloud storage with thumbnails
3. Build a composition layer using traditional web techniques:
   • Client-side background removal (GPU-accelerated, open-source library)
   • Image transforms (scale, rotate, position) handled in browser
   • Canvas-style editor with real-time preview
   • Separate compositions for different aspect ratios

When a user creates content:

1. Select from pre-generated style library (instant)
2. Upload their own image or reference (instant)
3. Apply background removal client-side (~2-3 seconds, no server cost)
4. Compose using drag-and-drop editor (instant feedback)
5. Optional: Apply AI style transform to uploaded image (15-30 seconds, non-blocking)
6. Optional: Request AI video generation (1-2 minutes, non-blocking)
7. Save composition metadata, not pixels

The User Experience

The difference was night and day:

• Instant feedback - every click, drag, scale operation happens in real-time
• Controllable - users can fine-tune positioning, styling, effects
• Explorable - browse entire style library before committing
• Recoverable - can save drafts, come back later, iterate
• Predictable - no mysterious wait times or timeouts

The slow operations (AI style transforms and video generation) became optional, non-blocking enhancements. Users could work with their composition immediately and request AI enhancements as needed, not as a prerequisite to getting started.

The Cost Structure

Economics became sustainable:

• One-time generation costs to build library (amortized across all users)
• Reuse at scale - thousands of users share same curated assets
• Client-side processing for transforms/removal (zero server cost)
• Predictable costs - can calculate exact cost per user based on optional features
• Marginal cost approaches zero as more users reuse library
• Assets that improve - can refine, update, and enhance library over time without regenerating for each user
• Monetization flexibility - AI features can be paywalled or upsold since they’re optional, not required

With cloud provider credits, the initial library generation was essentially free. Ongoing costs were storage (cheap) and optional per-user AI generation (style transforms and video).

Because AI generation is optional, it becomes a revenue opportunity rather than a cost center. Free tier: use the library and compose. Premium tier: unlock AI style transforms and video generation. Users who need AI pay for AI. Users who don’t, don’t.

Here’s the key insight: every dollar spent building the library creates lasting value. With real-time generation, every dollar generates throwaway content - used once, never improved, never reused.

The Reliability Win

System reliability improved dramatically:

• No external dependencies for core experience (browse, compose, save)
• Traditional web performance characteristics (CDN-cached assets, client-side rendering)
• Graceful degradation - optional AI features can fail without breaking core flows
• Offline-capable with progressive enhancement

Key Takeaways

The comparison reveals three core principles:

1. Use AI for creation, not delivery. Pre-generate and curate a library instead of generating on every request. Libraries scale better - you can refine, improve, and reuse assets. Real-time outputs are throwaway.

2. Make AI optional, not mandatory. A fast core experience with optional AI enhancements beats blocking users on AI generation. Users who need AI can opt in and pay. Users who don’t get instant results.

3. Traditional techniques often win. Background removal, image transforms, and composition have mature solutions. Use AI for hard problems (generating novel content), not solved problems.

When to Use Each Pattern

Neither pattern is universally better. Choose based on your use case:

Use Real-Time AI Generation When:

• Output must be truly unique (user’s exact photo, specific product, custom scene)
• Design space is unbounded (can’t pre-generate all possibilities)
• Volume is low (hundreds, not thousands, of generations)
• Users expect to wait (professional creative tools, high-value outputs)
• Quality > speed (users will wait for perfect results)

Use Curated Libraries When:

• Design space is bounded (styles, templates, themes)
• Volume is high (thousands+ users)
• UX is critical (conversion funnels, mobile apps)
• Costs must be predictable (fixed budgets, freemium models)
• Reliability matters (can’t depend on external services)

The Real Question

AI is often a solution looking for a problem. Everyone wants to ship “AI-powered” products, but the real question isn’t “how do we add AI?” - it’s “what problem are we solving, and what’s the best tool for the job?”

Most products don’t need real-time AI generation. They need curated libraries, good composition tools, instant feedback, and sustainable costs. AI is incredible for creating those assets. Traditional engineering is better for delivering them.

Sometimes the best tool is AI. Often it’s not.