AI-Based Carousel Builder
How I turned an 11-day design bottleneck into a 1-hour, no-design-skills-needed workflow.
Every carousel took 7–11 days to make. Not because anyone was slow.
Carousel design competed with everything else on a designer's plate. And every single carousel meant real decisions, repeated every slide:
- 📐 Layout: what goes where
- 🎨 Color: which palette, which accent
- 🔠 Hierarchy: what the eye sees first
- 📏 Spacing: how tight, how loose
Multiply that by every slide, every carousel, every week.
We tried templates. Reusable Figma files the marketing team could fill in themselves.
It backfired twice:
- 🧩 Marketing wasn't fluent in Figma, so even filling in a template was slow and frustrating
- 🎨 Everyone used the same templates, so every carousel started looking identical
The real problem was never speed. It was that non-designers were being asked to make design decisions they had no framework for.
That reframe changed everything about what I built next.
My first version was one big Claude Project trying to do everything at once: understand the content, choose a layout, reason about visual composition. Like designing directly inside an Instagram mockup.
It worked. It also burned 30,000+ tokens per carousel.
Too expensive to run every day, on every carousel, forever. But it proved the idea was real, and that mattered more than the cost, at this stage.
Here's the architectural bet that changed everything:
Split the problem in two.
| Layer | Job | Never does |
|---|---|---|
| 🧠 Claude | Reads raw content → outputs structured JSON (layout, color, icon choices) | Never touches pixels. Never designs anything visually. |
| 🖥️ My HTML tool | Takes that JSON → renders it, lets you edit it, exports it | Never has to think. Just executes a system I already built. |
(layout, color, icons)
Claude stopped trying to "see" a slide. It just had to describe one, in structured data. The actual visual rendering happened in code I built, where every design decision was already made once and encoded for good.
Result: 30,000 tokens → roughly 600. A 97%+ drop. And it got more reliable, not less, because I'd narrowed Claude's job down to something it could do consistently every time.
I didn't just prompt Claude to "stay on brand." I built rules that made going off-brand structurally impossible:
- 🎨 A fixed 10-color palette. Nothing else exists in the system's vocabulary. No red, anywhere, ever, by design.
- 🖼️ 7 named layouts, used only when content actually fits them, plus a flexible fallback for anything that doesn't
- 🔤 13 icons only. No invented icons, ever.
- ✍️ Copy stays exactly as written. Claude is allowed exactly four small edits (things like sentence-casing a heading). Everything else (tone, wording, even hyperbole) is untouched.
One small detail I'm proud of: if a slide centers on one big number ("Engagement up 47%"), the system automatically detects it and switches to a stat-focused layout, even if nobody asked for that. Small moments like this are what make a tool feel intelligent instead of just automated.
The JSON needed somewhere to live. So I built a self-contained HTML app (no install, no account, no server) that anyone on the team could just open and use.
What it does:
- ✅ Import Claude's JSON, see it rendered instantly
- ✅ Duplicate, delete, and reorder slides and sections
- ✅ Edit background color, accent color, font size, spacing, all from the same locked color system
- ✅ Auto-flips text color the instant a background gets darker, so nobody ever ships unreadable white-on-white or black-on-black text
- ✅ Auto-resizes uploaded images to fit the available space
- ✅ Exports to PNG (Instagram), PDF (LinkedIn), or a full ZIP
- ✅ Knows the difference between formats: the progress bar shows in-app but is automatically hidden in PDF exports, because it means nothing outside the interactive view
A non-designer can now build a fully on-brand carousel without opening Figma once.
The tool went straight to the marketing team: not a demo, real usage. Faizal used it directly and verified 4–5 live carousels built through the system.
Real usage surfaced real gaps, fast. 4 fixes, all from watching someone actually use the thing:
- 💾 Needed to save work in progress → added
- 🖼️ Images cropped wrong → auto-resize added
- 🔠 Text too small on some slides → font size controls expanded
- 📄 PDF exports showed a broken progress bar → fixed at the format level
I can architect systems, not just prompts
The breakthrough here wasn't a clever prompt: it was recognizing that two very different problems (content decisions vs. visual rendering) needed two very different solutions, and building both myself.
I design for the user who doesn't think like a designer
Every constraint I built in (the fixed palette, the auto contrast-flip, the locked layouts) exists because I was designing for someone who's never had to make a design decision in their life. That's a harder design problem than designing for another designer.
I ship, watch, and iterate
The gaps that got fixed didn't come from my own assumptions. They came from putting the tool in front of real users and paying attention.
The expensive first version wasn't a failure. It was necessary. I needed to prove the idea worked before I could see clearly what was actually making it expensive.
Once I saw that Claude was being asked to think visually (something it's fundamentally bad at doing cheaply and reliably). The fix became obvious: let Claude describe, let code render. That single split is the difference between a clever demo and a tool people actually use every day.