I did not need 33 different ideas for this article. I needed four: a hero, a pipeline, a mobile comparison, and a quality-control story. The rest was production work.
That distinction changed how I make images for this site. The useful creative decision is the concept and its hierarchy. Repeating exports, formats, widths, dimensions, and social crops is mechanical. I moved that work into code, then kept the final visual judgment outside it.
Four concepts, 33 files
Each concept has two authored compositions: a 1600 × 900 landscape master and a 900 × 1200 portrait master. The portrait is not a crop. It preserves the same information with a different reading order and larger labels.
The static build expands those eight PNG masters into the delivery set:
8 authored PNG masters
8 full-resolution WebP files
16 responsive-width WebP files
1 Open Graph JPEG
--
33 production files
Calling these 33 individually designed images would be misleading. There are eight deliberate compositions and 25 derivatives. The value of the workflow is that the derivatives follow the masters without becoming 25 additional editing tasks.
Two stages, not one magic command
The workflow has an intentional pause:
generate masters -> inspect and correct -> build delivery assets
The generator encodes the house colors, type choices, facts, and coordinates in SVG, then Sharp renders the PNG masters. The static build reads those files, creates WebP versions and width candidates, makes this site's 1200 × 630 social crop, adds intrinsic dimensions, and writes the final <picture> markup.
The revised hero is deliberately hybrid: a generated bitmap supplies the atmospheric background, while SVG still owns every word, number, card, and arrow. That source background is not published directly, so the 33-file count covers the delivery set readers and social previews can actually receive.
That is repeatable inside this project environment, not a promise of identical pixels on every computer. Font files, Sharp, libvips, and SVG renderers can change raster output across machines. The source and build configuration make the process inspectable and repeatable here; they do not make the rendering stack universal.
Mobile needed a new composition
My first assumption was that responsive delivery meant smaller files. That only solves part of the problem. A landscape diagram reduced to a phone width can remain technically complete while its labels become useless. Cropping it can remove the evidence entirely.
The HTML standard calls the alternative art direction: selecting different image content for different presentation conditions. The mobile masters keep every fact, but stack the hierarchy vertically. The browser can then choose an appropriate width from each composition's own srcset.
Researching this article exposed two gaps in my first implementation. The portrait <source> elements did not declare their own dimensions, so the browser could initially reserve the landscape ratio. The build also generated small WebP variants for the art-directed images without referencing them in the final HTML. I corrected both: every portrait source now carries its real width and height, and each WebP source receives its own width candidates without losing its media query or fallback.
Explicit dimensions let the browser reserve space before an image loads, which helps prevent layout movement. The web.dev guidance on layout shift covers the same requirement for sources with different aspect ratios. Google also recommends retaining the <img src> fallback when using responsive image markup because not every crawler or browser processes the advanced attributes in the same way (Google Image SEO guidance).
The tests passed. The cards still touched.
The image tests can verify file count, format, dimensions, and whether every referenced asset exists. They cannot decide that a composition looks balanced.
The previous article made that limit obvious. A long “Image Editing” card was 250 pixels wide inside columns separated by 245 pixels. The generated PNG was valid and every test passed, but the card overlapped its neighbor by five pixels. “Screen Recording” also crowded the consolidation arrow. Visual review caught both. Reducing the long-card width to 225 pixels created a 20-pixel column gap and cleared the arrow; regenerating the family applied the correction consistently.
The same review caught a more serious factual error earlier: one image said the generated site fell to 10 pages when the verified count was 9. A flawless export would only have reproduced the wrong number more reliably.
What stays automated
I will keep automating the parts with objective contracts: dimensions, encodings, width variants, file references, metadata, and the social crop. I will keep inspecting the parts that depend on meaning: facts, hierarchy, spacing, legibility, and whether the image earns its place in the article.
That is a smaller promise than complete automation, and a more useful one. Code makes a correction cheap to propagate. It does not decide that the correction is good.