DEV Community: xianyu110

Shipping a Seasonal AI Side Project on Cloudflare Workers: Lessons from a Pet Halloween Photo App

xianyu110 — Tue, 06 Oct 2026 04:02:32 +0000

Most side-project advice assumes you have time: launch, iterate, grow slowly. A Halloween product gets about three weeks. If people can't find it, trust it and pay for it in that window, the next chance is a year away.

This October I shipped HallowPaws. You upload a photo of your dog or cat, pick a costume, and get an HD Halloween portrait that still looks like your pet. Below are the engineering and product decisions that mattered for a short seasonal window. Most of them would apply to any AI photo side project.

Stack: boring, cheap, scales to zero

TanStack Start + React 19, deployed to Cloudflare Workers
D1 for data, R2 for images, a Cloudflare Queue for generation jobs
better-auth for accounts, Stripe Checkout for one-time packs
An image-edit model behind an API aggregator, with a fallback model

For a product that's busy for a few weeks and quiet the rest of the year, scale-to-zero pricing matters more than anything else on this list. Nothing sits idle and costs money in February.

Decision 1: no prompt box, just presets

The users are pet parents, not prompt engineers. So there is no free-text input anywhere. The only prompts that can run are 16 costume presets in one config file (vampire, witch, pumpkin, ghost, skeleton, pirate, wizard, mummy and so on). Each preset has just two creative fields, costume and scene, which get dropped into one shared template:

Edit the reference photo: create a Halloween costume portrait of the pet from the reference photo.
Keep the exact same animal identity: same species, breed, fur color and pattern,
markings, eye color, ear shape, face proportions and expression, so the owner
instantly recognizes their pet.
Dress the pet in {costume}. The costume must fit the animal's anatomy naturally...
Background: {scene}.
Style: photorealistic professional pet photography, sharp focus on the eyes,
detailed fur texture, shallow depth of field, vertical 4:5 portrait composition.
Do not add any humans, people, hands, text, captions, logos or brand marks...

The identity line comes before the costume line on purpose. For this kind of product, the quality bar isn't "nice AI art". It's whether a friend scrolling past would say "that's Max". Fixed presets also make results reproducible, so when a costume underperforms I fix one string in one file. Adding a costume or an SEO landing page means adding one entry, and the picker, sitemap and llms.txt all update from that config.

Decision 2: watermark on the server, before storage

The free tier is a low-res, watermarked preview. My first instinct was to ask the model to draw the watermark. Don't do that: the model treats it as a suggestion.

Instead, previews get stamped inside the Worker with Photon (Rust compiled to WASM) before anything is written to R2. The image is downscaled to 768px wide and a tiled overlay is applied. The clean original never exists in storage, so there's no URL for anyone to guess. HD images skip this step completely.

Two workerd gotchas:

The .wasm file has to be imported as a precompiled module (?module), because compiling from bytes at runtime is blocked.
Load it lazily on first use, so a WASM problem can never break Worker startup for every other route.

Decision 3: image calls are slower than your proxy

Image-edit calls regularly take longer than Cloudflare's ~100-second proxy timeout. Run them inside the request and users see HTTP 524. So generation became a job:

POST /generate validates the photos (JPEG/PNG/WebP, up to 10 MB each), reserves credits, stores the photos in R2, inserts a job row, puts the job id on the queue, and returns right away.
The queue consumer runs the job. A queue invocation can run far longer than an HTTP request.
The client polls the job status every few seconds.

Every failure path goes through one rule: mark the job failed and refund the reserved credits, exactly once. A sweeper fails and refunds anything stuck for more than 10 minutes. The provider wrapper also has a per-call timeout, so a hung primary model still leaves time to retry on the fallback model. Users never pay for a failed image, and that one rule removed a whole category of support emails.

Decision 4: let people try before they sign up

Asking for an account before showing any result kills a seasonal funnel. HallowPaws gives guests one free watermarked preview with no sign-up:

Guests are identified by an httpOnly cookie, rate-limited per hashed IP per rolling 24 hours, and capped globally per day to protect AI spend.
When the guest signs up, that preview is claimed into their new account as its free preview.
Signing up also gives one free HD credit, so a new user can unlock one clean, full-resolution portrait before paying anything.

Decision 5: price for a spike, not a habit

A monthly subscription for something people use for two weeks a year feels hostile. So HallowPaws sells one-time packs:

Treat: $1.99 for 4 HD images (classic costumes)
Spooky: $4.99 for 15 HD images (all 16 costumes)
Monster Party: $9.99 for 40 HD images, plus group portraits of up to 3 pets

Pack definitions live server-side as the single source of truth. The client only sends a pack key. Checkout ignores any price or credit count in the request body and records the server's numbers on the order, and that order is what the webhook grants.

Decision 6: honest demos

Before/after examples are the most persuasive part of the landing page. They're also the easiest place to cut corners. The ones on HallowPaws come from royalty-free (CC0) pet photos, run through the same presets customers get, and the page says so. If your product is "it still looks like your pet", the demo can't use cherry-picked outputs from a different pipeline.

What I'd tell someone building the next seasonal AI app

Ship the config, not the prompt box. Curated presets beat flexibility for consumer users and are far easier to debug.
Assume generation will outlive the request. Design for queues and polling from day one.
Treat credits like money from the start. Reserve first, refund on every failure path, and make the refund idempotent.
Enforce the free tier on the server. Watermarks and resolution limits belong in your code, not in the prompt.
Pick infrastructure that costs nothing in the off-season.

If you have a dog or cat and five minutes, you can try a free preview at hallowpaws.com. I'm happy to answer questions about the Workers + Queue + Photon setup in the comments.

Keeping One Character Consistent Across a Whole Article's AI Illustrations

xianyu110 — Tue, 06 Oct 2026 04:02:08 +0000

If you've tried to illustrate a long blog post with an image model, you know how it goes. You ask for five pictures and get five different art styles, three versions of your "mascot", and a stock-photo handshake you never asked for. Each image is fine by itself. Put them together in one post, though, and it looks like a ransom note.

I build InkDoo, a tool that takes an article and returns a full set of hand-drawn explainer illustrations, all starring the same character. This post covers the parts that actually made the set look consistent. Spoiler: most of it is boring prompt plumbing, not model magic.

The pipeline in one paragraph

Article in. A planner LLM reads the text and returns JSON: which ideas are worth a picture, which paragraph each picture goes after, and a scene description for each. Then an image model draws every scene from a strict prompt template. Finally, an exporter drops the hosted image URLs back into your Markdown at the right spots. Three stages, and the consistency work happens in all three.

1. Describe the character like a spec, not a vibe

The biggest single win was writing each character as a short, very literal visual spec, then pasting that exact string into every image prompt. Here is the default character, Mochi:

"Mochi", a round low squishy cat-like blob drawn ONLY as a hollow black
outline (white inside, never filled black): a wide soft dumpling-shaped body
sitting flat, two tiny triangle ears, two short sleepy horizontal line eyes,
a tiny 'w' mouth, small nub paws, one thin curly tail.

A few things I learned writing these:

Count things. "Two tiny triangle ears" and "ONE single large round eye" drift much less than "cute ears" or "big eye".
Repeat the negative. "Hollow outline, white inside, never filled black" appears in the description and in the style block. Without it the model kept turning line-art characters into solid silhouettes.
Give the character a personality in three words ("lazy-looking but surprisingly competent, deadpan"). It nudges poses without changing the design.

InkDoo ships six of these (Mochi, Doo, Blot, Stub, Folio, Puff), and they all follow the same spec format.

2. Make the character do the work

A consistent character that just stands in the corner waving is decoration. The planner's system prompt has one rule that changed the output more than anything else:

${N} must PERFORM the core conceptual action of each image (pulling, carrying,
sieving, weighing, stitching, guarding, pushing, folding, unpacking...).
If the image still works without ${N}, ${N} is too decorative â€” rewrite.

Because the character is part of the metaphor, every image has to draw it at a size and angle where its features are readable. A tiny figure in the background is where likeness falls apart, so this rule helps consistency too.

3. Lock the style separately from the content

Every image prompt has the same fixed "visual DNA" block: pure white background, minimalist black hand-drawn wobbly line art, at least 35% empty space, and sparse handwritten notes in only three colors. Each color has a job: orange for the main flow and arrows, red for the key warning or result, blue for side notes. It also carries a list of things to avoid: gradients, shadows, PPT infographics, cute-poster energy.

Only a few fields change from image to image: theme, structure type, core idea, composition, and two to five short labels. The planner picks the structure from a small, fixed list (Workflow, Before/after, Concept metaphor, Route map, Mini comicâ€¦). It also has to invent a fresh, low-tech physical metaphor using one or two objects: a funnel, a scale, a drawer, a broken machine.

Keeping the variable surface small is the real trick. The less each prompt is allowed to vary, the more the set reads as one series.

(Credit where it's due: the illustration method, meaning one idea per image, white background and sparse colored annotations, is adapted from the MIT-licensed Ian Xiaohei Illustrations project. The characters are original.)

4. The planner never sees images, so give it a text twin

Users can upload their own character as a reference picture. That creates an asymmetry. The image call can take the reference (InkDoo sends it to the edits endpoint), but the planner LLM is text-only. So a custom character gets two descriptions:

desc, for the image model: "the user's own original character, exactly as shown in the attached reference imageâ€¦ keep its silhouette, proportions, face and distinctive featuresâ€¦ but redraw it in this minimalist black hand-drawn line-art styleâ€¦ ignore the reference background."
planDesc, for the planner: a text-only version built from the name and any look description the user typed.

User text is sanitized (control characters, quotes and braces stripped, length capped) before it gets near a prompt. If the custom character is empty, the resolver quietly falls back to Mochi instead of producing a character-less set.

5. Switching characters without re-planning

Planning is free in InkDoo, and generating images costs credits. So I didn't want people re-planning just because they picked a different character halfway through. The planner writes scenes in English with the character's name in them, so switching is a careful, Unicode-aware whole-word replace of the old name with the new one. Mochi's scene ("Mochi sits on the overflowing inbox") becomes Doo's scene, with no extra LLM call.

6. Put the images back where they belong

The planner returns an after anchor for each shot: the first ~20 characters of the paragraph the image should follow, copied verbatim. The exporter splits the article into blocks, normalizes whitespace, and matches each anchor to a block. Then it writes out Markdown (or WeChat-friendly HTML) with the hosted image URLs in place. Matching on a short prefix holds up much better than asking the model for paragraph numbers, which it miscounts.

Things that still bite

Long jobs vs. request timeouts. Image calls can take minutes, so generation runs as a background job on a Cloudflare Queue. The client polls, and a failed or stuck job refunds its credit automatically.
Single-image redraws. Sometimes one image in the set is off. Each card can redraw just that scene with an edited prompt, and the rest stay as they are.
Labels in the right language. Handwritten notes follow the article language: Chinese articles get Chinese labels, English ones get English.

Takeaways

If you want a consistent character across many AI images:

Write the character as a literal, countable spec and reuse the exact string.
Make the character perform the key action so it's always drawn large enough to stay recognizable.
Freeze the style block and keep the per-image variables few and structured.
Keep a text twin for any reference image the planner can't see.

If you'd rather not build the plumbing yourself, you can try the whole pipeline at inkdoo.app. Paste a post or drop in a link or a .md/.docx file. New accounts get two free images. I'd love to hear how you're handling character consistency in your own projects.

hi

xianyu110 — Tue, 28 Jul 2026 14:37:19 +0000

hii

test

xianyu110 — Wed, 22 Jul 2026 10:50:06 +0000

test