Why I Eventually Moved My Projects to Vercel

 


I didn’t start with Vercel. Like most developers, I went through a phase of trying different hosting platforms just to figure out what actually works for me.


I used GoDaddy for a while. It did the job. My projects were online, things were stable, and I didn’t have to think too much about it. But I was paying around ₱300 every month. It’s not expensive, but at some point I started thinking, “Why am I paying for this when some of my projects are just experiments?” That was enough reason for me to cancel the subscription.


After that, I moved to AWS because I wanted to learn more about cloud infrastructure. The free tier sounded perfect. More control, more flexibility, and no cost, at least that’s what I expected. But in reality, I hit the limits in about three months. Maybe it was my usage or something I misconfigured, but either way it made one thing clear. You really need to understand what you’re doing on AWS or you’ll go beyond the free tier without realizing it. It’s powerful, but for simple deployments, it felt like too much.

I didn’t switch everything to Vercel immediately. At first, I just used it for small projects and testing. But the more I used it, the more I noticed how much easier everything became. I could push code and it would deploy automatically. No setup, no maintenance, no surprises. That convenience started to matter more than I expected.


Eventually, I stopped experimenting with other platforms and just leaned into Vercel. I don’t have to pay monthly just to keep projects alive. It works naturally with Git, deployments are fast, and I don’t have to think about servers anymore. It just fits how I work.


There is a limitation though. I can’t deploy my Laravel apps on Vercel. Since it’s built around serverless architecture, it doesn’t support traditional backend setups the way a VPS or EC2 instance would. So anything that depends on Laravel or long-running processes won’t really fit there.

That forced me to adjust how I build projects. Instead of relying on a full backend framework, I started leaning more toward serverless functions, APIs, and frontend-heavy applications. It’s a different approach, but it works for what I’m doing right now.


Trying different platforms wasn’t a waste. GoDaddy taught me the basics, AWS showed me how powerful cloud infrastructure can be, and Vercel showed me that deployment doesn’t have to be complicated.


Right now, everything I can move to Vercel is already there. And for future projects, I’ll probably start with Vercel first and only switch if I actually hit a limitation that matters.


For me, the biggest win wasn’t just saving money. It was removing friction. I spend less time thinking about deployment and more time actually building things.


- Juan

Comments

Post a Comment

Popular posts from this blog

Exploring Blogger Beyond Its Default Limits

Image
When I started exploring Google Blogger, my initial impression was simple: it works, but it feels limited. At work, some of our senior developers have been building a site builder that integrates with Blogger. Since I’m trying to keep up and understand how everything works behind the scenes, I decided to explore Blogger more deeply on my own. At first glance, the platform feels a bit outdated. The default layouts are basic, and the available themes don’t offer much flexibility in terms of design. If you’re used to modern frameworks like Vue or tools like Tailwind, the experience can feel restrictive. But instead of stopping there, I got curious. I started digging into Blogger’s theme system and found that it actually allows direct access to the HTML structure. It’s not your typical setup, though. The templates are written in a mix of HTML and XML, using special tags that Blogger understands. At first, it looks a bit unfamiliar, but once you get the idea, it becomes manageable. ...
Read more

Understanding Blogger’s Template System as a Developer

Image
After spending more time exploring Blogger, I started to look beyond the surface and dig into how its template system actually works. At first, it felt unfamiliar. Instead of the usual setup I’m used to with frameworks like Vue or Nuxt, Blogger uses a mix of HTML and XML with its own set of custom tags. Seeing things like <b:section> , <b:widget> , and <b:includable> for the first time was a bit confusing. But once I stepped back and tried to understand the structure, it started to make more sense. The way Blogger templates are built is actually quite similar to component-based thinking. A <b:widget> acts like a container or module, and inside it, <b:includable> blocks define reusable pieces of layout. These blocks can then be rendered using <b:include> , which feels very similar to calling a component or including a partial in other systems. One of the key parts is how data is handled. Instead of using variables like we no...
Read more

What I’m Building Right Now (And Why I Started This Blog)

Hello everyone, I’ve been working on different web development projects lately, and I realized something—I don’t have a place to document everything I’m learning and building. So I decided to start this blog. Right now, I’m focused on building real-world applications using modern technologies like Vue, Nuxt 3, and AI tools. I’ve also been exploring things like Web3 integrations, virtual assistants, and custom systems that solve actual problems. Some of the things I’m currently working on include: A virtual assistant system powered by AI Web applications using Nuxt 3 and Tailwind CSS Experiments with APIs, real-time systems, and automation Exploring integrations like wallets and token-based systems I also recently worked with platforms like Wix, which gave me a different perspective on how websites are built and managed compared to custom development. This blog will be a place where I share: What I’m building Problems I encounter (and how I solve them) Lessons...
Read more