Why I use Vercel

# Why I use Vercel

**Slug:** why-i-use-vercel
**Category:** Tools

---

I use Vercel because I never want to think about deployment.

That's it. That's the reason. Everything else I'm going to tell you in this post is just evidence for that one sentence.

---

## What deployment actually means

Before I figured out this stack, "deployment" was the step I dreaded. You'd finish building something, then spend an unpredictable amount of time trying to get it running somewhere that wasn't your laptop. Servers to configure, environment variables to manage, SSL certificates, DNS — all the plumbing that has nothing to do with what you're building but has to work before anyone can use it.

Vercel removes all of that. Connect your GitHub repo, add your environment variables, click deploy. Your app is live. From that point forward, every time you push to main, it deploys automatically. Every time you push to any other branch, Vercel creates a preview URL — a live version of that branch that you can share, test on a real device, or send to someone else for review.

That's the entire deployment workflow. Push code, things happen automatically.

---

## The preview URL is the thing I underestimated most

When I first heard about preview deployments I thought it was a nice-to-have. Now I think it's one of the most useful features in my entire stack.

Every branch you create gets its own live URL. The branch is connected to your real Supabase database. You can test the actual app, not a local simulation of it. You can send the URL to a co-founder, a beta user, or a client — they can click around on the feature you just built without you doing anything beyond pushing code.

For BeautySlot — the marketplace I'm building — this changed how I work with my co-founder Danielle. Before, showing her something meant either screen sharing or waiting until I merged to main. Now I push a branch and send her a URL. She sees it on her phone, leaves feedback, I make changes, push again, new URL. The iteration loop got much faster.

---

## The CI connection is the safety layer

I don't let AI agents deploy to production directly. That's a principle I apply to every tool in my stack — Codex, Claude Code, all of them. The agent writes code and commits to a branch. I review the branch. I merge when it looks right. Vercel deploys when it hits main.

That sequence matters. It means nothing touches production without going through git history, without me seeing the diff, without the review step. The agent has no path around that. And because Vercel is connected to GitHub, the deployment happens automatically on merge — I don't have to remember to trigger it, but it also can't happen without the merge.

GitHub Actions handles the Supabase side — migrations and edge functions deploy on merge to main through CI, not through the agent. Same principle: the pipeline is the safety layer.

For someone building without a traditional development background, this architecture matters more than it might for an experienced developer. I can't catch everything in a code review. Having the deployment happen through a process rather than through direct access means the process itself is a check.

---

## Free until it isn't

Vercel's hobby plan is free for personal projects and small apps. Vercel hosting, preview deployments, automatic deploys, custom domains — all free. For the early stage of both Hale CRM and BeautySlot, I've paid nothing for hosting.

There's an honest caveat: Vercel costs can grow at scale, and some indie developers have been caught out by unexpected bills from bot traffic. If your app gets significant traffic, model the costs before you're surprised by them.

For the stage I'm at — building, testing, iterating — the free tier is entirely sufficient and the workflow benefits are real regardless of what tier you're on.

---

## What I don't use it for

Vercel is a frontend platform. The backend — database, auth, edge functions — lives in Supabase. Vercel handles the React app. Supabase handles the data. Each one does its job and they connect through environment variables.

Some people try to run everything through Vercel's serverless functions. That works, but for my stack Supabase is the right place for backend logic. Keeping the separation clean means each tool is doing what it's best at.

---

## The honest summary

I didn't choose Vercel because I did a thorough evaluation of hosting platforms. I chose it because it was what the Lovable export connected to, and it turned out to be exactly right for how I build.

Zero configuration to get live. Automatic deploys on merge. Preview URLs per branch. Free at the scale I'm at. And it slots into the AI coding workflow cleanly — the agent commits, CI runs, Vercel deploys. No extra steps.

For building real products without a traditional development background, deployment should be the least interesting part of your day. Vercel makes that possible.

---

*Part of my full stack: Lovable (UI) + Claude Code + Codex (development) + Supabase (backend) + Vercel (deployment).*