DEV Community: Muhamad Revanza Rafif Hamdani

One Pillow Script, Two Sizes: Cover Decisions Behind 39 Packaged Products

Muhamad Revanza Rafif Hamdani — Sun, 25 Oct 2026 12:42:18 +0000

I still have the first cover I rendered with Pillow. It was a 1280×720 JPEG of a product that looked fine in my image viewer and like a blurry mess on Gumroad. The problem was not the art. I had rendered the text layer at screen resolution and let Pillow downsample the whole composition, so the title antialiased into mush. That one bad cover sat on product number one for two days while I rewrote the script that now packages all 39.

Here is what I learned about covers, sizes, and the decisions behind them.

Two sizes, one script, and why both exist

pack_product.py renders exactly two images per product: a cover at 1280×720 and a thumbnail at 600×600. That is not arbitrary. The 1280×720 cover is the wide format that marketplaces and product pages expect. The 600×600 square is what gets cropped to a circle on social cards and looks right in grid views where a wide banner becomes a thin sliver.

The decision that fixed my blurry mess: render text at final resolution. Never compose at a smaller size and resize up, and never render sharp text and then let the cover get scaled down by the platform. Pillow draws text at whatever point size you give it on whatever canvas you give it, so I set the canvas to 1280×720 from the start and pick font sizes that hold up at 600×600 when the thumbnail version resamples the same composition.

What goes on the cover

Every cover gets three things: the product title, a short subtitle, and the count of files inside. That last one comes straight from the command line:

python pack_product.py my-product "My Product" "A short subtitle" 9

That 9 is the file count, and putting it on the cover was one of the better decisions I made. Buyers on asset marketplaces want to know what they are getting before they click. A cover that says "9 files" answers the first question without anyone opening the listing. It also forced me to actually know the count for every product, which caught two packs where I had miscounted during zipping.

The script bundles the zip and renders both images into a _system folder next to where you run it. I made that configurable with --dir or a PACK_ROOT environment variable after I filled up a working directory with 39 covers and could not find anything.

The constraint that shaped everything: 1 vCPU and 2 GB of RAM

None of this ran on a beefy machine. The whole pipeline, covers included, ran on a single-core box with 2 GB of RAM and no GPU. That changes how you write a Pillow script.

The rules I ended up with:

One image job at a time. No parallel rendering on a 1-core box, it just thrashes.
gc.collect() after each asset, because Pillow image objects hold buffers longer than you expect.
Measure peak RSS with resource.getrusage(RUSAGE_SELF).ru_maxrss, not average memory. Average tells you nothing about whether the process dies at asset 30 of 39.
Render at the resolution you need. A 600×600 thumbnail does not need a 4000 px source in memory.

The cover renderer follows all of these. It loads the background, draws the text layers, saves both sizes, and releases everything before the next product starts. That is why 39 products packaged on a machine that would choke on a parallel batch.

Where the covers fit in the wider pipeline

Covers are step four. Before any product gets packaged, the assets already went through make_metadata.py, which writes the exact upload CSVs each marketplace demands: Adobe's 5-column header, Vecteezy's 4-column, Dreamstime's 15-column. All three reject a wrong header instantly, so the script writes the header they demand and nothing else. And upload_tracker.py keeps a ledger of what has been posted, because running a batch twice is the fastest way to get an account flagged.

The point is that the cover is not a design decision in isolation. It is the last step of a chain, and if any earlier step is wrong, the prettiest cover in the world sits on top of a rejected upload. That is why the kit is four small scripts and not one monolith. Two of them, make_metadata.py and upload_tracker.py, use only the Python standard library. The other two need exactly two third-party packages: Pillow for covers, reportlab for PDFs.

What I would tell someone starting today

Do not hand-make 39 covers in a design tool. Do not make 39 different cover designs either. One script, one layout, two sizes, variable text. Consistency across a catalogue reads as professionalism even when the layout is simple, and it means packaging product number 40 takes the same thirty seconds as product number 1.

The total output of this pipeline was 39 products, 856 MB, backed by about 19,000 lines of pipeline code and 300+ pages of research. The four scripts are the packaging layer I kept reaching for, so I cleaned them up and documented them as the pipeline starter kit. If you want the same scripts, including the cover renderer with the two sizes and the RAM habits baked in, they are here:

Get pipeline starter kit

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

Two Dependencies Total: Pillow And Reportlab Are All Your Product Needs

Muhamad Revanza Rafif Hamdani — Sun, 25 Oct 2026 12:42:07 +0000

Last February I lost a whole evening to a CSV header. I had 40 finished JPEGs ready for Adobe Stock, generated the metadata file, uploaded it, and got an instant rejection. Not a warning, not a partial accept. Rejected. The problem was one column: Adobe's upload CSV wants exactly five columns in a specific order, and I had six. A single extra field, probably a trailing keyword I thought was helpful, and the whole batch was dead on arrival.

That night I rewrote the metadata step as a script that writes the header the platform demands and nothing else. It became the first of four tools that now package every product I sell. This post is about why those tools need exactly two third-party dependencies, and why I think that number matters more than people realize.

The four things that actually stall you

Making the art is the fun part. What stalls solo makers is everything after it. In my case it was four specific things:

Metadata. Adobe wants a 5-column CSV, Vecteezy wants 4 columns, Dreamstime wants 15. Get the header wrong and the upload is rejected before a human ever sees your work.
Double-posting. Run your batch script twice, as I did once, and you can post the same asset twice. That is one of the fastest ways to get an account flagged. I now keep a ledger script that remembers what is done, so a re-run is impossible.
Turning a document into a product. You have the content, but a raw Markdown file does not look like something anyone would pay for.
Packaging. A zip with a real cover image sells. A bare file does not.

My solution for all four is four standalone Python scripts. No framework, no cloud account, no database server.

Why only two dependencies

Here is the full list of third-party packages across all four scripts: Pillow and reportlab. That is it.

Pillow renders the product covers (1280 by 720) and thumbnails (600 by 600). reportlab turns Markdown into a clean styled PDF with headings, tables, lists, and links. The other two scripts, the metadata builder and the upload tracker, use the Python standard library alone. If you only need those two, you install nothing at all.

I did not set out with a minimalism goal. It fell out of running this on a small server. The whole pipeline runs on 1 vCPU and 2 GB RAM with no GPU. Every dependency you add is memory you do not have, a version conflict you will eventually debug at midnight, and a supply chain surface you have to think about. Pillow and reportlab are both mature, both do exactly one job well, and both fit comfortably in 2 GB when you use them one file at a time.

The practical rule I landed on: if the standard library can do it with under about fifty lines of code, write the fifty lines. CSV writing, file tracking, zip creation, all of that is built in. Only reach for a package when the job genuinely needs it, like image rendering or PDF layout.

The small server habits that make it work

Two dependencies do not help if your process eats the box. These habits are what let the pipeline run on that 1-core machine:

One process at a time. Never fan out image jobs in parallel on a single core. It does not go faster, it just swaps.
Call gc.collect() after each asset. Freeing memory between items keeps peak usage flat instead of climbing.
Measure peak RSS, not average. resource.getrusage(RUSAGE_SELF).ru_maxrss gives you the real ceiling. Average memory lies.
Run heavy render steps as one file per subprocess, so memory is actually returned to the OS when the file finishes.
Render at the resolution you need. Inspecting a preview at 60 dpi instead of 300 is the difference between fitting in RAM and not.

For scale reference: these scripts packaged 39 finished products, 856 MB of output, as part of a parent project with around 19,000 lines of pipeline code. The rules behind them came from 300+ pages of research into what the stock platforms actually accept and reject.

The folder structure that keeps a catalogue sane

One structural decision saved me more time than any script: a fixed layout for every project.

project/
  assets/            raw output, one file per asset
  output/            ready-to-submit files plus metadata.csv
  packs/             finished product zips plus covers
  research/          notes and sources
  scripts/           the tools

The one I got wrong early: keep research/ forever. I deleted scrape logs and notes once to clean up, then needed them two months later for a follow-up product and had to redo the work. Your research folder is raw material for future products. It is not clutter.

Where the tooling lives now

Those four scripts, make_metadata.py, upload_tracker.py, md2pdf.py, and pack_product.py, are the packaging layer of everything I sell. They are collected, documented, and shipped as part of the ai sticker factory playbook, which is the honest writeup of this whole system: the prompt side, the platform rules, the RAM constraints, and the packaging scripts, all validated on that same 1 vCPU, 2 GB box. If you want the same pipeline without rediscovering the CSV header rules the hard way, that is where it is.

Get ai sticker factory playbook

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

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

Muhamad Revanza Rafif Hamdani — Sat, 24 Oct 2026 23:12:43 +0000

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

I had 39 products zipped and ready. Then I opened one of the zips on a marketplace preview page and watched it render as a grey file icon next to thumbnails that actually looked like products. Nothing was broken in the files themselves. The packaging was broken. A zip with no cover is not a product. It is a download link with extra steps.

That moment changed how I build. Here is what I learned, and the rules that came out of it.

The cover is the product, on screen

Buyers never see your files. They see the thumbnail first, then the cover, and only sometimes the file list. My pipeline had scripts for metadata, tracking, and PDF generation, but packaging was an afterthought. That was backwards.

pack_product.py now does the whole job in one command: it zips the files, renders a 1280×720 cover, and a 600×600 thumbnail. The cover gets the product title and a short subtitle. The thumbnail is the thing that survives being squeezed into a grid of 20 other listings.

You can run it 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 next to where you run it. Output location is configurable with --dir or the PACK_ROOT environment variable, so you do not edit the script per project.

Bad metadata dies before your file does

The second thing I learned is that platforms reject you before they ever look at the asset. A wrong CSV header is an instant bounce. Adobe wants a 5 column file. Vecteezy wants 4 columns. Dreamstime wants 15. One script, make_metadata.py, writes the exact header each channel demands and nothing else.

python make_metadata.py ./my-assets --platform adobe --out metadata.csv --ext .jpg

There is a real temptation to hand edit these CSVs. Do not. Build them from the folder. If you pass --titles titles.json you get real titles and keywords. Without it, the filename is title cased and used as a first pass title, which is fine for checking the pipeline runs, but replace it before you submit.

Running the batch twice is how accounts get flagged

The fastest way to get a seller account flagged is to upload the same 40 files twice because you lost track of what was already posted. upload_tracker.py is a ledger that makes that impossible:

python upload_tracker.py pending items.txt
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

Run pending before every session. Run done only after the upload confirms. The tracker remembers, so a re run never double posts. This sounds trivial until you are 200 files into a catalogue and genuinely cannot remember which batch went out on Tuesday.

The doc to product step

Some of what I sell is documentation: guides, notes, reference sheets. Those need to look like products, not like a text file someone renamed. md2pdf.py turns a Markdown file into a styled PDF with headings, tables, lists, and links:

python md2pdf.py content.md product.pdf "My Product Title"

One command, and the file goes from draft to shippable. It uses reportlab, which is one of only two third party packages in the whole kit. The other is Pillow, for the covers. The metadata and tracker scripts use the standard library alone, so if that is all you need, you skip the install entirely.

It all ran on one small server

Every number in this pipeline comes from a single 1 vCPU, 2 GB RAM, no GPU machine. No fan out, no parallel image jobs. One process at a time. gc.collect() after each asset so memory goes back. Peak RSS measured with resource.getrusage, not average, because the average hides the spike that kills you. Heavy render steps run one file per subprocess so the OS reclaims memory. Previews render at 60 dpi, not 300, because I am inspecting them, not printing them.

The parent project behind this shipped 39 products, 856 MB of output, from roughly 19,000 lines of pipeline code and over 300 pages of research. That volume is why the rules exist. The tracker exists because of a near miss. The cover rule exists because of the grey file icon.

Keep the research folder

One structural rule worth its own paragraph. This is the folder layout the kit assumes:

project/
  assets/     raw output, one file per asset
  output/     ready-to-submit files + metadata.csv
  packs/      finished zips + covers
  research/   notes and sources
  scripts/    the tools

Keep research/ forever. Scrape logs and notes are the raw material for the next product. I deleted mine once to clean up and I will not make that mistake again.

What this kit actually is

These four scripts are the packaging layer I wish I had on day one. They are not a tutorial that ends at "here is how you would". They are the working tools, running the same rules that got 39 products out the door.

If you want the full version of this, the reasoning behind each rule, the platform headers, the RAM habits, and the build flow from prompt to finished product, that is what the ai sticker factory playbook collects. The scripts are the how. The playbook is the why, plus the mistakes that produced the rules.

Start with one product. Give it a 1280×720 cover and a 600×600 thumbnail. Then zip it.

Get ai sticker factory playbook

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

Two Lines in Requirements.txt: Pillow, Reportlab, and Nothing Else

Muhamad Revanza Rafif Hamdani — Sat, 24 Oct 2026 23:12:26 +0000

Two Lines in Requirements.txt: Pillow, Reportlab, and Nothing Else

The rejection email was four words long: "Invalid CSV header."

I had just spent three hours naming 60 vector files and writing titles. All of it was sitting in a spreadsheet I built by hand, and Vecteezy's uploader refused the whole batch because one column was in the wrong place. No partial credit. No "fix it and retry." Just reject.

That was the moment I stopped treating packaging as something I would do "later, carefully." It turns out "carefully" is not a schedule. So I wrote the scripts. They shipped 39 products out the door, and the entire dependency list is this:

pillow
reportlab

Two lines. The rest is the Python standard library. Here is what actually works and why.

Wrong headers get rejected instantly, so generate them

Adobe, Vecteezy and Dreamstime each want a different CSV. Adobe takes 5 columns, Vecteezy takes 4, and Dreamstime takes 15. Get one header text wrong and the whole upload dies before a human ever looks at your art.

So make_metadata.py does one job: it walks a folder of files and writes the exact header each platform demands, nothing more. Three runs, three files:

python make_metadata.py ./my-assets --platform adobe      --out metadata.csv   --ext .jpg
python make_metadata.py ./my-assets --platform vecteezy   --out vecteezy.csv   --ext .jpg
python make_metadata.py ./my-assets --platform dreamstime --out dreamstime.csv --ext .jpg

Without extra input, the filename is title-cased into the title. That is fine for a first pass, but replace it before you submit. The script accepts --titles titles.json when you have real titles and keywords ready.

This script needs no install. Standard library only. If metadata is the thing you keep putting off, you can fix it today with zero packages.

Double posting is how accounts get flagged

The second failure mode is sneakier. You run a batch halfway, something interrupts you, you run it again, and suddenly 40 of your 60 assets are live twice. Running a batch twice is the fastest way to get an account flagged.

upload_tracker.py is a plain ledger. It remembers what you have marked done, so a re-run only shows what is left:

python upload_tracker.py pending items.txt   # what is NOT done yet
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

No database, no cloud account, no sync service. A file plus a script. It has never failed me because there is nothing in it to fail.

A product needs a cover, and a PDF needs a renderer

A zip with a real cover sells. A bare file does not. That is the only reason Pillow is in the requirements. pack_product.py zips the files and renders a 1280x720 cover plus a 600x600 thumbnail:

python pack_product.py my-product "My Product" "A short subtitle" 9

The other package, reportlab, exists because a PDF with real headings, tables, lists and links makes a Markdown doc look like a product instead of a draft:

python md2pdf.py content.md product.pdf "My Product Title"

Those are the only two third-party packages. Everything else, the CSV generation, the tracking, the zip, runs on Python alone.

The whole pipeline ran on 1 vCPU and 2 GB of RAM

This is the part people find hard to believe. The pipeline that produced 39 products and 856 MB of output ran on 1 vCPU, 2 GB of RAM and no GPU. It held together because of a few unglamorous habits:

One process at a time. Never fan out image jobs in parallel on one core.
Call gc.collect() after each asset to free memory between items.
Measure peak RSS, not average. resource.getrusage(RUSAGE_SELF).ru_maxrss tells you the real ceiling.
Run heavy render steps as one file per subprocess, so memory goes back to the OS.
Render at the resolution you need. A 60 dpi preview beats a 300 dpi one when you are just checking.

The parent project has roughly 19,000 lines of pipeline code and 300+ pages of research behind the rules these scripts enforce. The scripts themselves are small. The point is that small is enough.

The folder layout that keeps it from turning into a junk drawer

project/
  assets/            raw output (one file per asset)
  output/            ready-to-submit files + metadata.csv
  packs/             finished product zips + covers
  research/          your notes and sources
  scripts/           these tools

Keep research/ forever. Scrape logs and notes are the raw material for the next product. Deleting them to "clean up" is a mistake I made once and will not repeat.

These four scripts sit at the packaging layer. Above them, the full pipeline runs on a free stack: Hermes Agent schedules jobs, retries failures and makes decisions, with 9Router handling local LLM access. The packaging layer is where the rules from 300+ pages of research get enforced, and it is the part you can copy today.

None of this is clever. The requirements file is two lines. The scripts are boring on purpose. That is exactly why they shipped 39 products instead of sitting in a backlog with the metadata CSVs I never got around to fixing.

If you are building vector packs, stickers or templates and the packaging keeps stalling you, this is the tool built from that work, the same scripts and the playbook behind them.

Get vector prompt pack

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

Requirements.txt as Discipline: Stdlib-Only Scripts Need No Install

Muhamad Revanza Rafif Hamdani — Sat, 24 Oct 2026 17:36:52 +0000

Requirements.txt as Discipline: Stdlib-Only Scripts Need No Install

The second time I ran my upload batch, I got the email I had been dreading. A channel had flagged my account for double-posting. Nothing had gone wrong with the art. Nothing had crashed. My pipeline had simply done its job twice, and now I was sitting there writing an apology to a stock platform over a batch of files I had already posted. That day I changed three things: I split my pipeline into small standalone scripts, I made two of them depend on nothing but the Python standard library, and I wrote a tracker so a re-run could never double-post again. After that, I packaged 39 finished products, 856 MB of output, with a toolset that runs on a single-core, 2 GB server.

The problem with a fat environment

Every side project starts with a frameworks wish list. Then reality shows up: a two year old script that only works because of a pinned dependency from a version you can't remember, a server with 2 GB of RAM where even installing packages takes forever, and an eventual move to a new machine that breaks everything quietly. When your pipeline codes packaging and metadata, what really hurts is brittleness.

So I built the pipeline as four separate scripts. Two of them, make_metadata.py and upload_tracker.py, use only the standard library. make_metadata.py builds the exact Adobe (5-col), Vecteezy (4-col) and Dreamstime (15-col) upload CSVs from a folder of files. upload_tracker.py is a ledger that remembers what you have already posted, so a re-run never double-posts. No install. No venv. python make_metadata.py ./my-assets --platform adobe --out metadata.csv --ext .jpg and the header the platform demands comes out, nothing else. The other two, md2pdf.py and pack_product.py, do need packages: Pillow for the covers and reportlab for PDF output. That is the entire dependency list. Two packages, and only two, and they are isolated in the two scripts that actually need to render pixels or pages.

That split is the whole point. A CSV generator and a ledger are pure text and logic. They have no business pulling in an image library, and when they do not, you can run them anywhere Python exists. Python 3.9+, a venv, pip install -r requirements.txt. If you only use the two stdlib scripts, you skip the install entirely.

Platform rules are the spec

The thing that makes metadata generation a good fit for a dependency free script is that the platforms publish their rules. All three channels reject a wrong CSV header instantly, which means the header is not a suggestion. make_metadata.py writes the header they demand. Not a superset, not a comment line someone thought was helpful, just the header. When I say the 300+ pages of research behind this pipeline matter, this is what I mean: the rules the scripts enforce are the same rules that got my files rejected before I read them properly.

The tracker follows the same logic. The fastest way to get an account flagged is running your batch twice, so upload_tracker.py pending items.txt shows what is not done yet, upload_tracker.py done "asset-001.jpg" records one, and status tells you where you stand. Nothing clever. A ledger file and some string handling. That is exactly why it has survived every environment change since.

The pattern generalizes

Once I saw how well the split worked, I applied it to the slow parts. On a 1 vCPU, 2 GB box with no GPU, the pipeline only works if you respect those limits:

One process at a time. Never fan out image jobs in parallel on a single-core box.
Call gc.collect() after each asset so memory actually comes back.
Measure peak RSS with resource.getrusage(RUSAGE_SELF).ru_maxrss, not average. The ceiling is what kills you.
Run heavy render steps one file per subprocess, so memory returns to the OS.
Inspect previews at 60 dpi instead of rendering at 300.

And keep a fixed folder layout, because a catalogue turns into a junk drawer without one:

project/
  assets/     raw output (one file per asset)
  output/     ready-to-submit files + metadata.csv
  packs/      finished product zips + covers
  research/   your notes and sources
  scripts/    these tools

Keep research/ forever. Deleting scrape logs to clean up was the mistake this project made once and won't repeat. That folder is the raw material for future products.

What the kit is for

The four scripts are the packaging layer of a prompt engine that turned one input into 39 finished products. The parent project is roughly 19,000 lines of pipeline code. The packaging tools themselves are the part you can pick up today: build the CSVs, track what you have posted, turn a Markdown doc into a product PDF, zip it with a 1280x720 cover and a 600x600 thumbnail. make_metadata.py and upload_tracker.py run on the standard library alone. pack_product.py writes into a _system folder and takes --dir or PACK_ROOT if you want it elsewhere. No framework, no cloud account.

I did not write this as a tutorial that ends at here is how you would do it. I wrote it because running your batch twice and getting flagged is a pain I would rather you avoid. The scripts did that for me.

Get vector prompt pack

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

Two Packages, One 2 GB Server: Requirements.txt as Product Discipline

Muhamad Revanza Rafif Hamdani — Sat, 24 Oct 2026 17:36:11 +0000

Two Packages, One 2 GB Server: Requirements.txt as Product Discipline

The first batch I ever ran twice returned 39 rejected CSVs in under a minute. Not because my art was bad. Because I had fat-fingered a header and then re-run the upload script, and every channel treated the second pass as a fresh submission. One mistake, a whole evening gone. That day I learned that the most expensive things in a product pipeline are not render times. They are the small, dumb, repeatable errors that a script should have made impossible.

This post is about that lesson, and about something that surprised me while cleaning up the kit built from that mess: the strongest proof of discipline in a pipeline is often a tiny requirements.txt.

The requirements file is a promise to yourself

The pipeline starter kit has four scripts. make_metadata.py builds upload CSVs. upload_tracker.py is the double-post ledger. md2pdf.py turns Markdown into a PDF. pack_product.py zips files and renders a cover at 1280x720 plus a thumbnail at 600x600.

Two of those need third-party packages: Pillow for covers, reportlab for PDFs. The other two need nothing at all, just the standard library.

So the install is two lines in requirements.txt. Not fourteen. Not a framework, not an SDK, not a cloud client. When your dependency list is that short, every package you add has to justify itself against the 2 GB machine it has to run on. That is not minimalism for its own sake. It is a budget, and the same instinct that says "no" to a new package is the instinct that says "no" to running your batch twice.

The rules a 2 GB box will teach you

This entire pipeline ran on 1 vCPU, 2 GB RAM, no GPU, and it packaged 39 products totaling 856 MB of output. That is not a flex. It is a constraint that forced the code into better habits:

One process at a time. Never fan out image jobs in parallel on a single core.
Free memory between items with gc.collect() after each asset.
Measure peak RSS, not average, using resource.getrusage(RUSAGE_SELF).ru_maxrss.
Process one file per subprocess for heavy render steps, so memory goes back to the OS.
Render at the resolution you need. A 60 dpi preview will tell you what a 300 dpi render at the wrong size will not.

Every one of those habits is also a reliability habit. A pipeline that never runs out of memory is a pipeline that finishes the batch, and a pipeline that finishes the batch once is a pipeline you do not re-run by accident.

The platform rules that eat whole evenings

The four scripts exist because of four specific failure points, and each one has a hard rule attached.

Metadata. Adobe wants a 5-column CSV. Vecteezy wants 4 columns. Dreamstime wants 15. Get the header wrong and the upload is rejected instantly. make_metadata.py writes the header the channel demands and nothing else.

Double posting. The fastest way to get an account flagged is submitting the same batch twice. upload_tracker.py is a ledger. pending items.txt shows what you have not posted. done "asset-001.jpg" marks it. A re-run physically cannot double-post because the script checks the ledger first.

Docs into products. You already have the content. md2pdf.py content.md product.pdf "My Product Title" makes it look like a product in one command.

Packaging. A zip with a real cover sells. A bare file does not. pack_product.py my-product "My Product" "A short subtitle" 9 writes the zip, the cover, and the thumbnail into a _system folder, or wherever --dir or PACK_ROOT points.

Note how small each rule is. None of them needs a service. None needs a database. They are all just scripts that refuse to guess.

The folder layout is part of the requirements

A catalogue becomes a junk drawer within a week unless you fix the structure first. The kit assumes one shape:

project/
  assets/      raw output, one file per asset
  output/      ready-to-submit files plus metadata.csv
  packs/       finished zips and covers
  research/    your notes and sources
  scripts/     these tools

The one rule I will defend hardest is keeping research/. Those scrape logs and notes are raw material for the next product. Deleting them to "clean up" is a mistake this project made once and is not repeating.

What is actually inside the kit

Four standalone Python scripts. No framework. No cloud account. Python 3.9+.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

If you only use the metadata and tracker scripts, you can skip the install entirely. They need nothing but Python.

Opt into real labels with --titles titles.json when you have them. Without it, the filename is title-cased and used as the title, which is fine for a first pass and wrong for a submission.

The honest part

These scripts came out of a parent project with roughly 19,000 lines of pipeline code and more than 300 pages of research behind the rules they enforce. I cut it down because the rules did not need 19,000 lines. They needed four scripts, a short requirements file, and the discipline to not add to either.

Get pipeline starter kit

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

Running a 39-Product Asset Pipeline on a 2 GB Single-Core VPS

Muhamad Revanza Rafif Hamdani — Sat, 24 Oct 2026 17:14:34 +0000

Running a 39-Product Asset Pipeline on a 2 GB Single-Core VPS

The morning I knew the pipeline was broken, I was staring at a Dreamstime upload screen telling me my CSV header was invalid. Row one, column one. Nothing else. I had 39 finished products, 856 MB of output, around 19,000 lines of pipeline code behind them, and no idea which of the three channel formats I had mangled. That rejection cost me a morning and taught me the rule this whole build runs on: the platform format is the contract, and everything else is decoration.

Here is what actually works when you have one core, 2 GB of RAM, no GPU, and no patience for a second failed batch.

The four jobs that actually stall you

Making the art is the fun part. The four things that stop a solo maker are metadata, double posting, doc to product conversion, and packaging. Each one has a narrow, dumb solution.

For metadata, all three channels reject a wrong CSV header instantly. Adobe wants 5 columns, Vecteezy wants 4, Dreamstime wants 15. A small script that writes exactly that header, derived from a folder of files, removes an entire class of rejection.

For double posting, the fastest way to get an account flagged is running your batch twice. A plain ledger file that records what you already submitted, and refuses to hand you the same item again, makes that impossible. It also gives you a pending view so you always know what is left.

For turning a doc into a product, the content already exists. It just needs to look like something you would pay for. One command that turns Markdown into a clean PDF with headings, tables, lists, and links gets you there.

For packaging, a zip with a real cover sells. A bare file does not. So the pack step zips the files and renders a 1280x720 cover and a 600x600 thumbnail in the same pass.

One process, more RAM than you think

The RAM problem on a 2 GB box is not average usage. It is the peak. A single image job can look harmless and then spike when you least expect it.

Four habits made the whole pipeline fit on 1 vCPU:

Run one process at a time. Never fan out image jobs in parallel on a single core. Parallelism on one core is just slower work with a higher memory ceiling.
Call gc.collect() after every asset. It is one line and it keeps your footprint flat across a 39 product run.
Measure peak RSS, not average. resource.getrusage(RUSAGE_SELF).ru_maxrss gives you the real number, and the real number is what kills a small box.
Process one file per subprocess for heavy render steps. The OS gets the memory back when the process exits, which is more reliable than trusting your own cleanup code.
Render at the resolution you need. A preview inspected at 60 dpi costs a fraction of the same preview at 300.

None of this is clever. It is the difference between a box that finishes the batch and one that gets killed mid-run with half a product folder on disk.

Two packages, no framework, no cloud account

The pipeline needs exactly two third party libraries. Pillow for the covers and thumbnails. Reportlab for the PDF output. The metadata builder and the upload tracker use the standard library alone, so they run on a bare Python with no install at all.

That matters more than it sounds. Every dependency you add is another thing that can fail on a fresh server at 2 AM, and another reason the pipeline needs a babysitter. Python 3.9, a virtual environment, pip install pillow reportlab, and you are done.

The folder layout is the other half of the discipline. Without one, a catalogue turns into a junk drawer within a month:

project/
  assets/      raw output, one file per asset
  output/      ready to submit files plus metadata.csv
  packs/       finished product zips and covers
  research/    notes and sources
  scripts/     the tools

Keep research/ forever. The scrape logs and notes are the raw material for future products. Deleting them to clean up is a mistake this project made once and will not repeat.

The rules behind the scripts

Every header, column count, and required field in the kit traces back to something concrete. Three channel formats. A fixed set of required metadata per platform. A cover size of 1280x720 and a thumbnail of 600x600. The kit enforces those because a wrong one costs you a rejection and a re-upload, and a re-upload batch is exactly how accounts get flagged.

That is also why the tracker sits in front of the upload step. The pipeline does not trust memory, yours or mine. It trusts a ledger file.

The 39 products, the 856 MB of output, and the 300 plus pages of research behind these rules were all validated on that same 1 vCPU, 2 GB, no GPU box. The numbers are not a benchmark. They are what this rig actually produced.

Where this came from

These four scripts are the packaging layer, not a framework. If you want the exact tools that turned one prompt engine into 39 finished products, they are packaged as the compliance metadata kit: the metadata builder for Adobe, Vecteezy, and Dreamstime, the upload tracker, the Markdown to PDF converter, and the product packer. Standalone Python, two dependencies, the same rules enforced.

Get compliance metadata kit

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

No GPU, No Cloud: Four Python Scripts That Package Stock Assets for Three Platforms

Muhamad Revanza Rafif Hamdani — Sat, 24 Oct 2026 17:13:10 +0000

No GPU, No Cloud: Four Python Scripts That Package Stock Assets for Three Platforms

I still remember the moment the rejection landed. I had spent a weekend generating a batch of vector assets, opened the Adobe Stock contributor portal, and watched the upload fail on the CSV uploaded to the system. Wrong column count. Seven hours of production, blocked by a header row. That was the day I stopped trusting "I'll just build the CSV by hand" and wrote the first of the four scripts that now package everything I sell.

Here is what actually ships my work, and why each piece exists.

The four scripts and the two dependencies

The whole kit is four standalone Python files. No framework, no cloud account, no GPU.

make_metadata.py builds the exact Adobe (5 column), Vecteezy (4 column) and Dreamstime (15 column) upload CSVs from a folder of files.
upload_tracker.py is a ledger that remembers what you already posted, so a re-run never double-posts.
md2pdf.py turns a Markdown file into a styled PDF with headings, tables, lists and links.
pack_product.py bundles a product: it zips the files and renders a cover at 1280x720 plus a thumbnail at 600x600.

Only two third-party packages are involved: Pillow for the covers in pack_product.py, and reportlab for the PDF output in md2pdf.py. The metadata and tracker scripts use the standard library alone, so you can run them without installing anything.

Why metadata is the real bottleneck

All three platforms reject a wrong CSV header instantly. Not on review, not a day later. Instantly, at upload. Adobe wants five columns, Vecteezy wants four, Dreamstime wants fifteen, and none of them agree on the order.

make_metadata.py writes the header each platform demands and nothing else:

python make_metadata.py ./my-assets --platform adobe --out metadata.csv --ext .jpg
python make_metadata.py ./my-assets --platform vecteezy --out vecteezy.csv --ext .jpg
python make_metadata.py ./my-assets --platform dreamstime --out dreamstime.csv --ext .jpg

You can pass --titles titles.json to supply real titles and keywords. Without it, the filename gets title-cased and used as the title, which is fine for a first pass. Replace it before you submit for real.

The double-post trap

The fastest way to get a contributor account flagged is running your batch twice. It happens to almost everyone: you upload, something looks off, you re-run the script, and now the same asset exists twice.

upload_tracker.py makes that impossible:

python upload_tracker.py pending items.txt   # shows what is NOT done yet
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

A ledger beats memory. On a 39 product run, nobody remembers which sticker got posted on Tuesday.

Packaging on 1 vCPU and 2 GB of RAM

This entire pipeline ran on a single core, 2 GB of RAM, with no GPU. That is not a brag, it is a constraint I had to design around. A few habits made it work:

One process at a time. Never fan out image jobs in parallel on a one core box.
Free memory between items. Call gc.collect() after each asset.
Measure peak RSS, not average. resource.getrusage(RUSAGE_SELF).ru_maxrss tells you the real ceiling.
Process one file per subprocess for heavy render steps, so memory goes back to the OS.
Render at the resolution you need. Checking a preview at 60 dpi beats rendering it at 300.

Packaging itself is one command:

python pack_product.py my-product "My Product" "A short subtitle" 9

That writes my-product.zip, my-product-cover.jpg and my-product-thumb.jpg into a _system folder. Point it elsewhere with --dir or the PACK_ROOT environment variable, no need to edit the script.

A zip with a real cover sells. A bare file does not.

The folder layout that keeps a catalogue from rotting

Structure is what separates a product line from a junk drawer:

project/
  assets/            raw output (one file per asset)
  output/            ready-to-submit files + metadata.csv
  packs/             finished product zips + covers
  research/          your notes and sources
  scripts/           these tools

Keep research/ forever. Your scrape logs and notes are the raw material for the next product. Deleting them to clean up is a mistake this project made once and will not repeat.

The numbers behind this

These scripts are the packaging layer of a pipeline that produced 39 finished products, 856 MB of output, backed by roughly 19,000 lines of pipeline code in the parent project and 300 plus pages of research behind the rules the scripts enforce. All of it validated on 1 vCPU, 2 GB of RAM and no GPU.

Above the four scripts sits a free stack: an orchestrator that schedules jobs, retries failures and makes decisions, plus a local LLM proxy for model access, both at zero cost. No cloud bill, no rented GPU.

Where to get the full system

The scripts are the tool. The rules they enforce, the folder layout, the RAM discipline, the platform header specs and the order of operations, are the playbook. I packaged all of it as the ai sticker factory playbook, because the four scripts alone will still leave you guessing what to feed them and in what order.

Build the pipeline once. Then let it run while you make more art.

Get ai sticker factory playbook

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

Two Packages, One Server: Metadata CSVs, Covers and PDFs for 39 Products

Muhamad Revanza Rafif Hamdani — Sat, 24 Oct 2026 12:42:01 +0000

Two Packages, One Server: Metadata CSVs, Covers and PDFs for 39 Products

The first time a stock platform rejected one of my upload batches, it took me four hours to understand why. One column was out of order in the CSV. That's it. I had generated 39 products, zipped them, written the docs, and the batch died on a header row.

That rejection changed how I build. I stopped treating metadata and packaging as the boring afterthought and wrote scripts that enforce the rules instead of leaving them to my attention span at 1 a.m. Here is what actually matters.

Three platforms, three headers, no mercy

Adobe wants five columns. Vecteezy wants four. Dreamstime wants fifteen. Get one wrong and the whole file bounces before a human ever sees your art. I built one script, make_metadata.py, that writes the exact header each platform demands and nothing else. You point it at a folder:

python make_metadata.py ./my-assets --platform adobe --out metadata.csv --ext .jpg

It title-cases the filename and uses that as a first pass. Fine for a dry run, not fine for submission. Pass --titles titles.json to supply real titles and keywords before you upload. The script does not guess, it writes the columns.

If you only use this one and the tracker, you need no install at all. Standard library only.

A ledger beats your memory

The fastest way to get an account flagged is running a batch twice. I got close once. It was 861 files, a re-run after a crash, and only a gut feeling that stopped me. After that I wrote upload_tracker.py. It remembers what you posted:

python upload_tracker.py pending items.txt   # what is NOT done yet
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

A re-run of the same list cannot double-post, because the ledger knows. This is the least glamorous tool in the kit and the one I would pay for.

Docs that look like products

You have the content. You need it to look like something worth buying. md2pdf.py turns a Markdown file into a clean styled PDF with headings, tables, lists and links:

python md2pdf.py content.md product.pdf "My Product Title"

Packaging: a zip alone does not sell

pack_product.py zips the files and renders two images: a cover at 1280×720 and a thumbnail at 600×600.

python pack_product.py my-product "My Product" "A short subtitle" 9

It writes the zip, cover and thumb into a _system folder next to where you run it. Point it elsewhere with --dir or the PACK_ROOT environment variable. No editing the script.

That is the entire dependency story: two third-party packages across four scripts. Pillow for the covers, reportlab for the PDFs. Nothing else.

It ran on 1 vCPU and 2 GB of RAM

The full pipeline produced 39 products, 856 MB of output, from a single-core server with no GPU. It works because of five habits, not hardware:

One process at a time. Never fan out image jobs in parallel on a one-core box.
Free memory between items. gc.collect() after each asset.
Measure peak RSS, not average. resource.getrusage(RUSAGE_SELF).ru_maxrss tells you the real ceiling.
One file per subprocess for heavy render steps, so memory returns to the OS.
Render at the resolution you need. Inspecting a preview at 60 dpi beats rendering it at 300.

The folder layout matters too. Keep assets/, output/, packs/, research/ and scripts/ separate. And keep research/ forever. I deleted scrape logs once to "clean up." They were the raw material for the next three products. I won't repeat that.

What this came from

These four scripts sit under a larger pipeline: roughly 19,000 lines of code in the parent project, with 300+ pages of research behind the rules the scripts enforce. The tools are the packaging layer of everything I sell.

I packaged them as the compliance metadata kit: the four working scripts, the folder structure, and the RAM notes above. Not a tutorial that ends at "here's how you'd do it." The same tools that shipped 39 products on a 2 GB server.

If you have ever lost a day to a rejected CSV column, start there.

Get compliance metadata kit

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

The Stdlib Ledger That Stops a Re-Run From Double-Posting Uploads

Muhamad Revanza Rafif Hamdani — Sat, 24 Oct 2026 12:41:51 +0000

The Stdlib Ledger That Stops a Re-Run From Double-Posting Uploads

I nearly lost an upload account to a rerun. My batch script had already pushed 200 files to a stock site. I wanted to check one thing, so I ran the script again. It did not check anything. It started uploading from the top. I caught it around item 40 by watching the progress bar scroll past filenames I recognized. The platform had not flagged me yet, but that is luck, not a system.

The fix was not a smarter uploader. It was a ledger. upload_tracker.py is about 40 lines of standard library Python, and it does one thing: it remembers what you have already posted. That alone removed the most dangerous failure mode in the whole pipeline.

Why a rerun is the fastest way to get flagged

Stock platforms treat repeated identical submissions as spam. A second upload of the same file is not just wasted time, it is a signal. Do it across a few hundred files and you move from "new seller" to "pattern to review."

The usual workaround is a naming convention plus eyeballing a folder. That breaks the moment you batch-generate files, because regenerated filenames shift. The ledger moves the source of truth out of the filesystem and into a state file that only the tracker writes.

The commands are deliberately dumb:

python upload_tracker.py pending items.txt   # shows what is NOT done yet
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

No database, no cloud, no install. upload_tracker.py uses the standard library alone. The ledger is local state, and local state on a 1 vCPU, 2 GB box is exactly what you want.

The rule the ledger enforces: `pending` is the only input

Once the tracker exists, the workflow changes shape. You do not run a batch from your asset folder. You run it from pending. The batch script asks the ledger what is unfinished, and the ledger returns only items with no done record.

That gives you three guarantees for free:

Rerun safety. If a job dies halfway, rerun it. The completed half is skipped.
Resumability. You can stop at any point and pick up tomorrow.
Auditability. status tells you exactly what went out, without reading platform dashboards.

I have not double-posted since. Not once. The ledger costs nothing to maintain because it has no dependencies, and the failure it prevents is the one that cannot be undone.

The same rule, applied to CSVs

The double-post problem has a quieter twin: rejected batches. All three channels reject a wrong CSV header instantly, and a rejected batch wastes a review cycle. make_metadata.py writes the exact header each platform demands:

Adobe: 5 columns
Vecteezy: 4 columns
Dreamstime: 15 columns

One command per platform:

python make_metadata.py ./my-assets --platform adobe --out metadata.csv --ext .jpg

It also uses only the standard library. It reads a folder, writes the header the platform demands, and nothing else. If you pass --titles titles.json it uses your real titles and keywords. Without it, filenames are title-cased as a first pass. That is fine for testing, but replace it before you submit.

Two packages, and only two

The rest of the kit stays lean by design. Only pack_product.py needs Pillow for covers and thumbnails, and only md2pdf.py needs reportlab for PDF output. If you use just the metadata and tracker scripts, you can skip pip install entirely. On a machine this small, fewer dependencies means fewer failure modes.

The packaging step follows the same pattern. pack_product.py bundles a zip with a 1280x720 cover and a 600x600 thumbnail, because a zip with a real cover sells and a bare file does not. Output goes to a _system folder, and you can redirect it with --dir or the PACK_ROOT environment variable, with no script edits.

What this looked like in production

This is not a thought experiment. The parent project produced 39 finished products, 856 MB of output, backed by roughly 19,000 lines of pipeline code and more than 300 pages of research, all on 1 vCPU, 2 GB RAM, no GPU. The habits that made that possible:

One process at a time. Never fan out image jobs on a 1-core box.
Free memory between items. Call gc.collect() after each asset.
Measure peak RSS, not average. resource.getrusage(RUSAGE_SELF).ru_maxrss tells you the real ceiling.
Render at the resolution you need. A 60 dpi preview beats a 300 dpi render for inspection.

The ledger sits above all of this. It is the cheapest component in the stack and the one that taught me the most: in an automated pipeline, the state file matters more than the code that runs.

What I packaged from this

I pulled the four working scripts into a starter kit: make_metadata.py, upload_tracker.py, md2pdf.py and pack_product.py, with the folder layout that scales (assets/, output/, packs/, research/, scripts/) and the RAM notes above. Keep research/ forever, by the way. I deleted mine once to "clean up" and will not repeat that mistake.

The tracker is the piece that makes the kit safe to run more than once. Everything else is packaging.

Get compliance metadata kit

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

Building Upload Tracker Ledger With Python Stdlib Before Your First Upload

Muhamad Revanza Rafif Hamdani — Fri, 23 Oct 2026 17:13:58 +0000

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

Stop Double-Posting Stock Assets With CSV Ledger That Remembers Every Upload

Muhamad Revanza Rafif Hamdani — Fri, 23 Oct 2026 17:13:43 +0000

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

DEV Community: Muhamad Revanza Rafif Hamdani

One Pillow Script, Two Sizes: Cover Decisions Behind 39 Packaged Products

Two sizes, one script, and why both exist

What goes on the cover

The constraint that shaped everything: 1 vCPU and 2 GB of RAM

Where the covers fit in the wider pipeline

What I would tell someone starting today

Two Dependencies Total: Pillow And Reportlab Are All Your Product Needs

The four things that actually stall you

Why only two dependencies

The small server habits that make it work

The folder structure that keeps a catalogue sane

Where the tooling lives now

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

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

The cover is the product, on screen

Bad metadata dies before your file does

Running the batch twice is how accounts get flagged

The doc to product step

It all ran on one small server

Keep the research folder

What this kit actually is

Two Lines in Requirements.txt: Pillow, Reportlab, and Nothing Else

Two Lines in Requirements.txt: Pillow, Reportlab, and Nothing Else

Wrong headers get rejected instantly, so generate them

Double posting is how accounts get flagged

A product needs a cover, and a PDF needs a renderer

The whole pipeline ran on 1 vCPU and 2 GB of RAM

The folder layout that keeps it from turning into a junk drawer

Requirements.txt as Discipline: Stdlib-Only Scripts Need No Install

Requirements.txt as Discipline: Stdlib-Only Scripts Need No Install

The problem with a fat environment

Platform rules are the spec

The pattern generalizes

What the kit is for

Two Packages, One 2 GB Server: Requirements.txt as Product Discipline

Two Packages, One 2 GB Server: Requirements.txt as Product Discipline

The requirements file is a promise to yourself

The rules a 2 GB box will teach you

The platform rules that eat whole evenings

The folder layout is part of the requirements

What is actually inside the kit

The honest part

Running a 39-Product Asset Pipeline on a 2 GB Single-Core VPS

Running a 39-Product Asset Pipeline on a 2 GB Single-Core VPS

The four jobs that actually stall you

One process, more RAM than you think

Two packages, no framework, no cloud account

The rules behind the scripts

Where this came from

No GPU, No Cloud: Four Python Scripts That Package Stock Assets for Three Platforms

No GPU, No Cloud: Four Python Scripts That Package Stock Assets for Three Platforms

The four scripts and the two dependencies

Why metadata is the real bottleneck

The double-post trap

Packaging on 1 vCPU and 2 GB of RAM

The folder layout that keeps a catalogue from rotting

The numbers behind this

Where to get the full system

Two Packages, One Server: Metadata CSVs, Covers and PDFs for 39 Products

Two Packages, One Server: Metadata CSVs, Covers and PDFs for 39 Products

Three platforms, three headers, no mercy

A ledger beats your memory

Docs that look like products

Packaging: a zip alone does not sell

It ran on 1 vCPU and 2 GB of RAM

What this came from

The Stdlib Ledger That Stops a Re-Run From Double-Posting Uploads

The Stdlib Ledger That Stops a Re-Run From Double-Posting Uploads

Why a rerun is the fastest way to get flagged

The rule the ledger enforces: pending is the only input

The same rule, applied to CSVs

Two packages, and only two

What this looked like in production

What I packaged from this

Building Upload Tracker Ledger With Python Stdlib Before Your First Upload

Stop Double-Posting Stock Assets With CSV Ledger That Remembers Every Upload

The rule the ledger enforces: `pending` is the only input