Adding AI Features to a Canvas App Without a Rewrite

Adding AI features to a Canvas app is one of the most common reasons clients call us in 2026. The pattern is consistent: a Canvas app working well at scale, a clear business case for an AI feature, and no obvious path inside Bubble to ship it without making a mess.

The good news is that most AI features can be added to a Canvas app without leaving Bubble. The pattern that works is to keep the AI orchestration outside Bubble (where it belongs) and let Bubble do what it does well: the UI.

This article describes the patterns we use at AppSavvy when adding AI features to Canvas apps. It also covers the cases where the AI work itself is a signal that the migration off Canvas is closer than you thought.

The architecture that works

The pattern: Canvas handles the UI, a small code service handles the AI, the two communicate over HTTP.

The code service:

• Receives requests from Bubble (via API Connector)
• Calls the LLM (Claude, OpenAI, or whatever)
• Manages tool use, RAG, response formatting, retries
• Streams or returns results to Bubble

Bubble:

• Presents the UI
• Captures user input
• Calls the code service via API Connector
• Renders the response

This is not the same as bolting an external backend onto Bubble, which is a structural mistake. This is keeping one bounded code service alongside Bubble, with a clear single responsibility: AI orchestration.

Why not do it inside Bubble?

Bubble can technically call an LLM directly via the API Connector. We strongly advise against this pattern for anything beyond the simplest cases. Three reasons:

1. Prompt management gets messy

A real AI feature involves prompt templates, system prompts, few-shot examples, possibly RAG. Storing and updating these inside Bubble means editing them via the Bubble editor. There is no version control, no rollback, and no ability to A/B test prompt variants.

Code services give you all of this for free: prompts in a git repo, change history, easy rollback.

2. Streaming responses are hard from Bubble

Modern AI features benefit from streaming the response token by token (the typewriter effect you see in Claude or ChatGPT). Bubble's request model is request and response; streaming requires a different protocol.

A code service can stream to Bubble via Server-Sent Events or websockets, and Bubble can render the stream via a small custom HTML element. The orchestration lives where it belongs.

3. Model swapping needs to be a config change, not a refactor

The AI model market moves quarterly. The right model for your use case today might be a different model in six months. If your Bubble app has hardcoded API calls to a specific provider, every swap is a refactor.

A code service with a thin abstraction (or a routing layer like OpenRouter) makes the swap a one-line change.

The patterns that work

Pattern 1: chatbots that know your data

The most common request. Users want a chat interface inside your Canvas app that can answer questions about their data.

The architecture:

• A code service indexes the user's data (Bubble Data Types) into a vector store
• When the user asks a question, the code service does retrieval-augmented generation (RAG)
• The response comes back to Bubble with citations
• The chat UI in Bubble renders the conversation

Bubble does what it does well: nice chat UI, conversation history, user permissions. The code service does what it does well: vector search, prompt engineering, model orchestration.

Pattern 2: structured data extraction from documents

A user uploads a PDF or image. The app extracts structured data: invoice numbers, line items, contract terms, addresses.

The architecture:

• Bubble handles the upload (via standard file upload)
• Bubble fires a workflow that calls the code service with the file URL
• The code service downloads the file, runs OCR if needed, calls the LLM with a structured-output prompt
• The structured data comes back to Bubble and gets saved into a Data Type

This is straightforward. The hardest part is prompt engineering for reliable structured output, which lives in the code service.

Pattern 3: AI search and recommendations

Instead of Bubble's literal text search, the user can search in natural language. Or the app suggests relevant items based on user context.

The architecture is similar to chatbots, but the UI is different. Bubble surfaces a search bar; the code service handles the semantic understanding.

Pattern 4: AI-assisted form filling

Users describe what they want in natural language; the app fills the form for them.

The architecture: Bubble has a "Describe what you want" input. On submit, Bubble calls the code service. The service returns a JSON object with the expected field values. Bubble's workflows pre-populate the form fields from the JSON.

This is one of the highest-impact AI features for B2B SaaS because it removes the friction of complex forms.

Pattern 5: background AI workflows

The user does something. The app does AI work in the background (categorise the item, generate a summary, score lead quality) and updates the record when done.

The architecture: Bubble fires the workflow when the trigger happens. The code service does the AI work asynchronously via a background job. When complete, the service calls back to Bubble (via webhook to a Bubble API endpoint) to update the record.

This is the pattern we use for anything that does not need to be synchronous.

What the code service looks like

A typical AI service for a Canvas client at AppSavvy is a small Next.js app:

• Hosted on Vercel
• API routes that Bubble calls
• An LLM abstraction (we use OpenRouter most of the time to stay model-agnostic)
• A vector store (Supabase pgvector or Pinecone, depending on the use case)
• Authentication: Bubble passes a shared secret in headers; the service validates

The service is small (often a few thousand lines of code) and bounded in scope. It does AI work and nothing else. No database for the customer entities (those stay in Bubble), no auth UI (that stays in Bubble), no payments (those stay in Bubble).

The boundary stays clean if you keep the rule: the code service is for AI orchestration only.

The gotchas

Latency

LLM calls take seconds. The Bubble UI cannot block on them.

The pattern is to fire the call from Bubble asynchronously (use "Schedule API workflow"), poll for completion from the page, and render the result when ready. Most users tolerate a few seconds of "thinking..." if the UI shows progress.

For streaming, you need a custom HTML element in Bubble that handles the SSE stream. This is a one-off effort but it works.

Cost

LLM API calls cost real money. For high-volume features, costs can grow fast.

The code service is the right place to manage this: caching, rate limiting per user, model selection based on the use case (cheaper models for simple tasks, more expensive ones where it matters).

Hallucinations

LLMs sometimes make things up. The code service should:

• Use RAG with citations whenever possible
• Validate structured outputs against a schema before returning
• Surface confidence indicators where relevant

The Bubble UI can then display "we are uncertain about this" appropriately.

Prompt injection

User input is part of the prompt. Malicious users can try to manipulate the LLM via crafted input.

The code service handles this with input validation, output validation, and sandboxing. It is significantly easier to defend against from code than from Bubble.

When the AI work signals you should migrate

If you are adding AI features and find:

• The AI service is growing into a large code project
• More and more workflows are calling the AI service
• The boundary between "AI work" and "app logic" is blurring
• You are duplicating data into the AI service to avoid round trips

These are signals that your app is becoming a code app with Bubble as a UI layer. At some point the right move is to commit to the migration off Bubble rather than maintain the split.

This is fine. The AI service was always a stepping stone for some clients. The pattern works during the transition and the migration becomes incremental rather than a big-bang rewrite.

What to do next

If you want help adding AI features to your Canvas app, book a 30-minute discovery call. We do AI-extension engagements as standalone work (typically 6-12 weeks) as well as part of larger migration work.

Read next: Canvas to code migration path and Canvas plugin strategy.