This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What if your whole marketing team fit on a laptop, and finished in 55 seconds?

I used to run an ecommerce brand.

In small ecommerce, marketing is everything, and it comes in two kinds.

Performance marketing is the ads you pay for. Organic marketing is the posts, reels and listings you put out without paying for reach. Both run on a constant stream of fresh content. If it isn't live, you aren't selling.

Every product meant listing copy stitched together from two or three AI chats, then ad copy, photo edits, images for the listing, and video ads. Every step in a different tool. Every handoff a copy and paste.

It cost me in three ways:

• Time. The gap between "I have a product" and "it's live" was where sales were lost.
• Cashflow. A subscription for images, one for video, one for copy, one for editing. In a small business, tool bills quietly eat tight cashflow.
• Privacy. My product details, my pricing and my workflow all sat inside other people's tools. None of it was ever private.

Then I watched my mom run into the same wall.

My mom is a cosmetician. She sells skincare and beauty products, and she is very good at it. Her marketing is organic: Instagram and Facebook posts and reels.

But one single image post took her 3 to 4 hours.

Canva for the picture. CapCut or another editor for the video. ChatGPT or Claude for the caption, then copy, paste, "make it shorter", copy, paste again. Then the post itself, on every platform she sells on. A reel could take days.

On top of that, she kept switching between ChatGPT, Claude, Higgsfield and whatever other AI tool she could find, often across several accounts to keep going. That irritated her a lot.

Those are hours she should have spent with customers. Instead she was working as a part-time designer and video editor.

Different business, same trap: too many tools, too much attention, and your product details sent to places you don't control.

So I built Mochi: one product photo and a few true facts become studio photos, an image deck, a 10-second video and copy for every platform you sell on. It runs on open models on your own computer, so nothing about your product goes to anyone else's server.

I built it for my mom and for sellers like me, and I tried it on a real brand to see if it works. More on that session is further down.

Here it is in action:

Here's the proof. A skincare brand, Velora, dropped three photos of a face cleanser into Mochi. This is the screen when it finished:

Fifty-five seconds. And this is what it had made.

9 studio photos on a designed backdrop:

A 5-slide image deck (this is slide 3 of 5):

A 10-second vertical video ad, with text cards built from the copy:

Listing copy, tags and an SEO title, each one editable:

No agency. No stack of subscriptions. No uploading your product to someone else's server. Just open models running on one computer.

What I Built

Mochi turns that whole chain of tools, tabs and copy-pasting into three taps.

You get:

• Studio photos. Your phone photo, cut out and placed on a designed backdrop, and the product is never regenerated, so it stays your real product
• An image deck. Slides ready for a feed or a catalog
• A 10-second vertical video. Camera moves and text cards built from your own copy
• Platform copy. Listing, social, Pinterest and a video brief, written for each place you sell

One thing I care about more than anything: Mochi checks its own copy for things you never told it. Models do invent claims, so every kit is checked by plain code. Missing facts are listed back to you ("Not provided, so left out of the copy"), and anything the copy says that isn't in your facts is flagged before you post.

For a skincare seller, that matters. "Reduces wrinkles" is a legal claim, not a style choice.

How to use it

Five steps, about two minutes of your time. The screenshots are from a real run on a phone.

The shortcut: add a photo, and if Mochi's guesses from it look right, tap Looks right: generate now. Everything below is the long way, for when you want control.

Step 1. Add your photos.
Tap Take photo or Add more. You can add up to 5. The first photo is your Main one, and it also opens and closes your video. Different angles make a better video and deck. A clear photo on a plain background works best. Mochi starts reading them right away.

Step 2. Check what Mochi found.
Mochi reads the label on your product and offers the text as notes you can tap to add. Fields it filled in are tagged "From photo, check it". Fill in what's missing, like price and features. Only add what is true. Blank fields are flagged as missing, never guessed.

Step 3. Pick your style.
Choose where you sell (Instagram, Facebook, Pinterest, Etsy, Shopify), a tone (from Straightforward to Luxury), a goal (Drive sales, Brand awareness, Gift appeal or Explain features), and a writing speed:

• Fast takes about 20 seconds
• Best quality uses a larger model and takes about a minute

Then pick a backdrop for your photos and video: Premium studio, UGC-style, Minimal, Warm and cozy, or Bold and colorful. Tap Generate kit.

Step 4. Let it build.
You see real progress, step by step: writing copy, building studio photos and video, adding text to the video. You can leave the page. It keeps running.

Step 5. Review, edit and share.
Your kit has four tabs:

• Overview: the video, the image deck, and a "double-check before posting" list
• Copy: listing, social, Pinterest and a video brief. Change the tone or refresh any section.
• Photos: your studio photos, ready to download
• Share: download or share the kit

The finished result of a real run is at the top of this post.

Nothing posts on its own. The only thing Mochi can send anywhere is a Shopify draft, and only when you tap it.

Demo

Every page of the web app

Landing: hero

Landing: the interactive studio

Landing: written the way each channel works

Landing: your next ad starts with a photo

Landing: upload once, get the lot

Landing: same facts, your voice

Landing: three steps, about a minute

Landing: call to action

Create: start

Create step 1: photos, and the text Mochi read from them

Create step 2: product facts

Create step 3: tone, goal, speed and visual style

Result: overview with video ad and image deck

Result: copy for every channel

Result: studio photos, white background and cut-outs

Result: share and export

Stores

Code

Backend: FastAPI, SQLite, Pydantic. Frontend: Next.js 16 and React 19. 135 backend tests pass. Every number in this post can be reproduced from the files in backend/finetune/results/, with the commands in docs/RESULTS.md.

How I Built It

Two lanes run at the same time: one for visuals and one for language. They meet at the deck and the video, which need the finished copy. The page polls the job every 1.5 seconds and shows real progress and partial copy as it arrives.

Every model has one job and one strict contract.

Two choices worth explaining:

• The video is not AI-generated. It's image processing plus FFmpeg, so the product in the video is your product, not a regenerated lookalike. (I do denoise, upscale and retouch it.) Generative video tends to repaint the product.
• The checker is plain code, not a second model. A model can talk itself into anything. A word list and a number check can't.

The copy is split into parallel parts (four core parts plus one per platform), each forced into a JSON schema. A bad call is retried once, and plain code then checks for forbidden words, invented numbers and unsupported claims.

Photos are read, never trusted. Up to 5 photos are shrunk to 768 px and read under strict rules. What comes back is only a suggestion, marked "From photo, check it".

Studio shots: measure, cut out, refine the product's pixels, fix the tone, pick a backdrop from what the photo shows, compose. If the cutout looks wrong, it falls back to a framed photo instead of a bad cutout.

The video: at least 4 shots rendered with FFmpeg (up to 3 at once), 0.4 s crossfades, text cards from your edited copy, checked to be 10 seconds at 1080x1920. Edit the copy and only the text layer re-renders.

Why it's fast. My first version took 90 to 145 seconds for one big generation on a laptop.

A four-photo kit went from about 100 s to about 18 s in Fast mode. The trade-off: the 4B model gets more claims flagged than the 12B, the post-check still catches them, and Best quality (about 57 s) is one switch away.

The fine-tune, the evaluation and the Sentry setup each have their own section under Prize Categories.

Why Does Open Innovation Matter?

Go back to my two stories. In both, the real cost was not money alone. It was control.

1. Your product details stay yours. Pricing, ingredients, launch plans. With open models running locally, the data never leaves your machine. There's no "we don't train on your data" to trust.

2. No per-kit fee. Every kit costs electricity. A seller can run it five times, try three tones, and never wonder if it's "worth" the credits. When cashflow is tight, that matters.

3. I could change the model, not just the prompt. I fine-tuned a small open model to follow one rule: don't invent claims. Prompting alone left the 4B model at 23% clean kits. Training took it to 88%. You can't do that to a closed model, or download what you trained.

4. I could look inside and measure. I tested the fine-tune against an independent judge model, not just my own checker. With a closed API I'd have one number and no way to question it.

5. One setting swaps the model. Fast or Best quality is a single switch between two open Gemma models. The next Gemma release is a one-line change.

The honest limit: open models need a computer that can run them. I wrote the local setup into the README.

My Agent Session

I built Mochi with Claude Code, and every session is recorded with Entire. docs/DECISIONS.md lists 19 decisions, each with its reason, its commit and its Entire checkpoint, so you can read the conversation behind any choice. More in the Entire section below.

My First User

Velora, a skincare brand, ran its Sensicontrol Face Cleanser through Mochi on a phone, on 16 October 2026. The phone reached my computer over a Cloudflare tunnel, so for this demo the photos passed through Cloudflare. In normal use everything stays on the machine. I have the screen recording. Here is what happened, taken only from what is on screen.

I don't have a written quote from them, so I'm not putting words in their mouth. What I do have is the recording, and it shows what they actually did.

They followed the five steps above (the screenshots for steps 1 to 4 are from their session): three photos of the bottle, the label read off it, a persuasive tone, Best quality writing, Pinterest as the platform, and the warm and cozy backdrop.

What came out is shown at the top of this post: the finished kit in 55 seconds, the studio photos, the deck, the video and the copy. It was built on Best quality, with three photos, by a Gemma 3 12B model running on my own computer.

The part I care about most. Mochi told them what it had left out, and what it had written that they never said:

• "Not provided, so left out of the copy": dimensions, verified benefits, target audience, care instructions
• "Double-check before posting": Not in your facts: "available now". Remove it unless it's true.
• "About your photos": it skipped the close-up slide because the photo didn't have enough pixels on the product

The kit was five slides, nine studio photos, a 10-second video, and copy for one platform.

What I learned from watching. All of this is from the recording:

• They changed their mind before generating. They started with the Friendly tone, Instagram and Fast, then switched to Persuasive, Pinterest and Best quality. The choices clearly matter to people, so I'm glad nothing is locked in.
• They left several facts blank, and the copy respected that. Target audience, dimensions, verified benefits and care instructions were never filled in, so Mochi left them out and said so, instead of guessing.
• Best quality costs time. The form says Fast takes about 20 seconds and Best quality about a minute. They chose the slower one, and it took 55.

Prize Categories

I'm entering Tinker, Gemma, Sentry Agent Tracing and Entire. Each section covers what I used, why, what it was meant to fix, and what I found.

Best Use of Tinker

What I used it for. I fine-tuned Qwen3.5-4B with a LoRA adapter on Tinker to write marketing copy that follows one rule: never invent a claim the seller didn't give.

Why Tinker. Prompting a small model to follow that rule didn't work. Untuned Qwen3.5-4B produced a clean kit only 18% of the time. I wanted to change the model, not keep rewording the prompt, and Tinker let me train without running my own GPU servers.

How it worked.

1. A big teacher model, Qwen3.5-397B-A17B, writes and revises kits on Tinker
2. My checker and an independent judge (Gemma 12B, a different model family) reject any kit with an invented claim, number or forbidden word
3. The teacher revises with the checker's findings, at most 2 rounds
4. Only kits that pass both the checker and the judge become training data (zero hard violations)
5. A small student is trained on those: rank 32, 3 epochs, 319 examples, learning rate 2e-4
6. A held-out set of 60 products, which the training code refuses to read, tests it

The whole thing cost $5.41 of the $10 credit.

The full detailed version (tap to open it full size and zoom in):

Results (60 held-out synthetic products, one checker):

The full detailed version (tap to open it full size and zoom in):

That's a 4B model, a third of Gemma 12B's size, producing nearly twice as many clean kits, and about 10 times faster (4.9 s against 48.7 s per kit, though v2 runs on Tinker's cloud and Gemma on my laptop).

The honest result on the judge. v2 halves the untuned model's flags (0.43 to 0.20), but the confidence intervals overlap, and Gemma 12B is lower still at 0.13. With 30 kits per model I can't claim more than that.

Limits I'm stating on purpose:

• The test set is synthetic, and the checker also filtered the training data
• The fine-tune runs on Tinker, so its inputs leave the machine. The app's default (Gemma via Ollama) stays local.
• The fine-tune is not in the app's path yet. I haven't exported it to GGUF for Ollama.
• Hosted cost is about $3 per 1,000 kits, estimated from token counts

What I learned. A small model trained on the right examples can follow a narrow rule better than a larger model that's only prompted. The checker and the judge decide which examples count, so they matter as much as the training run.

Best Use of Gemma

What I used it for. Gemma does three jobs inside Mochi, all through Ollama on the seller's own computer:

1. The copy writer. Gemma 3 4B for Fast, Gemma 3 12B for Best quality
2. The photo reader. It reads up to 5 photos and returns suggested facts, each tagged "From photo, check it"
3. The independent judge. Gemma 3 12B, a different family from the Qwen teacher, reviews kits in my evaluation

The full detailed version (tap to open it full size and zoom in):

The full detailed version (tap to open it full size and zoom in):

Why Gemma. It's open-weight, it runs on one machine, and it can be held to a JSON schema. That matters here: the seller's facts shouldn't leave their computer, and every part of a kit must come back as strict, checkable JSON.

What it was meant to fix. The cost and privacy problems from my ecommerce days: no per-kit fee, and nothing sent to anyone else's server.

Results.

• Both sizes run the same prompt and the same checker, so I could compare them fairly: 23% clean kits on 4B and 45% on 12B
• Speed is the trade-off. Fast (4B) builds a four-photo kit in about 18 s, Best quality (12B) in about 57 s
• As the judge, Gemma 12B had the fewest flags of any model I tested (0.13 per kit)

What I learned. Two things. First, the model size is a user choice, not a technical one, so I made it a switch on the form. Second, the judge is Gemma, so it may be lenient toward Gemma's own writing. That bias favours the Gemma rows and works against my fine-tune's claim, so it can't be inflating my result.

Best Use of Sentry Agent Tracing

What I used it for. Tracing every model call and every job, without Sentry ever seeing a seller's product facts.

Why this was the hard part. A marketing tool handles a seller's most private material: product details, prices, plans. Sending prompts to a tracing service would break the promise the whole product makes. So the question was not "can I trace this", it was "can I trace this and prove nothing private leaks".

The full detailed version (tap to open it full size and zoom in):

• Each model call is a gen_ai.chat span, with the model, token counts and latency
• Each generation job is a transaction
• Each flagged claim is an issue (which rule fired, and how many)
• Each seller report is an event. The report button sends a section name and a fixed reason code, never free text

The flagged claims come from the copy post-check, so each issue is a rule the code caught, not a model's opinion.

The full detailed version (tap to open it full size and zoom in):

What it never sees. An allow-list scrubber removes everything that is not on the list of allowed metadata. Product facts, copy, photos and prompts can't pass it.

How I know it works. A canary test pushes a unique fake product through every input path of the real app, then fails if that marker shows up in any outgoing Sentry payload. It's in tests/test_tracing.py.

Results and honesty. The scrubber and the canary test are in place and pass. I am not claiming Sentry has caught a real production incident, because it hasn't. Mochi has had one real user session, not production traffic.

What I learned. Making tracing safe was a bigger design question than turning it on. The allow-list approach (what's permitted, not what's blocked) is the one that survives new fields being added later.

Best Use of Entire

What I used it for. To record how Mochi was built, so a reader can see why the code is the way it is, not just what it does.

Why. Most repos show a result. For a project where I changed my mind several times, the changes are the story. A privacy rule, a new default and a safety check each have a reason that a commit message can't hold.

What came of it.

• About 113 checkpoints of Claude Code sessions, pushed to the repo
• docs/DECISIONS.md: 19 numbered decisions, each with the reason, the commit and the Entire checkpoint ID
• Anyone can run entire checkpoint explain <id> in a clone and read the prompts, files and reasoning behind a decision

The most useful example. Decision #11 records why Sentry only ever gets metadata, and how the scrubber enforces it. That kind of reasoning normally disappears. Here it is written down, with the conversation that led to it.

Honest limit. Checkpoints from before Entire was enabled were imported from local history and matched by time. They show the conversation a commit came out of, not a one-to-one record.

---

If you sell something and make your own content, I'd love to hear what's missing. Tell me in the comments.

Built solo, with Claude Code.