Y
our dev team says you need to "move off Heroku and onto AWS." You nod. The meeting moves on. You have no idea what that means, whether it's the right call, or how much it's going to cost. This post is for that moment. By the end, you'll know what a server actually is, the difference between the three main ways to run one, and what questions to ask before your team makes an infrastructure decision that will follow your product for years.What a server actually is
A server is a computer. That's the whole secret.
It's a computer that runs your code and responds to requests from users — and the reason it sounds mysterious is that it's usually someone else's computer, sitting in a data center, and you're renting access to it.
When someone opens your app, their phone sends a request across the internet to that computer. The computer runs your code, does something useful, and sends a response back. That's the entire chain.
Where it gets complicated is that there are three very different ways to rent that computer, each with different tradeoffs on cost, control, and complexity.
Three ways to run your product
The VPS (Virtual Private Server)
You rent a slice of a physical machine. Fixed specs — say, 2 CPU cores, 4GB RAM, 80GB disk. You get full access to it. You install your own software, configure the networking, handle updates. Providers like DigitalOcean and Hetzner sell these. The pricing is flat and predictable. The catch: when something goes wrong at 2am, it's your problem to fix.
Managed cloud platforms
This is what people mean when they say , Google Cloud, or Azure. You're still renting computers, but the provider manages far more of the underlying infrastructure. You pick services from a menu — virtual machines, managed databases, file storage. These platforms scale on demand, which sounds great until you see the bill. Pricing is usage-based and can surprise you if nobody's watching it.
Serverless
You don't rent a server at all. You upload a function, and the provider runs it only when someone calls it. You pay per execution, not per hour. Vercel is mostly built on this model. AWS Lambda is this. It's excellent for unpredictable traffic because you're not paying for idle time. It hits a wall — in cost and flexibility — at scale.
None of these is inherently better. They're different tools with different price curves and different operational burdens.
What "moving to AWS" actually means
When your team says this, they mean: let's stop using a managed platform like Heroku or Vercel and run our own infrastructure on AWS instead.
Heroku and Vercel are platforms. They handle deployments, server management, and a lot of the operational work that would otherwise fall on your engineering team. AWS is not a platform — it's a collection of infrastructure services. Moving to it means taking on all the work those platforms were doing behind the scenes.
That's not always the wrong call. Vercel's pricing at scale becomes a real problem for some products. Sometimes you need infrastructure control that a platform can't give you. But it's not simpler. It's significantly more complex, and it requires someone on your team who actually knows how to operate it — or it falls apart quietly.
The thing founders underestimate: "moving to AWS" is a meaningful engineering project. It takes weeks. It changes what your team is responsible for. And it should be a deliberate decision, not something that happens because it sounds more serious.
The part most founders get wrong
Serverless pricing looks cheap until it isn't.
Vercel, Netlify, AWS Lambda — they all charge per execution. At low traffic, this is genuinely affordable. At high traffic, you're paying for every request, every function invocation, every cold start.
A startup I've seen go through this was paying around $200/month on Vercel at 50,000 monthly active users. Reasonable. At 500,000 users, the same product on the same code was billing $4,000/month. Not because anything broke — because the pricing model doesn't scale linearly.
A comparable workload on a managed VPS at Hetzner or DigitalOcean: $60–100/month. Fixed. You own the maintenance overhead, but the economics flip hard at volume.
This isn't an argument against serverless. It's an argument for understanding what you're buying before you depend on it.
How Traveloka thought about this
Traveloka handles some of the most volatile traffic in Indonesia — Lebaran and Harbolnas, when flight and hotel searches spike by orders of magnitude in hours. They weren't doing anything exotic to handle it.
Load balancers distribute incoming traffic across multiple servers. Auto-scaling groups spin up additional servers during peaks and wind them back down after. Caching layers prevent every request from hitting the database cold.
[→ Read: What Is Software Architecture? A Plain-Language Guide for Founders]None of that required serverless. It required engineers who understood how to configure the infrastructure they had.
The infrastructure model matters far less than whether your team can operate it competently. A well-run VPS beats a poorly-managed serverless setup every time. The question isn't what the platform is — it's whether anyone on your team is responsible for keeping it healthy.
FAQ
Q: Is AWS better than Heroku?
A: Better for what? Heroku is simpler to operate. AWS gives you more control. Heroku costs more per unit of compute once you're past the hobby tiers. AWS requires more expertise to run without incident. Most early-stage startups should stay on Heroku or Vercel until cost or a specific limitation becomes a real, documented problem — not a hypothetical one.
Q: What does "the cloud" actually mean?
A: Someone else's computers, rented on demand, billed by usage. AWS, Google Cloud, and Azure are the three dominant providers. When your team says "we're on the cloud," they mean they're using one of these instead of running physical servers in a rack somewhere. It's a billing model and a delivery model, not a technology.
Q: When should we move off Vercel?
A: When the bill becomes disproportionate to the value, or when you hit a hard limit — specific server-side requirements, database connection ceilings, cold start latency that's affecting user experience. For most products at Seed and Series A, Vercel is a reasonable choice. Don't migrate for the sake of sounding more serious.
Q: What's the difference between a server and a database?
A: A server runs your application code. A database stores your data. They're separate systems that work together. Your server receives a request, queries the database, gets or writes information, and returns a response. In development they often run on the same machine. In production, they almost always run separately.
Q: Do I need to understand all this to build a product?
A: Not to ship an MVP, no. You need to understand it when infrastructure decisions start costing real money or affecting users. A founder who can ask "are we paying per request or per server?" in a planning meeting will catch expensive architecture mistakes before they compound.
Infrastructure decisions made at 1,000 users have a way of still being in place at 1,000,000. That's not an argument for over-engineering early — it's a reason to pick something you can understand, operate, and migrate off deliberately when the time comes. If you're not sure whether your current setup fits where you're heading, that's exactly what a technical architecture review should tell you.
Internal Reference Logs: