AWS, Vercel, and Amdahl's Law
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:
- AWS is feature-rich; Vercel has a smaller set of very well-functioning features.
- AWS gives you fine-grained control over all sorts of things, especially permissions; Vercel gives you strong performance over a smaller set of possible configurations.
- If you govern your builds with CDK1 in a reasonable way, your AWS-based builds will take a reasonable amount of time. Vercel builds tend to be much faster.
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.2 For present purposes, it's less important that I'm right and more important that I take the situation to be:
- AWS-with-CDK is a reasonable default I've been using for a long time;
- It's been my default because you can do approximately anything from the command line in reasonable ways, at reasonable costs, at reasonable speed with excellent uptime, through a CLI.3
- But Vercel does a core set of things well and much faster.
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: 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:
- You can view the higher opportunity cost of coffee breaks as another Amdahl's Law effect: if you view breaks as a recharge period in the functioning of a programmer, optimizing those breaks now has much greater maximum payoff.4
- AI is also relevant here in that it makes the actual migration a lot faster (as I've written about at length).
- Some readers might say that it's a mistake to view AI-assisted engineering as a sped-up version of the trad-engineering, do-stuff-and-deploy-it paradigm. They might be right, and I'm plenty curious about those other paradigms (anyone out there using Gas Town?). As much as my programming life has changed, however, it's still structurally analogous to trad-programming enough that the Amdahl's Law analysis is relevant.
- One peripheral, but to me very interesting, subject that I've changed my opinion on in a way that's relevant to this decision is queueing. This Matthew Hawthorne article got me asking questions about when and how I use queues, and my answer wound up being, roughly, "way too much."5 So, leaving SQS behind is much less costly to me than it used to be. To be clear, this isn't an Amdahl's Law point but a change of perspective on a basic engineering subject.
...and even if you don't, if you're like almost any AWS user I've ever seen.↩
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.↩
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.↩
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.↩
Not exactly for Hawthorne's reasons, but that's another post.↩