A prospect called us in February asking how soon we could move his site to "the edge." His current host was a $14/month shared box that served his five-page plumbing business out of Atlanta. He'd read a blog post. He was worried he was falling behind. We talked him out of it in about twenty minutes and saved him a four-figure migration he didn't need.
This conversation happens a lot. Cloudflare Workers and Vercel Edge are pitched as the default, and for the kind of site we mostly build, they are not.
What edge actually is
Putting your application code on hundreds of points of presence around the world, so that when a user in Tokyo hits your site, the response is generated in Tokyo instead of round-tripping to Virginia. For a global SaaS product where every 100 milliseconds shows up in conversion numbers, that's real. For a roofing company whose customers all live within forty miles of Marietta, the Tokyo PoP is doing nothing.
The actual latency win on a US-only small business site, comparing a properly configured origin in us-east with edge-deployed workers, is typically under 80 milliseconds. The user does not notice. The Lighthouse score does not move. The conversion rate does not move. You have spent engineering time on a number that does not exist.
Why this got marketed as a default
Vercel and Cloudflare both sell edge compute as a product. The product is real and the marketing is good. The unstated assumption is that you have global users, that your origin is slow, and that your application is shaped in a way that benefits from running closer to the visitor. Three things, all of which need to be true. If one isn't, you've added complexity for a benchmark you don't appear on.
And the complexity is not free. Edge runtimes are not full Node. You cannot just npm install whatever you want. Cold starts behave differently. Database connections, in particular, get awkward — most traditional databases hate being talked to from 300 different locations simultaneously, which is why Cloudflare invented D1 and Vercel partners with Neon. Now you're not just on edge, you're on a specific edge-shaped database too.
Where it actually pays off
A/B testing flags. You want the experiment assignment to happen before the page renders, without a flash of the wrong variant, and without leaking the assignment logic to the client. A Worker that reads a cookie and rewrites the HTML response is the cleanest implementation we've found. One of our e-commerce clients runs three concurrent tests this way and the variant flicker that drove their old vendor crazy just disappeared.
Geo-routing. If you have a regional offer — a Texas-only promotion, a Canadian price list — doing the geo-lookup at the edge means the user gets the right page on the first request, with no client-side redirect, no double-render, and no SEO confusion about which page is canonical. We do this for a multi-region franchise client and it works exactly as advertised.
Auth at the edge for paywalls. When a returning subscriber hits a gated article, the edge worker checks the JWT, decides whether to serve the cached full article or the truncated public version, and does it without a round trip to the origin. The cache hit rate jumps. The origin server stops sweating. This is the use case where edge actually earns its complexity, and it's the one we'll keep recommending without hesitation.
Image transformation, sometimes. Cloudflare's image resizing service is good and cheap. If your client uploads 4000-pixel-wide photos to their CMS and you don't want to run a separate image pipeline, putting the resize at the edge is fine. This is closer to "use the CDN's feature" than "build on edge compute," but it counts.
What our portfolio actually looks like
We currently maintain fourteen client sites. Three of them use Cloudflare Workers for something real: the franchise geo-router, the paywall auth check, and one e-commerce site running A/B experiments. The other eleven sit on conventional origin hosting — a mix of DigitalOcean droplets, a couple of Hetzner boxes, and one stubbornly happy Linode. They all sit behind a CDN for static assets. None of them need edge compute, and adding it would not make them measurably better.
The CDN piece matters, by the way. We're not anti-edge in any general sense. Caching static assets at the edge is just how the web has worked for fifteen years. The thing we're skeptical of is putting application logic there as a default, when most small business applications have one obvious place to live and one obvious database to talk to.
The honest test
Before adding edge to a project, we ask three questions. Do you have users outside the continental US who matter to your revenue? Is your origin response time over 400 milliseconds in the 75th percentile? Is there a specific behavior — A/B, geo, auth — that benefits from running closer to the user? If the answer to all three is no, the edge will not save you. It will just give you a more complicated stack to maintain.
The plumber didn't need the edge. He needed a faster image on his hero section.