# AWS, Vercel, and Amdahl's Law

> Source: <https://www.natemeyvis.com/aws-vercel-and-amdahls-law/>
> Published: 2026-09-09 20:24:00+00:00

Many applications can be built and deployed with either a Vercel-based stack or an AWS-based one. Here's a rough view of some tradeoffs:

This is nowhere close to a complete comparison of AWS and Vercel, and I'm sure many people would argue with some of those claims. It's even a bit of a category mistake to frame a comparison as "AWS vs. Vercel:" they do different things, and you can call AWS from a Vercel-governed project perfectly well.<sup>[2](#fn-2)</sup> For present purposes, it's less important that I'm right and more important that I take the situation to be:

Rightly or wrongly, I have taken the AWS-Vercel decision to rest primarily on a tradeoff between better build-deploy speed and other benefits. The importance of build-deploy speed, however, has gone *way* up for me, because of [Amdahl's Law](https://en.wikipedia.org/wiki/Amdahl%27s_law): generative AI has made everything *else* I do so much faster that the speeding up the build-deploy part of the development loop has much greater (maximum) benefit.

This is, I think, a nice example of how generative AI, in completely restructuring the development loop, affects programmers' lives in both direct and indirect ways. I haven't much changed my opinion of either tool, but I'm now much more eager to be using Vercel. Some further notes:

...and even if you don't, if you're like almost any AWS user I've ever seen.[↩](#fnref-1)

I'm also using "Vercel" to mean something like "Vercel and the add-ons it makes very easy to use." So, in particular, I tend to think of Neon-as-used-through-Vercel as part of Vercel proper.[↩](#fnref-2)

Of the many, many caveats I'd like to discuss here, I only have time for a few. First, "good-enough" is how I think about the *build and deployment* performance; I think that the performance of S3, DDB, and certain other core AWS services as much, *much* better than good enough. Second, when I say that costs are reasonable, I mean reasonable from the perspective of the 2026 market; I am old enough that the cost of most AWS services seems comically low. Third, when I say you can do things through the CLI in reasonable ways, I don't mean that the APIs are a model of brilliant API design but rather that, in an AI-first world, you can consistently get the results you need with the CLI.[↩](#fnref-3)

This is separate from the main cost-of-coffee effect I discuss there, which has to do with the *structure* of work and the fact that it's so much easier to do make meaningful engineering progress in the, say, 10 minutes you'd spend at leisure.[↩](#fnref-4)

Not exactly for Hawthorne's reasons, but that's another post.[↩](#fnref-5)