Half Your Scripts Need Zero Installs: Why Stdlib-Only Products Sell Better
The moment I knew I had a problem: a buyer messaged me that make_metadata.py crashed on import. Nothing was wrong with the script. It needed pandas, and their Python was 3.8 on a locked-down work laptop. They gave up. I lost the sale, but more importantly, I realized most of my tooling was overbuilt. The parts people actually needed could do the job with nothing but the standard library.
The install wall kills more sales than bad code
Every third-party package is a door a buyer can trip on. pip install is easy for you and me. For someone who just wants their Vecteezy CSV to have the right headers, it is friction. Venv activation, a Python version mismatch, a corporate proxy, a broken wheel on Windows.
In my pipeline, two of the four tools import nothing outside the standard library. make_metadata.py builds the exact Adobe 5-column, Vecteezy 4-column and Dreamstime 15-column upload CSVs using only csv, os and argparse. upload_tracker.py is a ledger built on plain file reads and writes. There is no install step. Python 3.9+ and you're running.
I stopped treating that as a compromise and started treating it as the product feature. A tool that runs before a buyer finishes reading the readme is a tool they trust.
Platform rules are the real spec, not your code
Here is what the scripts enforce, because these are the mistakes I made writing the rulebook by hand first:
All three channels reject a wrong CSV header immediately. Not on review, on upload. Adobe wants 5 columns, Vecteezy wants 4, Dreamstime wants 15. Get the header wrong and the entire batch bounces. make_metadata.py writes the header they demand and nothing else, so that class of rejection disappears.
The second rule is for your own safety: double-posting. The fastest way to get an account flagged is running your batch twice. upload_tracker.py keeps a ledger, so pending items.txt shows only what is not done yet, and a re-run never posts twice. Both of these scripts are stdlib-only. The two rules that save the most accounts cost zero installs.
Where a package earns its place
I am not anti-library. I am strict about which ones.
pack_product.py needs Pillow because it renders a 1280x720 cover and a 600x600 thumbnail, and I am not writing an image decoder. md2pdf.py needs reportlab because it produces a styled PDF with headings, tables, lists and links. Those two are the only third-party packages in the kit.
The test I use now: does the package replace a job that would take me weeks to do correctly, or is it a convenience wrapper around something in os and csv? Pillow and reportlab pass. The rest didn't.
The install section of the kit reflects this directly. pip install -r requirements.txt installs pillow and reportlab. If you only use make_metadata.py and upload_tracker.py, skip the install. They need nothing but Python.
The pipeline that shipped 39 products on a 2 GB box
This kit is not a demo. It packaged 39 products, 856 MB of output, off a pipeline with roughly 19,000 lines of code and 300+ pages of research behind the rules it enforces. It ran on one vCPU, 2 GB RAM, no GPU. The habits that made that possible are boring and specific:
Process one file at a time. Never fan out image jobs on a single core. Call gc.collect() after each item. Measure peak RSS with resource.getrusage(RUSAGE_SELF).ru_maxrss, not average memory, because the peak is what crashes you. Run heavy render steps as one file per subprocess so memory returns to the OS. And render previews at 60 dpi when you are just checking, not 300.
None of that needs a framework. None of it needs a cloud account. A stdlib script and a habit of measuring peak memory will outlast a fancy stack on a small box.
The folder layout gets deleted most often
The structure the kit assumes is assets/ for raw output, output/ for ready-to-submit files plus metadata.csv, packs/ for finished zips and covers, research/ for notes and sources, and scripts/ for the tools.
Keep research/ forever. I deleted mine once to clean up, and it cost me every scrape log and note that would have become the next three products. Your notes are inventory. Treat them like it.
The honest close
Everything above is what I build with, not a theory. The four scripts in the starter kit are the same ones in that 39-product run, and two of them need no install at all. If that is the layer you are missing, the full product is called digital asset factory, and it is built from this exact work: the stdlib tools, the two packages that earn their place, and the pipeline that ran on 1 vCPU and 2 GB.
Building digital products? Free guides & kits for digital product sellers.
Top comments (0)