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

I zipped forty files, filled the CSV, hit submit, and the listing went live with a gray box where the preview should be.

No preview meant no one clicked. No clicks meant no sales. It sat there for two weeks before I noticed, and the first real sale I ever got, for $0.99, came from a different pack that happened to have a proper cover.

The files were fine. The packaging was not. That is the whole lesson, and it took me 1,700 made assets and 58 live listings on Adobe to learn it properly. Making the art is the easy part now. Shipping it is where everyone stalls.

A zip is not a listing

I used to think a product was the files inside the zip. Buyers never see the files until after they pay. What they see first is one image: the cover. A folder of 40 SVGs and a folder of 40 SVGs plus a clean 1280×720 cover are the same product with a different chance of selling.

So I stopped treating the cover as the last step. It gets generated at the same time as the zip, from the same run. One command produces my-product.zip, my-product-cover.jpg at 1280×720, and my-product-thumb.jpg at 600×600. If the run fails to produce all three, the product is not done. That rule alone fixed my conversion problem more than any keyword pass did.

The metadata header is the first gate

Every platform rejects a bad header instantly. Not after review, instantly, at upload. Adobe wants a 5-column header. Vecteezy wants 4 columns. Dreamstime wants 15. Get the count wrong by one and the whole batch bounces back with no useful error.

Once I stopped hand-editing CSVs, this stopped being a problem. A script writes the exact header each platform demands and nothing else. If you only use that one script, skip the venv entirely, it runs on the standard library with no install.

The part people get wrong: the script will title-case the filename and use it as the title if you do not supply anything better. That is fine for a first pass and terrible for a real submission. Replace the titles before you upload. I learned that after watching a batch of listings rank for nothing.

The re-run is what gets accounts flagged

Fastest way to lose an account is running your batch twice. The upload fails halfway, you re-run it, half your assets post in duplicate, and now you are explaining yourself to support.

So there is a ledger. pending items.txt shows what is not done. done "asset-001.jpg" marks one. status shows where you are. The script refuses to double-post. It is boring and it is the single thing that saved me from a suspension I would have earned.

1 vCPU, 2 GB RAM, no GPU

The whole pipeline that packaged 39 products, 856 MB of output, ran on a single core with 2 GB of memory. No GPU. These are the habits that made that possible:

• One process at a time. Never fan out image jobs on one core.
• Free memory between items. gc.collect() after each asset.
• Measure peak RSS, not average. resource.getrusage(RUSAGE_SELF).ru_maxrss gives the real ceiling, averages lie.
• One file per subprocess for heavy renders, so memory returns to the OS.
• Render previews at 60 dpi. There is no reason to inspect anything at 300.

None of this is clever. It is just refusing to do more work than the box can hold. The parent project is around 19,000 lines and 300+ pages of research behind the rules these scripts enforce, and most of that research exists because I broke something first.

What actually ships a product

Four steps, in this order:

1. Metadata CSV. Right header, real titles.
2. Ledger. Know what is already posted.
3. Doc to PDF, if the product is written content. One command, styled output.
4. Package. Zip plus cover plus thumb, generated together.

Only two third-party packages in the whole set, Pillow for the covers and reportlab for the PDFs.

That is the pipeline. The cover was not decoration. It was the difference between a folder and a listing, and it took a $0.99 sale to make me see it.

Get digital asset factory

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