DEV Community

Cover image for The 1280 720 Lesson: Why a Zip Isn't Shippable Until It Has a Cover"**

The 1280 720 Lesson: Why a Zip Isn't Shippable Until It Has a Cover"**

The 1280×720 Lesson: Why a Zip Isn't Shippable Until It Has a Cover

I had 39 products zipped and ready. Then I opened one of the zips on a marketplace preview page and watched it render as a grey file icon next to thumbnails that actually looked like products. Nothing was broken in the files themselves. The packaging was broken. A zip with no cover is not a product. It is a download link with extra steps.

That moment changed how I build. Here is what I learned, and the rules that came out of it.

The cover is the product, on screen

Buyers never see your files. They see the thumbnail first, then the cover, and only sometimes the file list. My pipeline had scripts for metadata, tracking, and PDF generation, but packaging was an afterthought. That was backwards.

pack_product.py now does the whole job in one command: it zips the files, renders a 1280×720 cover, and a 600×600 thumbnail. The cover gets the product title and a short subtitle. The thumbnail is the thing that survives being squeezed into a grid of 20 other listings.

You can run it like this:

python pack_product.py my-product "My Product" "A short subtitle" 9
Enter fullscreen mode Exit fullscreen mode

It writes the zip, the cover, and the thumb into a _system folder next to where you run it. Output location is configurable with --dir or the PACK_ROOT environment variable, so you do not edit the script per project.

Bad metadata dies before your file does

The second thing I learned is that platforms reject you before they ever look at the asset. A wrong CSV header is an instant bounce. Adobe wants a 5 column file. Vecteezy wants 4 columns. Dreamstime wants 15. One script, make_metadata.py, writes the exact header each channel demands and nothing else.

python make_metadata.py ./my-assets --platform adobe --out metadata.csv --ext .jpg
Enter fullscreen mode Exit fullscreen mode

There is a real temptation to hand edit these CSVs. Do not. Build them from the folder. If you pass --titles titles.json you get real titles and keywords. Without it, the filename is title cased and used as a first pass title, which is fine for checking the pipeline runs, but replace it before you submit.

Running the batch twice is how accounts get flagged

The fastest way to get a seller account flagged is to upload the same 40 files twice because you lost track of what was already posted. upload_tracker.py is a ledger that makes that impossible:

python upload_tracker.py pending items.txt
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status
Enter fullscreen mode Exit fullscreen mode

Run pending before every session. Run done only after the upload confirms. The tracker remembers, so a re run never double posts. This sounds trivial until you are 200 files into a catalogue and genuinely cannot remember which batch went out on Tuesday.

The doc to product step

Some of what I sell is documentation: guides, notes, reference sheets. Those need to look like products, not like a text file someone renamed. md2pdf.py turns a Markdown file into a styled PDF with headings, tables, lists, and links:

python md2pdf.py content.md product.pdf "My Product Title"
Enter fullscreen mode Exit fullscreen mode

One command, and the file goes from draft to shippable. It uses reportlab, which is one of only two third party packages in the whole kit. The other is Pillow, for the covers. The metadata and tracker scripts use the standard library alone, so if that is all you need, you skip the install entirely.

It all ran on one small server

Every number in this pipeline comes from a single 1 vCPU, 2 GB RAM, no GPU machine. No fan out, no parallel image jobs. One process at a time. gc.collect() after each asset so memory goes back. Peak RSS measured with resource.getrusage, not average, because the average hides the spike that kills you. Heavy render steps run one file per subprocess so the OS reclaims memory. Previews render at 60 dpi, not 300, because I am inspecting them, not printing them.

The parent project behind this shipped 39 products, 856 MB of output, from roughly 19,000 lines of pipeline code and over 300 pages of research. That volume is why the rules exist. The tracker exists because of a near miss. The cover rule exists because of the grey file icon.

Keep the research folder

One structural rule worth its own paragraph. This is the folder layout the kit assumes:

project/
  assets/     raw output, one file per asset
  output/     ready-to-submit files + metadata.csv
  packs/      finished zips + covers
  research/   notes and sources
  scripts/    the tools
Enter fullscreen mode Exit fullscreen mode

Keep research/ forever. Scrape logs and notes are the raw material for the next product. I deleted mine once to clean up and I will not make that mistake again.

What this kit actually is

These four scripts are the packaging layer I wish I had on day one. They are not a tutorial that ends at "here is how you would". They are the working tools, running the same rules that got 39 products out the door.

If you want the full version of this, the reasoning behind each rule, the platform headers, the RAM habits, and the build flow from prompt to finished product, that is what the ai sticker factory playbook collects. The scripts are the how. The playbook is the why, plus the mistakes that produced the rules.

Start with one product. Give it a 1280×720 cover and a 600×600 thumbnail. Then zip it.

Get ai sticker factory playbook


Building digital products? Free guides & kits for digital product sellers.

Top comments (0)