Building a Mobile AI Comic-Drama App in 8 Days: An Engineering Practice from Idea to Finished Video

1. Where the requirement actually comes from: creation happens on the phone, tools live on the desktop

AI comic dramas (using generative models to batch-produce storyboard frames and assemble them into a short drama) have quickly become one of the most popular directions in content creation over the past year. But there is an obvious mismatch: inspiration shows up on a commuter train, in bed late at night, in the gaps of a conversation with friends, while the production tooling is almost entirely desktop web apps. Open a laptop, log into a console, drag reference images into an uploader, copy prompts one at a time — by the time the setup work is done, the urge to create has usually already gone cold.

The first conclusion follows from this: moving the creation flow to mobile is not “shrinking the PC interface proportionally,” it means redesigning the interaction model. Mobile’s strengths and weaknesses are both extreme: voice and camera capture are far more natural input methods, but the screen is small, long-running tasks are restricted in the background, weak networks are common, and exporting the finished video is constrained by compute and battery. So the goal of the first mobile version should not be “feature complete,” but opening the shortest usable loop: one sentence in, one finished video out.

A second conclusion matters just as much: no stage in a multimodal generation chain is reliable. If it is built as a one-shot black box, a failure in any stage forces a re-run of the whole chain, and both cost and experience collapse. The architecture therefore has to insist on structured intermediate artifacts and the ability to re-run each step independently.

2. Breaking down the pipeline: the minimum production loop for one episode

Decompose “make one episode of a comic drama” and it is essentially an eight-stage pipeline:

Stage	Input	Output	Editability
1 Screenplay	One-line idea	Episode/scene structure + dialogue	High, must be editable
2 Character design	Screenplay	Character cards (appearance / outfit / personality / speech habits)	High
3 Scene design	Screenplay	Scene cards (environment / lighting / mood)	High
4 Shot list	Screenplay + settings	Structured shot list	High
5 Storyboard frames	Shot list + characters/scenes	One keyframe image per shot	Medium, regenerable
6 Storyboard video	Keyframes	One video clip per shot	Low, re-run only
7 Audio and subtitles	Dialogue	Voice-over, sound effects, subtitles	Medium
8 Assembly	All artifacts	Finished video	Low

This table drives every technical decision that follows. Steps 5 and 6 in particular are the most expensive and the slowest, so they must come last, and the pipeline must allow “generate a low-quality preview first, then a high-quality version once confirmed.”

3. Turning the generation flow into a debuggable data flow with structured intermediates

The most common beginner mistake is to let the model emit a block of finished screenplay text and then hard-pass it downstream. The correct approach is to define a strict schema for every stage and converge natural language into validatable data. A shot list, for example, can be defined as:

{
  "episode_id": "ep_001",
  "characters": [
    {
      "id": "c_hero",
      "name": "Hero",
      "age": "20s",
      "face": "oval face, monolid eyes, a small mole under the right eye",
      "hair": "short black hair, slightly messy",
      "outfit": "dark gray hoodie, worn left cuff",
      "persona": "quiet, touches the back of his neck when nervous"
    }
  ],
  "scenes": [{ "id": "s_rooftop", "desc": "rooftop on a rainy night, neon reflections, cool color palette" }],
  "shots": [
    {
      "shot_no": 1,
      "shot_size": "wide shot",
      "camera_angle": "high angle",
      "camera_move": "slow push-in",
      "characters": ["c_hero"],
      "scene": "s_rooftop",
      "prompt_core": "rooftop on a rainy night, back view of a teenage boy, neon reflections, cool blue tones, anime style",
      "dialogue": { "speaker": "c_hero", "text": "Another night like this." },
      "duration_sec": 3.5,
      "transition": "cross dissolve"
    }
  ]
}

This yields four direct benefits. First, you can validate automatically with a JSON Schema: non-compliant model output triggers a retry with the error message attached, instead of being discovered by hand. Second, it supports resuming from a breakpoint—if one shot fails, only that shot is re-run. Third, it makes caching natural: the same input hashes to a cache hit and costs nothing. Fourth, the frontend can render the structure directly as an editable form, so a user who changes one line of dialogue or swaps a character only forces downstream recomputation where it is needed.

4. AI-assisted coding: how the 8-day MVP was compressed

The real constraints on this project were: a single developer, 8 days (minus 3 days of holiday), and a cross-platform app plus a server plus generation pipeline orchestration. Compressing the work to that scale owed a lot to AI-assisted coding, concentrated in a few reusable practices.

First, write the context before the code. Keep a rules file in the project root and make the coding assistant read it every time, so the same class of mistake does not have to be corrected repeatedly. It roughly contains: tech stack and versions, directory conventions, forbidden dependencies, naming style, error-handling conventions, and acceptance requirements such as “every completed feature must ship with validation logic.”

# Project rules
- Client: cross-platform mobile app framework, one codebase targeting both platforms
- Server: single-language implementation, REST + async jobs
- Forbidden: any third-party SDK not explicitly listed
- All model inputs and outputs must pass schema validation; retry limit is 3
- Every long-running task must have a job_id, a state machine, and idempotent retries
- Must pass lint and unit tests before committing

Second, size the task so that “one conversation produces one verifiable artifact.” Writing the requirement as “build the comic-drama app” is almost guaranteed to fail; writing it as “implement the schema validation function for the shot-list JSON, with 5 positive and 3 negative test cases” passes in one shot. Putting the input, the output, the boundary conditions, and the acceptance criteria into the task description is where the biggest efficiency difference comes from.

Third, build the end-to-end skeleton first, then thicken it layer by layer. On day 1 you want “one sentence in → a fake-data 10-second video out” to run end to end, even with placeholder images and placeholder audio. With a walking skeleton in place, every later layer is just replacing a stub implementation, and integration risk drops sharply.

Fourth, let AI write the validators and the tests. Schema validation, mock data generation, batch regression scripts, log formatting—high-effort but low-creativity work is exactly where AI is strongest, and it is safe to hand over.

Fifth, commit in small steps with discipline. AI generates a lot of code, fast, and a large change that lands in one piece is very expensive to roll back if the direction turns out to be wrong. Commit once per verifiable unit, so there is always a runnable version at any moment.

At the same time, the boundaries have to be recognized clearly: AI is good at writing implementations, not at making trade-offs. Architecture layering, the cost model, model selection, failure-degradation strategy, and the aesthetic judgment of “does this shot look good” still have to be decided by a human. Outsourcing that class of decision too tends to blow up around day 4 or 5.

5. Core challenge one: a layered solution for character consistency

Character consistency is the first make-or-break line for an AI comic drama. Viewers will tolerate fuzzy background detail, but if the protagonist’s face in shot 3 differs from shot 30, the story instantly loses credibility. In practice it is not advisable to bet on a single technique; the layers should be stacked:

1) Text layer: write the character as a structured record and fix a prefix. Every generation uses exactly the same character description string (same order, same wording), concatenated into the prompt as a fixed segment ahead of the scene description:

CHAR_PREFIX = (
    "consistent character design, {name}, {age}, {face}, {hair}, "
    "always wearing {outfit}, {persona}"
)
def build_image_prompt(shot, character, scene, style):
    return ", ".join([
        style,                                  # lock the global art style
        CHAR_PREFIX.format(**character),
        scene["desc"],
        shot["prompt_core"],
        shot["shot_size"] + " shot",
        shot["camera_angle"],
    ])

The fixed concatenation order of style words, character words, scene words, and camera words is itself a low-cost consistency constraint.

2) Image layer: reference image plus re-draw in edit mode. Generate one “character reference portrait” per character first, and after manual approval use it as the single reference image; all later shots take that reference as input and are generated in image-to-image / edit mode rather than pure text-to-image. Combined with fixed random seeds, inpainting to repair the face, and uniform upscaling and color grading, this converges the differences further.

3) Fine-tuning layer: only after data accumulates. Once an IP’s characters and scenes reach a certain volume, consider fixing the look with lightweight fine-tuning or a custom style model. This layer has the highest payoff but also the largest upfront investment, and it is unnecessary in the MVP stage.

4) Validation layer: automatic scoring with a human fallback. Score character similarity on generated images (face feature comparison or general image similarity); anything below the threshold is regenerated automatically, and after N attempts it goes to a human. “Automatic filtering plus a limited number of retries” is far more realistic than “generate a perfect image in one shot.”

5) Make it configurable. Ship sensible defaults—2 characters, 7 scenes, 3 candidate images per shot—but expose all of them as configuration. The defaults let new users start with zero thinking; configurability leaves room for heavy users and for later evaluation.

6. Core challenge two: shot language and the usability of image-to-video

With the storyboard frames in hand, the next step is turning static images into moving shots. The failure modes here are concentrated: subject deformation, motion drift, multiple characters merging into each other, broken hands, and clip duration not matching the target.

The corresponding engineering countermeasures:

• One action per shot. Describe a single action and a single camera move per shot. “He turns, looks up, and smiles” in one prompt will inevitably fall apart.
• Standardize camera-move descriptions. Reduce them to an enumeration (push in, pull out, pan, track, follow, static) rather than free text, which makes batch generation and result comparison practical.
• Keep single-shot duration short. Generation models are markedly more stable on short clips (typically 2–5 seconds); long takes come from editing clips together, not from a single generation.
• Avoid high-risk compositions. Reduce hand close-ups, reduce the number of characters in frame, avoid fast or large-amplitude motion.
• Candidates plus filtering. Generate 2–3 candidates per shot, select with rules (sharpness, deformation detection, similarity to the first frame) plus human judgment, and let only the selected clips into assembly.

There is also an implicit ordering decision here: fix the shot duration first and then record the voice-over, or record the voice-over first and adjust the visuals to the audio duration. The former keeps the flow simple but often produces “the line gets cut off before the shot changes”; the latter is a better experience but requires the audio to land first and allows the shot list to be revised afterward. Since comic dramas are narrative-driven, the recommendation is audio-driven duration: assemble the dialogue first, measure the actual duration of each line, adjust each shot’s duration accordingly, and split one shot into two when necessary.

7. Voice, subtitles, and final assembly

The voice-over stage is not about “can it make a sound,” but “is the voice stable and does the emotion fit.” The approach is to bind voice parameters to the character ID: each character gets fixed voice parameters, speaking rate, and emotion tags. Stripping punctuation noise from dialogue text and unifying the reading of numbers and polyphonic characters (a pronunciation dictionary can be maintained) noticeably reduces the number of regenerations.

Lip-sync is a well-known industry difficulty. The pragmatic MVP approach is: do not insist on frame-by-frame lip alignment; use subtitles plus shot changes (cut to a back view, a wide shot, a close-up of an object) to avoid long lines of dialogue shot from the front, and introduce a lip-drive solution once the pipeline is stable.

The core of the assembly stage is timeline management: align shot clips, dialogue tracks, sound effects, background music, and subtitles on a single timeline, duck the background music during voice segments, and add transitions in the editing stage rather than delegating them to the generation model. Scripting this with a command-line audio/video toolchain is enough, with every parameter derived from the shot-list JSON and nothing done by hand:

# Illustration: trim shot -> normalize spec -> concat -> mix audio -> export vertical
ffmpeg -i shot_03_raw.mp4 -t 3.5 -vf "scale=1080:-2,setsar=1" -r 30 shot_03.mp4
ffmpeg -f concat -safe 0 -i list.txt -c copy episode_silent.mp4
ffmpeg -i episode_silent.mp4 -i voice.wav -i bgm.wav \
  -filter_complex "[2:a]volume=0.25[bg];[1:a][bg]amix=inputs=2:duration=first[a]" \
  -map 0:v -map "[a]" -c:v libx264 -c:a aac episode_001.mp4

Export specs—vertical 9:16, fixed bitrate tiers, a first-frame cover image—are worth locking down on day 1 to avoid rework later.

8. Mobile engineering and cost governance

Long-running tasks are the first-order problem. Generating one complete episode routinely takes minutes to tens of minutes, so synchronous waiting is out of the question. It has to be an asynchronous job: the client submits and immediately gets back a job_id; the server puts the task on a queue, splits it into stages (screenplay → character images → storyboard frames → storyboard video → assembly), and each stage retries, bills, and reports progress independently. The client shows staged progress via polling or push, and can recover after the process is killed by using the job_id.

Idempotency and resumption. Every generation request uses “hash of the input content + parameters” as its idempotency key, so a repeat submission hits the existing artifact directly. In weak-network retry scenarios this saves a great deal of money.

Storage and distribution. Generated images and videos go into object storage with CDN distribution, and the naming convention includes episode/character/shot levels plus a version number. The client only preloads thumbnails and downloads finished videos on demand.

Observability. At minimum, instrument these metrics: success rate per stage, P50/P95 latency, generation cost per episode, retry-count distribution, and user abandonment rate. Without those numbers, cost optimization is guesswork. On mainstream cloud platforms (Baidu AI Cloud, for example) these capabilities are usually covered by a combination of general-purpose products—object storage, message queue, container service, logging service, and monitoring/alerting—so there is no need to build them in-house.

Four blades for cost governance. First, model tiering: use a lightweight model for screenplay inference and a high-quality model for the final render. Second, prompt caching: cache hits for long, fixed character/style prefixes. Third, artifact caching: deduplicate by content hash so identical parameters are never generated twice. Fourth, concurrency limits and off-peak scheduling: this both protects downstream quotas and reduces exposure to unit-price fluctuations.

Don’t forget the coding-side consumption. An easily overlooked fact is that building an AI app with AI burns tokens in two places: the coding conversations during development, and the business calls at product runtime. Both can exceed intuition by a wide margin, so it is worth tracking coding-side usage separately from day one; otherwise the bill is hard to attribute when it arrives.

Compliance is a hard constraint. Generated content needs to pass content safety review (text, image, and audio reviewed separately), AI-generated content needs to be labeled according to the applicable rules, and source material provenance and generation parameters need to be retained for traceability. None of this gets bolted on after launch; review checkpoints are reserved inside the pipeline.

9. The 8-day schedule and a pitfall list

Time	Goal	Deliverable
D1–D2	Skeleton and data model	Project scaffold, schema definitions, end-to-end fake-data flow
D3–D4	Screenplay and settings generation	One sentence → screenplay → character/scene cards, editable
D5–D6	Storyboard frames and consistency	Reference-image flow, consistency checks, candidate filtering
D7	Storyboard video and audio	Image-to-video, TTS, timeline alignment
D8	Assembly, export, and polish	Final export, weak-network optimization, error messages, demo material

Pitfall list (each one paid for in real time):

1. Not defining the schema first, so a mid-project structure change forced rework in three places at once: backend, frontend, and prompts.
2. Handing over too large a task in one conversation; the AI output looks complete but does not run, and debugging takes far longer than rewriting.
3. Ignoring idempotency, so weak-network retries caused duplicate charges and duplicate artifacts.
4. Delegating long shots to the generation model; deformation is severe and cannot be fixed by retrying, only avoided by splitting.
5. Not binding the voice to the character, so the same character sounds different from scene to scene and the result feels disjointed.
6. Putting review checkpoints last, which produced an enormous amount of rework.
7. Having no regression script, so after editing one prompt template there was no way to tell whether other characters had degraded.

10. Retrospective: the efficiency boundary of AI-assisted coding

Shipping a cross-platform AI content production MVP in 8 days did produce a significant efficiency gain, but the source of that gain is worth stating precisely: it came mainly from boilerplate code, type and interface definitions, UI skeletons, test and validation scripts, and mechanical translation across languages and frameworks. What all of that work has in common is a clear goal, fast feedback, and automatic verifiability.

Conversely, what AI is still not good at is defining a product’s minimum closed loop, making quantified trade-offs between cost and quality, judging whether a given shot’s composition works, and root-causing difficult problems that surface across multiple layers of a system. Those are precisely the parts that decide whether the product succeeds.

The direction of further evolution is also clear: consistency moving from “filter many generations” to “controllable generation”; storyboarding moving from templates to genuine shot-language reasoning; an IP-level asset library for long-term accumulation of character looks and style; and an automated evaluation set—fixed screenplay inputs, fixed character cards, quantifiable composition and consistency scores—so every model or prompt change produces regression data. In a multimodal project without an evaluation set, optimization eventually comes down to feel alone.

The one-line summary of these 8 days: define the data flow first, then let AI fill in the implementation; isolate unstable stages into re-runnable units, and turn cost into observable numbers. The rest is a matter of time.