The Problem
Image optimization looked solved until the usage bill arrived.
At Bob's Watches, performance mattered because SEO traffic depended on fast pages. Visual quality mattered just as much because luxury watches sell through trust, detail, and material fidelity. The existing approach created a forced tradeoff: compress images aggressively to protect Lighthouse scores, or preserve detail and accept heavier delivery costs.
That tradeoff became worse as traffic scaled. Bot traffic, AI crawlers, and scrapers could burn through transform or bandwidth quotas without creating customer value. The product experience might still look polished, but the business model underneath it was working against the user.
Why It Was Difficult
The hard part was not just resizing images. It was designing an image system that stayed predictable under messy real-world traffic.
The product had to preserve visual fidelity for high-value ecommerce photography, support SEO-sensitive page performance, and keep working during crawler spikes or DDoS-like traffic. It also had to avoid becoming another abstract enterprise image platform where teams only understand the cost after they are already locked in.
That meant the core design constraint was incentive alignment: charge for actual image processing work, not for every cached delivery event or every byte moved by someone else's edge network.
Key Product Decisions
- Meter compute, not traffic.
ArkCDN meters CPU time when it performs an image transform. Cached delivery should approach zero ArkCDN compute cost, which keeps the pricing model tied to real work instead of raw traffic volume. - Keep delivery at the edge.
ArkCDN sits behind the customer's existing CDN layer, such as Cloudflare or Fastly. The edge handles bandwidth and cache hits, while ArkCDN handles cache misses, refreshes, and image transformation. - Make degradation predictable.
When limits are reached, the system should throttle or reduce quality rather than create broken pages, surprise overages, or emergency sales conversations. - Treat visibility as part of the product.
Usage charts, cache hit rates, CPU consumption, bandwidth views, sources, domains, presets, and integration steps are not admin afterthoughts. They are the controls teams need to understand how image behavior maps to cost. - Keep configuration small and operational.
ArkCDN supports domains, sources, defaults, presets, and integration URLs without forcing customers into a complex hierarchy. The goal is enough control for production use without turning setup into a platform implementation project.
Decoupled Architecture. By sitting behind the edge (Cloudflare/Fastly), ArkCDN ensures you only pay for compute on cache misses, while the edge absorbs the bandwidth costs.
The Solution
ArkCDN is an image optimization layer that routes requests through the customer's existing edge CDN and only performs compute work when a transformed image needs to be generated or refreshed.
On a cache hit, the edge serves the asset and ArkCDN incurs no transform cost. On a cache miss, ArkCDN fetches the original image, runs the transform pipeline, returns the optimized image with cache-control headers, and records the CPU time used.
The product experience is organized around three surfaces:
- Operational visibility: dashboards show requests, bandwidth, CPU time, cache behavior, and usage trends so teams can see whether cost is coming from real customers, crawlers, or configuration choices.
- Configuration: domains, sources, defaults, presets, and integration URLs are separated into focused views so setup stays legible.
- Billing: plans are self-serve, usage limits are explicit, and overage behavior is framed around throttling instead of surprise charges.
The stack is intentionally practical. A Bun-based HTTP proxy runs the transform layer with Sharp. React handles the control plane. QuestDB records write-heavy telemetry. Stripe supports plan selection and billing.
Impact
The production version of ArkCDN's core logic has been running for over a year in a high-volume luxury ecommerce environment, helping deliver SEO-sensitive, image-heavy pages while avoiding the cost pattern that made traditional CDN pricing difficult to trust.
For this portfolio, ArkCDN is also running as live infrastructure. The high-resolution case study imagery on the site is processed and delivered through the same system, which means the case study is not only describing the product; it is being served by it.
Metric not available for public reporting. The strongest evidence available is the shipped production system, the visible product surface, and the architecture change: image processing cost is tied to transform work rather than crawler traffic or bandwidth spikes.
Even with the occasional DDoS, images didn't stop working
What I'd Improve
The biggest remaining friction is DNS setup. Even when the product model is simple, domain configuration can become the drop-off point for new users. The next priority is Domain Connect support so teams can provision domains with less manual setup.
I would also keep refining analytics from raw metrics into clearer trend context: not just what happened, but whether a spike came from customer traffic, cache misses, crawlers, preset changes, or degraded behavior.
ArkCDN proved the core product principle behind the work: good product design aligns incentives. When the business model fights the user, no amount of interface polish can save the experience.