Beyond Vercel and Netlify: finding smarter frontend hosting alternatives

Not so long ago, deploying a website was a messy business. You rented a VPS, installed Nginx, configured SSL certificates, worried about ports and permissions, and hoped you didn’t bring the server down while deploying a new version. Then came Netlify and Vercel. Suddenly, you could connect your GitHub repo, push your code, and your website went live. For frontend developers, that was magic.

The idea was simple but powerful: abstract away the infrastructure and let developers focus on code. Vercel and Netlify didn’t only host static files; they offered continuous deployment, automatic previews, global CDNs, and even serverless functions. They became the default answer for “where should I host my frontend?”

But like many revolutions, the next stage came with trade-offs. What made these platforms so convenient also made them rigid. And as teams and projects grew, some of those trade-offs started to hurt.

What Vercel and Netlify solved

Both platforms solved a massive pain in frontend workflows. Before them, deployment was an afterthought, often handled by the one backend engineer who understood the server. Suddenly, every frontend developer could deploy confidently. With every git push, your code built, deployed, and served globally in seconds. You didn’t have to think about CDNs, SSL, or caching.

They also made collaboration easier. Preview URLs for pull requests changed how teams reviewed code. Serverless functions made it possible to run backend logic without managing a separate API. And because they were built around Git workflows, developers didn’t have to learn new tools.

For small teams, side projects, or startups, it was perfect. Fast, clean, modern.

The cracks start to show

The problems show up when you scale. Not necessarily in traffic, but in the complexity of your team or stack.

The first issue is vendor lock-in. These platforms rely on proprietary configurations and deploy systems. Once you use Vercel’s edge functions or Netlify’s forms, you’re not deploying just code: you’re deploying their flavor of it. Moving away later can mean rewriting features or reconfiguring your whole CI/CD.

The second problem is limited stack support. They excel at Next.js, Gatsby, or static SvelteKit sites, but if your project has a backend, custom API, or database integration, the simplicity breaks. Many teams end up deploying parts of their app elsewhere anyway.

Then there’s pricing. It starts cheap, but as soon as your team grows, you pay per seat, per build minute, per function invocation. That model punishes collaboration.
Agencies, in particular, hit this wall fast: suddenly, every developer costs extra, even if they’re only working on one project for a client.

And perhaps the biggest frustration is lack of control. You can’t decide how your CDN behaves, which region functions run in, or how scaling rules apply. The simplicity that made it great for individuals makes it limiting for teams that need flexibility.

Why we looked for alternatives

At We Do Dev Work, we run an agency environment. Multiple developers, multiple projects, different frameworks, different clients. We need a setup that can grow with us and adapt to how we work, not the other way around.

We don’t want to pay per seat. We don’t want to be told which stack we can use. And we need a system that’s consistent across projects: so when one developer finishes a project, another can take over without a steep learning curve.

That’s why we started looking beyond Vercel and Netlify. We wanted something that integrates cleanly with our ecosystem: TypeScript, .NET, PostgreSQL, SvelteKit, and Supabase. Something that gives us control over infrastructure, costs, and access.

That led us to AWS Amplify.

Why we like AWS Amplify

Amplify is not as flashy as Vercel. It doesn’t market itself with fancy animations or magic words like “instant deploy.” But under the hood, it offers the right balance between convenience and control.

It supports modern frameworks like React, Vue, and SvelteKit without forcing a specific one. You connect your repo, and it builds on every push. Same as the others. But because it’s part of AWS, it integrates naturally with the rest of the ecosystem. Need a database? You can spin up RDS or connect Supabase. Need to host images? Use S3. Need edge caching? CloudFront is there.

We like that everything is transparent. You can see what you pay for, region by region. You’re not billed for team members. You don’t have hidden function costs or build-minute limits. If a project grows, we scale it the same way we scale our backend.

Another big plus: consistency. Every project we deploy follows the same Amplify setup. It means our developers can jump between client projects without needing to learn new pipelines or proprietary workflows. It also keeps all environments under our control. No need to depend on a vendor that might change its pricing or features tomorrow.

Alternatives worth exploring

Amplify works well for us, but it’s not the only path. Depending on your project size and focus, there are other great options:

• Cloudflare Pages is excellent for static and JAMStack sites. Fast global delivery, built-in edge functions, and straightforward Git integration. It’s also one of the most affordable options for simple frontends.
• Render is an interesting balance between simplicity and full-stack flexibility. It supports web services, cron jobs, PostgreSQL, and background workers. All with a relatively easy dashboard.
• Fly.io focuses on performance and proximity. You can run Dockerized apps close to your users, ideal for projects where latency matters.
• DigitalOcean App Platform feels like a friendlier version of AWS. It supports most frameworks, offers managed databases, and is great for small businesses. But for some reason DigitalOcean isn’t the favorite option for many.
• Google Cloud Run provides serious scalability, though it’s more technical. It can host anything containerized, but it requires more configuration and DevOps knowledge.

Each of these tools has its own trade-offs. The key is matching the tool to the team.

When serverless isn’t the answer

Serverless hosting sounds like the future - and it often is - but not for everything. We’ve seen projects where serverless ends up more expensive and complex than a classic VPS setup.

The issues usually come down to scale and consistency. For long-running tasks or heavy traffic, serverless costs can skyrocket. Cold starts can hurt user experience, and debugging across multiple lambda invocations can be painful. And because each function runs in isolation, caching and state management are harder.

A classic container-based setup can be cheaper, easier to debug, and still scalable. With the right DevOps setup: CI/CD pipelines, autoscaling, and load balancing, you get predictable costs and performance. It’s not “modern” in the buzzword sense, but it’s still how a lot of large-scale applications run successfully.

In other words, the right architecture is the one that fits the problem, not the trend.

Our approach at We Do Dev Work

For us, flexibility wins. We use Amplify when we need quick frontend deployments, integrated with Supabase for data and authentication. When we need more control, we go for classic container deployments on AWS ECS or even managed VPS setups.

Our goal is always the same: fast, reliable, and maintainable hosting with transparent costs. It’s not about chasing the newest tool. It’s about picking the right tool for the job.

And owning the full process from code to production.

We still admire what Vercel and Netlify brought to the ecosystem. They made modern frontend development accessible and enjoyable. But convenience has its limits. For an agency that handles multiple stacks, teams, and clients, owning the pipeline matters more than one-click deploys.

Final thoughts

Frontend deployment has come a long way: from manual FTP uploads to serverless CDNs with previews and functions. But the story isn’t finished. We’re entering a phase where teams want the same convenience and control. Where costs need to be predictable, environments reproducible, and tools open.

For us at We Do Dev Work, AWS Amplify hits that balance. It’s reliable, flexible, and fits naturally within our stack. But the real takeaway is this: don’t let hosting define your architecture.

Pick a platform that serves your workflow, not the other way around.
That’s how you build scalable systems - and a sustainable agency.