How to Build an AI Google Slides Generator That Doesn't Suck

The Core Stack: What You Actually Need

Forget the all-in-one web apps for a minute. Most are just shiny wrappers around the same core components, and they lock you into their templates and pricing. You can build a more powerful, flexible system yourself with three things: Google Slides, Google Apps Script, and an LLM API key.

That’s it. The whole system lives inside your Google Workspace account.

Google Slides is your canvas and, critically, your template engine. You’re not starting from a blank page; you’re starting from your own branded master template. Google Apps Script is the engine that connects everything. It’s Javascript that runs on Google’s servers and can manipulate your Slides, Sheets, and Docs programmatically. Think of it as the nervous system for your G-Suite. For the brain, you’ll use an LLM. I use OpenAI‘s GPT-4 models, but you could swap in Claude or Gemini. The cost is negligible. A complex 15-slide deck might cost you ten cents in API calls. Honestly, the free credits they give you are probably enough to run your business for a month.

What Most Guides Get Wrong About AI Slide Decks

Here’s the problem with 99% of AI presentation tools: they think the job is to generate text and images. That’s the easy part. The actual hard part is arranging that content into a coherent narrative that follows a specific visual structure—your structure.

These tools spit out generic, ugly slides that look like they were designed by a committee in 2004. They ignore your company’s fonts, colors, and layout conventions. You spend more time fixing the output than it would have taken to make the deck from scratch. The result is an unusable mess that screams “I let a robot make this.”

Our goal is different. We aren’t asking an AI to *design* a presentation. We are commanding it to *populate our pre-existing, beautifully designed template*. The AI’s job is to be a content strategist, not a graphic designer. It will decide the flow and the text for each slide, and it will tell our script which of our layouts to use for that specific piece of content.

Step 1: Architecting the Master Template

This is the most important step, and the one everyone skips. Before you write a single line of code or a single prompt, you must build a bulletproof master template in Google Slides. Open `View > Master` and create a set of distinct slide layouts for every type of slide you use. Don’t just rely on the defaults.

Create layouts like:

• Title_Slide: For the main title and subtitle.
• Section_Header: A bold slide to introduce a new topic.
• Two_Column_Text: A layout with a title and two distinct text boxes.
• Image_Left_Text_Right: A layout with a placeholder for an image on the left and text on the right.
• Quote_Slide: For a large, impactful quote.

The key is to give each of these master layouts a unique, descriptive name. You do this in the Master view by selecting a layout and using the ‘Rename’ button. This name is how your script will identify and create new slides. My concrete gripe here is that Google’s documentation on programmatically accessing layouts by the names you set is shockingly thin. It took me a full afternoon of `Logger.log()` trial and error to figure out the exact syntax to get a layout by its custom name instead of its useless index ID. It’s a perfect example of a feature being technically available but practically undocumented.

Step 2: The “Director” Prompt for the LLM

Your prompt is not going to be, “Write me a presentation about cold email automation.” That’s a recipe for generic paragraphs. Instead, you’ll prompt the LLM to act as a “Presentation Director.” Its only job is to return a JSON object that our script can parse.

This prompt is a contract. It defines the exact structure of the output, mapping directly to the master layouts you just created. You have to be ruthlessly specific.

Here’s a simplified version of a prompt I use:

This approach forces the LLM to think about structure first. It has to choose the right layout for each piece of the narrative, which is exactly what a human would do.

How Do You Handle Image Generation and Placement?

This is where most automated systems fall apart. You have two main options: generate images with a model like DALL-E 3, or fetch existing images from a stock photo API. I strongly recommend the latter for this use case.

Why? Cost and speed. Calling DALL-E for every slide is slow and can get expensive. A stock photo API like Unsplash or Pexels is much faster and, for many use cases, completely free. The Unsplash API offers 50 requests per hour on its free tier, which is more than enough for a solo operator. A $29/mo plan gets you way more if you need it, but the free plan is perfectly usable.

Your “Director” prompt (from the previous step) provides the `image_query`. Your Apps Script then takes that query, makes an API call to Unsplash, gets the URL of a suitable image, and inserts it into the correct image placeholder on your slide. My concrete love for this system is the first time it works perfectly. Seeing your script not only write the text but also find and place a genuinely relevant, high-quality photo into your custom-branded layout feels like actual magic. It’s the moment it transitions from a toy to a real production tool.

Step 3: The Google Apps Script Engine

Now you wire it all together with Google Apps Script. The script is the factory worker that takes the JSON blueprint from the LLM and assembles the final product. It lives in the Script editor of your master template file (`Extensions > Apps Script`).

The logic is straightforward:

1. Get the user’s topic. This can come from a simple `prompt()` dialog, a cell in a Google Sheet, or a web form.
2. Call the LLM API. You’ll use `UrlFetchApp` to send your Director prompt and the topic to the OpenAI (or other) API endpoint.
3. Parse the JSON response. The LLM’s output is a string, so you use `JSON.parse()` to turn it into a usable Javascript object.
4. Create the new presentation. The script makes a copy of your master template file, giving it a new name.
5. Loop and build. The script iterates through the array of slide objects from the JSON. For each object:
• It finds the master layout by its name (e.g., `deck.getLayouts().find(l => l.getDisplayName() === slide.layout)`).
• It appends a new slide using that layout: `deck.appendSlide(layout)`.
• It finds the placeholder shapes on that new slide (like the title box or body text box) and populates them with the content from the JSON object. This part is finicky and requires you to map the JSON keys to the placeholder text—if you’ve ever tried to automate PowerPoint with VBA, you know the pain.
• If an `image_query` exists, it calls the Unsplash API, gets an image URL, and replaces the image placeholder on the slide with the fetched image.

This creates a perfect, on-brand presentation in about 60 seconds.

Debugging When It Inevitably Breaks

This system will break. All real automation does. Here are the three most common failure modes and how to fix them.

First, the LLM will occasionally return malformed JSON. It might forget a comma or add a weird trailing character. Your `JSON.parse()` call will fail. The fix is to wrap the parsing in a `try…catch` block. In the `catch` block, you can log the bad output and either stop or, for a more advanced system, send it back to the LLM with a prompt that says “This is invalid JSON. Please fix it.”

Second, you’ll hit Google Apps Script execution limits. Standard Gmail accounts get 6 minutes per execution. If you’re generating a 30-slide deck with lots of image lookups, you might time out. The solution is to optimize. Make your API calls more efficient, or structure your script to run in batches if needed. For most decks under 20 slides, this won’t be an issue.

Third, you’ll have a mismatch between the JSON content and the slide template. The LLM might return a content key named `body_text` when the placeholder on your slide is expecting `main_content`. The script won’t find the placeholder and will fail silently. The only solution is rigor. Your prompt’s instructions and your template’s structure must be perfectly synchronized. Treat your prompt like a technical spec sheet, because it is.

Building this system requires some patience, especially with the quirks of Apps Script. But the result is a powerful asset that generates client-ready presentations with a single command.

We cover this in more depth elsewhere — deeper coverage of AI agent platforms.

If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this entire workflow, including the Apps Script and Director Prompt, as a deployable AI automation blueprint. You can find it at deepusecase.com/vault.