Last March I almost shipped a product with a requirements.txt that had eleven packages in it. Requests, beautifulsoup4, a YAML lib, two PDF libraries, an image toolkit, and a few things I honestly could not explain. A buyer opened an issue before launch: "I just wanted to make a CSV, why am I installing a web scraper?" That comment stung because it was right. I had bundled my whole pipeline's dependencies into one file and called it a product.
I rewrote everything that week. The result is four standalone scripts and a requirements.txt with exactly two lines. Here is what changed and why it matters if you are selling tools to other makers.
Buyers read requirements.txt before they read your README
When someone pays $9 for a script bundle, the install step is the first trust test. Eleven packages says "this is a mess, good luck." Two packages says "I know what this does." Pillow for cover rendering, reportlab for PDF output. That is it. Two of the four scripts, the metadata builder and the upload tracker, use only the Python standard library. No install at all. If a buyer only wants Adobe and Vecteezy CSVs, they run the script on a bare Python 3.9 install and it works.
That split matters commercially. The people buying metadata tools are often the least technical sellers in your audience. Every pip install is a place they can quit.
The CSV headers are the real product
This is the part I got wrong for months. Adobe Stock wants a five column upload CSV. Vecteezy wants four columns. Dreamstime wants fifteen. Get one header wrong and the platform rejects the whole file instantly, and you learn nothing about why. I burned an afternoon in February resubmitting a 40 asset batch three times because one column name was off.
So make_metadata.py hardcodes the exact headers for all three platforms and writes nothing else. No config, no template editing. You point it at a folder of JPGs, pass --platform adobe, and get a CSV that passes the first review check. The filename becomes a title cased title, which is fine for a first pass, but the script accepts a titles.json so you can supply real titles and keywords before you submit. Platforms do judge your metadata quality, and a filename like asset_041_final.jpg as a title does not help you.
Double-posting is the fastest way to get flagged
The failure mode nobody warns you about: you run your upload batch, something times out on row 17, you fix it, you run the batch again. Now rows 1 through 16 are duplicated. Stock platforms treat that as spam behavior and it puts a mark on your account.
upload_tracker.py is a dumb ledger, about a hundred lines, standard library only. pending shows what is not done yet, done marks an asset, status gives you the count. It is not clever. It is the difference between a re-run being safe and a re-run being a ban risk. When your pipeline runs unattended at 2am, dumb and reliable beats smart.
Packaging is where a file becomes a product
A zip of loose files does not sell the same way a zip with a real cover does. pack_product.py does three things in one command: zips the files, renders a 1280x720 cover, and a 600x600 thumbnail. One third party dependency, Pillow, already in the requirements file.
This script alone has packaged 39 products for me, 856 MB of finished output, running on a server with 1 vCPU and 2 GB RAM and no GPU. The small server constraint shaped the code more than any feature request did. One process at a time, gc.collect() between assets, and render previews at 60 dpi instead of 300 when you are only inspecting. If you are generating AI images at a few cents each and batch producing, memory discipline is what keeps a $5 VPS viable.
The folder layout is part of the tool
Every script assumes one structure: assets/ for raw output, output/ for submission ready files and CSVs, packs/ for finished zips and covers, research/ for notes, scripts/ for the tools. The mistake I made once and will not repeat was deleting research/ during a cleanup. My scrape logs and notes were the raw material for three later products. Keep it forever, it is cheap.
What I would tell the me from last March
Slim requirements are not about elegance, they are about conversion. Every dependency you remove is a buyer who gets to a working first command. Four scripts, two packages, standard library where possible, and a ledger so an unattended run cannot ruin your account standing.
That rewrite became the packaging layer of a bigger system. The parent project is around 19,000 lines of pipeline code backed by 300+ pages of research, and it has produced 1,700 assets so far, with 58 live on Adobe Stock and a first sale of $0.99 that I screenshot because it proved the whole thing worked end to end. The scripts in this post are the four tools from that system that other sellers kept asking for, bundled as the Digital Asset Factory. It is the honest version, not a get rich promise, just the working tools and the rules they enforce.
Building digital products? Free guides & kits for digital product sellers.
Top comments (0)