Bloated requirements.txt Is a Red Flag: Why "Just Two Packages" Tells Buyers You Actually Run This Code

I still remember the afternoon I opened a file that looked like a confession. I had just bought a "productivity pipeline" from another maker. The requirements.txt inside had 47 packages. Beautiful, right? Then I ran it. It crashed on line one because the author had pinned pandas to a version that no longer existed. It didn't even have a packaging shim. That file had clearly been generated by an editor that guesses imports, not by someone who ever typed pip install and watched it finish. I refunded and moved on. That day I made a rule for anything I sell: my dependency list must be so short a buyer can verify it by reading it in seven seconds.

Here is what I learned building a real pipeline that shipped, and why "just two packages" is something I now put front and center.

The file is a receipt, not a wish list

A requirements.txt is proof of work. When it has 40 entries, one of three things is true: the author vendored architecture they never used, the author copied a template, or the author never actually ran the tool on a clean machine. All three are bad news for a buyer who is about to hand over their own files.

My kit has four scripts and exactly two third-party packages. Pillow renders the covers in pack_product.py. Reportlab writes the PDF output in md2pdf.py. The other two scripts, make_metadata.py and upload_tracker.py, import nothing outside the standard library. You can run the metadata builder and the upload ledger on a fresh Python install with no pip install at all.

That is not minimalism as a design aesthetic. It came from a hard constraint: the whole pipeline ran on 1 vCPU, 2 GB RAM, no GPU. A forty-package stack eats that box alive before your first asset renders.

Every dependency has a job or it gets cut

The discipline that produced those two packages was simple. A package had to be the shortest path to a specific feature, and I had to be able to name the feature in one sentence.

Pillow makes the 1280×720 cover and 600×600 thumbnail. Reportlab makes a styled PDF with headings, tables, lists, and links. Done. No jinja2, no markdown, no click for argument parsing. The argparse in the standard library is fine. No cloud SDK because there is no cloud account. That is deliberate: nothing in the kit phones home.

A buyer can open requirements.txt, see two names, and understand exactly what they are installing and why. That trust is worth more than any framework convenience.

It has already survived the only test that matters

Dependencies are easy to list and hard to keep working. The real test is running the thing on a bare machine at scale. This kit's scripts are the same ones that packaged 39 finished products (856 MB of output) out of roughly 19,000 lines of pipeline code in the parent project, backed by 300+ pages of research that shaped the rules the scripts enforce.

The scripts encode platform rules that break quietly otherwise. make_metadata.py writes the exact CSV headers each channel demands: Adobe at 5 columns, Vecteezy at 4, and Dreamstime at 15. Get a header wrong and the upload is rejected instantly. upload_tracker.py exists because running a batch twice is the fastest way to get an account flagged. A small, auditable dependency list is why those rules stay honest: there is nothing drifting underneath them.

Small footprint is a feature buyers can feel

Two packages means faster installs, fewer version conflicts, and no mystery native builds. If you are a solo maker running this on a $5 server or an old laptop, the difference between 2 and 47 packages is the difference between a working tool and a support thread.

The RAM habits matter here too. Run one process at a time. Call gc.collect() after each asset. Measure peak RSS with resource.getrusage, not average. Process one heavy render per subprocess so memory returns to the OS. Render previews at 60 dpi, not 300. Every one of those choices gets easier when your stack is two packages, not forty.

What I tell buyers now

If a seller cannot explain their requirements.txt line by line, ask why it is there. A buyer deserves to know that the code they are running was actually run by someone, not assembled.

The four scripts in the pipeline starter kit are the working tools, the same ones that shipped those 39 products on a single-core 2 GB box. They sit under a free stack in the full pipeline: Hermes Agent as the orchestrator at $0, 9Router as a local proxy for LLM access, and the rest of the packaging layer you can inspect.

If you have ever refunded a tool because it collapsed on first run, you already know why this matters. The shortest dependency list is the loudest proof that someone ran the code.

Get pipeline starter kit

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