Building an AI Product Takes More Than a Generate Button

I built Content Carousel to turn SaaS material into slides, captions and vertical-video assets. Its first AI content workflow was a folder of JSON, rendering scripts and notes that worked because I knew how to operate it.

Making that workflow usable by another founder required more than a better renderer. The product had to preserve editorial decisions, recover interrupted work and distinguish a finished asset from an approved post.

This is an owned-product engineering case study, not a client engagement or a measured marketing-performance claim. Content Carousel is one of the products I build; the transferable work is the workflow behind it.

Separate editorial inputs before generating assets

In August 2026, I reviewed 522 TikTok slideshow posts from 17 creator accounts, comparing posts against each creator's own median rather than comparing raw reach across accounts. It was observational research, not evidence that a particular design caused higher views or sales.

A useful product decision was separating format from visual treatment. A checklist, comparison and founder lesson describe what the reader receives. Photography, collage and editorial typography describe how it looks.

My early picker mixed those decisions. Adding another template would not fix an input model that made compatible choices compete with each other.

The website could supply product facts, but not a founder's private results or actual routine. A first-person claim needs confirmation from the person whose experience it describes. Otherwise, the draft should offer an example or recommendation instead of inventing a story.

That boundary belongs in the brief and generation instructions, followed by human review. It is not something a more casual tone can repair afterwards.

One feature can support different explanations

A fictional scheduled-report feature can produce a setup checklist, a metric-definition example, a fixed-report versus dashboard comparison, a design decision and a short demonstration.

Those are different questions, not five rewrites of “new feature launched”. Keep the capabilities and safe example data beside the drafts so a weekly report does not become “real-time analytics” during generation.

A useful content product needs history and batch context too. An individually reasonable post may be the wrong next post if it repeats the previous hook or claim.

This is a software-state problem as well as a writing problem. Inputs, prior outputs, approvals and relevant source material need deliberate relationships.

Approval, rendering and publication are different facts

During my interface review, “Rendered” and “Draft” appeared to compete as statuses. They described different decisions. An image could finish rendering while the content still needed approval.

I simplified the main customer-facing states to Generating, Draft and Approved. Asset progress and failures still need their own detail. Publication is separate: copying a caption or downloading a file does not establish that it was posted.

The button “Copy TikTok caption” also sets a narrower, more accurate expectation than “Copy TikTok post”. A caption is not the images.

An editorial suggestion should explain what it proposes to change. A technical retry should explain which output it regenerates. Neither should imply that the software already applied a change it merely recommended.

A video export needs another editorial check

Stills let the reader choose the pace. A video chooses it for them. Exporting the same text into a moving file does not establish that the result is readable.

Use motion when the change itself matters, such as a booking moving between slots. A settings comparison may work better as a still image.

Check dense frames at normal speed and without sound. Keep demonstration data free of private customer material. Maintain source briefs and screenshots so a product change does not leave an untraceable library of outdated claims.

These are choices about explaining software. I have not run a controlled test establishing that these changes increase reach or conversion.

The challenge extends beyond generating text

A content workflow has several different kinds of work: plan the posts, generate the material, render images, encode video and expose usable assets to the customer. Some stages take longer than an ordinary browser request.

There is also a commercial boundary. If a batch is interrupted, the product needs to know what was completed, what should be retried and what usage has been consumed. Treating all of that as a single “generate” button hides important decisions.

Durable jobs separate progress from the browser

The implementation uses persisted generation jobs and a background worker. Work can be claimed and processed independently of an open browser tab. The web app and worker have distinct responsibilities rather than asking a user to keep one long-running request alive.

The business consequence is straightforward: a customer can return to recorded progress. The engineering responsibility is less visible: job state must distinguish queued, running, completed and terminally failed work, with a recovery path for interruptions.

This architecture is not a promise that jobs never fail. It makes failure a state the application can represent and handle rather than a lost browser request.

Usage is reserved before the batch completes

The database implementation reserves generation allowance when a plan is enqueued. Completion couples creating the resulting deck and render work with consuming the reserved usage. Terminal failure paths release the relevant reservation.

That separation matters. Starting work, finishing work and charging usage are not the same event. Retries should not accidentally treat the same completion as a second purchase.

The transferable lesson for a paid AI application is to write down when an action is reserved, committed or released. A loading spinner cannot act as the source of truth for a customer's allowance.

Images and video have separate completion requirements

The render worker produces the required image outputs and queues video after the necessary images are available. The documented rendering workflow encodes video one slide at a time and bounds browser-rendering resources.

Separating the stages allows completed image assets to remain useful if video generation needs another attempt. It also gives the product a more precise status than “everything failed.”

For a different app, the same pattern might separate a generated document from its email delivery, or a successful import from an optional summary. The dependencies should follow the product's actual acceptance criteria.

Ordering needs its own regression check

A content queue should not reorder older work just because one item was recently edited. The repository includes a queue-ordering function and tests that preserve batch order and the slot within a batch; standalone drafts retain creation order.

This is a small example of a rule that a generic “page loads” test would not cover. The test expresses the behaviour the user relies on, not only the shape of the returned data.

What this demonstrates and what it does not

The implementation shows how background work, usage accounting, partial output and interface order connect. It does not establish a universal throughput figure, prove that every path is free of defects or replace an independent security assessment.

Source review for this article focused on the worker documentation, generation-job migration and queue-ordering implementation and tests. No customer data, production credentials or private incident details are included.

Bringing the same approach to your app

A useful engagement starts with the workflow: what triggers it, what must happen once, what can retry and what the customer should see if a stage fails. From there I can scope the code, data changes and verification.

Thunkle feature development covers background jobs, AI integrations and other blocked workflows. Request a feature-development quote with the workflow you need to build. If the app is already stuck between prototype and launch, AI-app rescue explains how I diagnose the next step.