I had 39 finished products sitting in a folder and nothing to show for it.
This was a Tuesday night in the middle of the build. I had zipped up a bundle of assets, written a short description, and dropped the zip into my Gumroad draft. I looked at the preview and saw a gray file icon. No cover, no thumbnail, nothing that looked like a product. I almost published it anyway because I was tired. I did not, and that hesitation turned into one of the most useful lessons of the whole project: a zip is not a product until it has a cover.
Here is what I learned fixing that, and the rules I now bake into every package automatically.
The cover is the product page
Marketplaces and storefronts both render a preview. Gumroad shows a thumbnail in your product card. Adobe Stock shows the image itself, so the problem is less visible there, but for anything you sell as a bundle, the 1280×720 cover is the first and often only thing a buyer sees before deciding.
A bare zip gives them a file icon. That converts at roughly zero. My first sale on Adobe Stock was $0.99, and even at that scale the difference between a listing with a real cover and one without is the difference between looking like a shop and looking like a folder someone uploaded by accident.
So the rule became: nothing ships without a 1280×720 cover and a 600×600 thumbnail. Not "when I get around to it". Automatically, every time.
Making it automatic was the fix
I did not need better covers. I needed to stop relying on my memory to make them. The packaging step in my pipeline now does three things in one command: zips the files, renders the cover at 1280×720, and renders the thumbnail at 600×600. It uses Pillow, which is one of only two third-party packages in the whole packaging layer. The other is reportlab for PDFs. Everything else is standard library.
The command looks like this:
python pack_product.py my-product "My Product" "A short subtitle" 9
It writes the zip, the cover, and the thumb into a _system folder, and you can redirect that with --dir or an environment variable. No editing the script, no manual image work in an editor at midnight. The reason this matters is not speed. It is that a step you do by hand is a step you will skip on the tenth product, and the tenth product is the one that goes live looking unfinished.
The same lesson applies to metadata
Covers are the visible version of a broader rule: marketplaces reject anything that does not match their exact format. Adobe Stock's upload CSV has a 5-column header. Vecteezy uses 4 columns. Dreamstime wants 15. Get one column wrong and the upload fails instantly, before a human ever looks at your work.
I learned this by having batches bounced for header mismatches. The fix was the same as with covers: stop doing it by hand. My metadata script reads a folder of files and writes the exact header each platform demands, nothing else. Filenames become title-cased titles by default, which is fine for a first pass, but I always pass a titles file with real titles and keywords before submitting, because filename titles read as filename titles.
Double-posting is the other silent killer
Once you automate packaging, the next failure mode is running your upload batch twice. That is the fastest way to get an account flagged on stock platforms. After a long session of uploads, it is genuinely hard to remember which of 58 assets already went to Adobe.
So the pipeline keeps a ledger. A tiny tracker script records what is done, shows what is pending, and makes a re-run a no-op for anything already posted. It uses the standard library alone, no install at all. This is the least glamorous code in the project and possibly the most valuable.
All of this ran on 1 vCPU and 2 GB of RAM
None of the rendering above needed a big machine, but it needed discipline. The whole pipeline, including cover rendering for 39 products and 856 MB of output, ran on a single core with 2 GB of RAM and no GPU. The habits that made it work:
- One image job at a time, never parallel on one core.
-
gc.collect()after each asset to free memory between items. - Measure peak RSS with
resource.getrusage(RUSAGE_SELF).ru_maxrss, not averages, because the peak is what kills a 2 GB box. - One file per subprocess for heavy renders, so memory actually returns to the OS.
- Inspect previews at 60 dpi, render finals at the resolution you need.
The covers themselves are 1280×720 JPEGs. That renders in seconds on a 1-core box. The bottleneck was never compute, it was process.
Where this ended up
The project behind all this produced about 1,700 assets, 58 of which are live on Adobe Stock, and a first sale of $0.99. Around 19,000 lines of pipeline code and 300+ pages of research went into figuring out which rules actually matter. The four packaging scripts above, the metadata builder, the upload tracker, the Markdown to PDF converter, and the cover renderer, are the parts I would tell any solo maker to build first, because they are what turns output into products.
I packaged them up as the digital asset factory, the full system built from this work. It is the same scripts that packaged those 39 products, documented honestly, no promises about income. If you are building your own pipeline, it saves you the metadata rejections and the midnight cover problem.
Building digital products? Free guides & kits for digital product sellers.
Top comments (0)