Shipping app store art without a design team

Putting our own products on this site meant collecting logos, icons and screenshots and making them look deliberate next to each other. There is no design team here, so the work was mostly about handling real assets carefully. A few things caught us out.

Never trust the dimensions in the markup

Pulling screenshots for the Play listing, the page advertised each one at 526 by 296 — a landscape ratio. We resized to match and the results were subtly wrong: everything squashed, text slightly too wide.

The advertised size was a thumbnail crop. The actual files were 900 by 1600 portrait, which is what you would expect from a phone screenshot and exactly what the markup did not say.

The lesson is boring and worth internalising: read dimensions off the downloaded file, not from the page that linked to it. One line of code to check, and it would have saved a round of mangled assets.

Pick the format for the content, not out of habit

The screenshots came down as PNG at around 250 to 385 KB each. Three of those on one page is over a megabyte of images for what is essentially decoration.

PNG is the right default for interface work — sharp edges, flat colour, no artefacts. But these were full app screens: photographic gradients, blurred backgrounds, soft shadows. Exactly the content PNG is worst at.

Converting to JPEG at high quality took each one to under 60 KB. Same visual result at a glance, roughly a fifth of the weight.

The icons stayed PNG, because they need transparency and crisp edges at small sizes. Same page, different formats, chosen per asset rather than per project.

Resize down, never up

Every asset was fetched at the largest size available and scaled down to what the layout uses. An app icon offered at 512 becomes 224 for a 60-pixel slot, which still looks right on a high-density screen without shipping half a megabyte.

Scaling up is the trap. It never adds detail, it always adds weight, and it looks soft in a way that reads as careless rather than low-resolution.

Small vector marks want to be inlined

One brand mark was an SVG under a kilobyte. The build inlines assets below a size threshold as data URIs, so it ends up embedded in the markup rather than fetched separately.

That is the correct outcome and worth knowing about, because it means a tiny logo costs no round trip at all. It also means searching the built output for the filename finds nothing, which briefly looks like the asset went missing. It had not — it was sitting in the HTML.

Use what is already published

Every asset here came from somewhere it was already live: the store listing, the product's own site, its favicon. Nothing was redrawn.

That is not just less work. Reusing the published artwork is the only way the site matches what someone sees when they arrive at the actual product. A prettier logo that nobody recognises is a worse logo.

All of it is stored in the repository rather than linked from someone else's CDN, so the page cannot break because a third party reorganised their storage.