The Real Lesson From a GitHub Stats Widget: Your Storefront Is an Image URL
Cross-border sellers spend most of their tooling budget on dashboards nobody outside the company ever sees. Meanwhile the assets that actually convert — product images, review widgets, trust badges, share cards — are treated as static files dumped into a CDN bucket and forgotten. That asymmetry is why I read Velocity Radar, a small developer-momentum tool that launched on Product Hunt, with more interest than its niche deserves. It is not an e-commerce product. But its core architectural bet — that a personalised, server-rendered image URL is a distribution channel — is the single most under-exploited pattern in cross-border commerce right now, and the launch thread contains a caching post-mortem that every operator running dynamic creative should read.
What the thing actually is
Velocity Radar was built by Paul Save, who describes himself as working on the iD8 ecosystem and orchestrating multi-agent workflows. The product measures what he calls “true developer momentum” rather than raw activity: it compares a developer’s newest stretch of 30 active days against their earlier baseline, and it categorises commits into substantive, automated, and merges so that AI agent activity doesn’t inflate the numbers. The output is a graph, a badge, and a 1200×630 share card, all served from velocity.id8.one. A developer pastes one line into their GitHub README and every profile visit fetches a personalised PNG.
The stack detail matters more than the product. Save runs Vercel Functions behind Vercel’s CDN, with routing rules in vercel.json. Each request renders an SVG from the user’s counted data and converts it to PNG. The CDN caches each image for a day and serves the stale copy while a new one renders, so a README never shows a broken image during the nightly count refresh. No sign-up, no install, no app. As Save puts it, “because a graph is just a cached image URL, Velocity Radar needs no sign-up, no install and no app. That frictionless start is the growth.”
Hold that sentence. It is a growth thesis, not an engineering note.
The Problem It Solves Is Really a Distribution Problem
Strip away the GitHub context and Velocity Radar is solving a problem every DTC brand has: how do you get a personalised, always-fresh visual asset in front of an audience you don’t own, without asking that audience to install anything or log in anywhere?
The conventional answers are all worse. You can build a dashboard, but dashboards require a login, and logins kill virality. You can generate static images on a schedule, but then they go stale. You can render client-side with JavaScript, but most platforms that embed third-party content — GitHub READMEs, email clients, marketplace listing pages, affiliate networks — strip or block scripts. What survives everywhere is an <img> tag pointing at a URL you control.
That constraint is not unique to GitHub. It is the defining constraint of cross-border commerce distribution in 2025:
- Amazon listing images and A+ content modules are served from Amazon’s own CDN, and you cannot inject scripts into them.
- Etsy shop banners and listing photos are static uploads.
- TikTok Shop product cards and Temu listing visuals are platform-rendered from your submitted assets.
- Email — still the highest-ROI channel for most DTC brands — blocks JavaScript in every major client, including Klaviyo sends.
- Affiliate and influencer networks typically allow only image pixels and tracking URLs, not script tags.
In every one of those surfaces, the only dynamic element you can reliably control is the URL of an image. Which means the image URL is your API. Velocity Radar is a clean proof that this works at scale, at near-zero marginal cost, with no server fleet.
Why Amazon sellers should care more than Shopify ones
A Shopify merchant owns their storefront and can run arbitrary JavaScript, install apps, and A/B test with Google Optimize successors or Convert without asking permission. An Amazon seller cannot. Amazon Seller Central gives you image slots, a title, bullets, A+ modules, and a Brand Story — all static, all reviewed, all cached by Amazon’s own infrastructure. The only lever you have that behaves like a live API is the image URL you upload, and even then Amazon re-hosts it.
But there’s a second-order version of this that almost nobody exploits: the images you control outside the marketplace. Your Shopify storefront that exists purely to capture branded search traffic. Your email flows. Your affiliate creatives. Your influencer brief kits. Your Linktree or bio link. Your review-request follow-ups. All of those accept image URLs, and all of them can be made to render a different image for every recipient, every day, without anyone installing anything.
A cross-border seller running the same SKU across Amazon US, Amazon DE, TikTok Shop UK, and a Shopify DTC store currently ships four sets of static assets and updates them by hand. The Velocity Radar pattern says you could ship one image endpoint that renders locale-appropriate pricing, stock status, shipping ETA, and a personalised discount code — and update it from one place.
What Cross-Border Sellers Can Actually Borrow
Three transferable ideas, in order of how quickly you could ship them.
1. Treat dynamic creative as infrastructure, not a design task
Most brands think of creative as something a designer produces and an operator uploads. Velocity Radar treats it as something a function produces and a CDN caches. That shift is the whole game. Once your hero image is a URL that hits your own endpoint, you can change what every viewer sees without touching a single platform’s admin panel.
Concretely: a /img/hero/{sku}/{locale}.png endpoint that reads from your PIM, renders price in local currency, overlays a shipping promise based on the viewer’s country (derived from request headers), and stamps a personalised promo code. Cache it for an hour. Serve stale while revalidating. That is a weekend project for one backend engineer and it replaces a monthly design cycle.
2. The cache-control conversation is the real product decision
The most instructive part of the launch thread is a correction from Konstantin Tikhaev, who flagged that the image endpoint needed explicit Cache-Control headers with max-age=0 and no-cache, because GitHub routes all profile README images through its Camo proxy at camo.githubusercontent.com. If the server doesn’t tell Camo not to cache, GitHub keeps the image on edge for days and any refresh schedule breaks silently.
Save’s response is the part worth studying: the endpoint had been setting s-maxage for Vercel’s edge cache but nothing for downstream, so Camo picked its own freshness. He fixed it by sending max-age=3600, reasoning that max-age=0, no-cache would force Camo to re-fetch on every README view for data that changes once a day. He also clarified that the “ten minutes” in the guide refers to how often the service checks a username after you paste the snippet, not the graph render cadence — the graph itself refreshes nightly.
That is a textbook example of a decision every cross-border operator will eventually face the moment they serve dynamic images to a marketplace, an email client, or a social platform. The intermediary’s cache is not your cache. If you don’t specify downstream freshness, the intermediary will choose for you, and it will choose wrong. Amazon’s image CDN, TikTok’s CDN, Klaviyo’s image proxy, and every email client’s image proxy behave the same way. The operator who understands Cache-Control beats the operator who doesn’t, every time.
3. Frictionless start is the growth loop
Save’s framing — “that frictionless start is the growth” — is worth stealing verbatim as a product principle. Every step you remove between a potential customer and their first impression of your brand compounds. No sign-up, no install, no app. For cross-border sellers, the equivalent is: no forced account creation to see pricing, no login wall on the returns portal, no app download to track a shipment, no form fill to get a size guide.
This is where most DTC brands still lose to marketplaces. Amazon wins a huge share of cross-border volume not because its prices are better but because the path from search to purchase has fewer steps. If your DTC storefront adds a cookie banner, a pop-up, a currency selector, and an account prompt before the customer sees a price, you have already lost the comparison.
Where the Analogy Breaks — and Where My Judgment Says It Falls Short
I want to be honest about the limits, because the temptation to over-extend a developer-tool pattern into e-commerce is strong and mostly wrong.
First, the audience is different. A GitHub README image is viewed by developers who understand what a dynamic image is and don’t find it creepy. A product image on an Etsy listing or a TikTok Shop card is viewed by a shopper who expects it to be static. Serving a different price or a different shipping promise to different viewers on a marketplace listing is not just technically hard — it’s a compliance problem. Amazon’s product detail page rules and most marketplace terms prohibit showing different prices to different buyers based on anything other than a publicly available promotion. Dynamic creative is safe in email, on your own storefront, and in affiliate kits. It is a landmine on marketplace listings.
Second, the cost model is different. Velocity Radar’s economics work because each image is small, cached for a day, and viewed a handful of times per profile. A DTC hero image may be viewed millions of times per month across dozens of locales. Vercel’s function pricing is fine for a stats widget; it is not obviously fine for a high-traffic storefront unless you’re caching aggressively at the edge. Run the math before you commit.
Third, the product itself has a narrow audience. Velocity Radar solves a real problem for developers who care about commit quality and AI-agent skew. It does not solve anything for a cross-border seller directly. I’m citing it as an architectural pattern, not recommending you install it. If you sell on Amazon and have never touched a Cache-Control header, the honest takeaway is: hire someone who has, or learn it yourself this quarter.
Fourth, the launch thread itself is thin. There is one substantive technical exchange and a handful of upvotes. I would not read this as a validated category. I’d read it as a well-executed small tool whose architecture happens to be instructive.
What I’d Watch / Test Next
Three concrete things to do this week, in order of leverage.
One: audit your image URLs. Open your Shopify theme, your Klaviyo templates, your Amazon A+ modules, and your TikTok Shop product cards. For each image, ask: is this a static file I uploaded, or a URL that hits an endpoint I control? Most operators will find that 100% of their images are static. That’s the gap.
Two: build one dynamic image endpoint. Pick the highest-value surface — I’d start with the post-purchase email flow, because it’s high-open, low-risk, and doesn’t touch marketplace compliance. Render a personalised shipping ETA, a locale-appropriate currency, and a one-time discount code. Cache it for an hour. Ship it. Measure click-through against your current static image.
Three: read the Vercel Functions docs and the MDN Cache-Control reference end to end. Not because you’ll necessarily use Vercel, but because the mental model — edge functions plus explicit downstream cache directives — is the same one you’ll need whether you’re on Cloudflare Workers, AWS Lambda@Edge, or a homegrown CDN. The operators who understand this layer in 2026 will have a structural cost and speed advantage over the ones who don’t.
And if you want to see the pattern in the wild before you build, generate a Velocity Radar card for your own GitHub profile. It costs nothing, requires no sign-up, and takes about thirty seconds. That frictionlessness is the lesson.
