DEV Community: jy H uang

How to deploy a website at a low cost? How to choose between Vercel and Cloudflare?

jy H uang — Mon, 19 Oct 2026 02:49:05 +0000

Here is an idiomatic, developer-to-developer English translation that strips out the generic "AI tone" and keeps the practical, conversational style of an indie hacker:

It’s been just over a month since I officially kicked off my micro-SaaS tool project aimed at the global market.

Aside from building out features, I've spent a fair amount of time wrestling with infrastructure. For solo founders, keeping hosting costs as close to zero as possible, picking the right serverless provider, and avoiding surprise four-figure cloud bills are all things you want to think through before writing code.

Drawing from my own tech stack and real-world observations, here is a practical look at VPS vs. Serverless, why I lean toward Cloudflare over Vercel, and the best free-tier infrastructure available to bootstrapped devs today.

1. VPS vs. Serverless: Which One for Indie Projects?

When thinking about hosting, the classic developer playbook usually involves spinning up a VPS, installing a control panel (like aaPanel), setting up Nginx, configuring PM2 or systemd, and babysitting processes.

It’s a battle-tested and flexible approach. But for an early-stage side project, self-hosting eats into your most limited resource: time and mental bandwidth.

If your product is still in validation mode—low traffic, minimal background workloads—managed serverless platforms like Vercel or Cloudflare Workers should be your default.

Here is how the two approaches compare side by side:

Dimension	VPS	Serverless
Ops Burden	Manual setup, Nginx configs, process management, security patches	Fully managed; you focus almost entirely on application code
Scaling	Manual vertical scaling, adding boxes, setting up load balancers	Auto-scales instantly based on incoming traffic
Pricing Model	Fixed monthly/annual cost; you pay even when idling	Pay-per-use (requests/compute/bandwidth); virtually free at low volume
Cold Starts	None (persistent running processes)	Possible depending on the runtime (e.g., Node container vs. V8 isolates)
State & Storage	Local filesystem, co-located SQLite/Postgres, Redis	Stateless compute; requires managed DBs, KV stores, or S3-compatible object storage
Execution Time	Uncapped; great for long-running jobs and heavy background tasks	Strict CPU and execution timeouts per request
Runtime & Libs	Full root access; install whatever OS packages or binaries you want	Bound to supported runtimes, sandboxes, and platform-specific APIs
Networking	Static public IPs, direct SSH, unrestricted outbound connections	Dynamic egress IPs; static IPs or custom VPC networking often cost extra
Cost Curve	Predictable flat fees; cheaper at steady, high traffic	Dirt-cheap early on, but can spike fast with unoptimized loops or bandwidth spikes

For anyone starting out solo, I strongly recommend going Serverless first.

Developer time is your most expensive asset. Instead of spending your weekends configuring firewalls and updating OS packages, focus on shipping, talking to users, and finding product-market fit. Once you have sustainable traffic and clear infrastructure demands, you can always migrate.

Of course, serverless has hard limits. If your app needs persistent worker daemons, heavy audio/video transcoding, CPU-intensive background jobs, or custom native binaries, a VPS, container host (like Railway or Fly.io), or a dedicated job queue will be a much better fit.

2. Serverless Footguns to Watch Out For

Serverless makes deployment trivial, but the runtime environments vary significantly across platforms.

Take Vercel and Cloudflare Workers:

Vercel Functions run in a standard Node.js environment, but still impose limits on execution time, memory, CPU, and payload sizes.
Cloudflare Workers run on lightweight V8 isolates. They use their own Web Standards runtime APIs and rely on a compatibility layer to emulate a subset of Node.js.

In practice, code that runs fine locally in Node might crash immediately when pushed to Cloudflare Workers. Anything relying on native C++ bindings, child processes, direct filesystem access, or unsupported Node built-ins will bite you.

If you plan on using Cloudflare Workers, skim these docs first:

Node.js compatibility: Which Node APIs actually work.
Compatibility flags: How to toggle flags like nodejs_compat.
Workers Runtime APIs: Cloudflare's native primitives (Fetch, Web Crypto, Caching, etc.).
Durable Objects: For coordination and stateful edge compute.

You don't need to memorize every quirk. Instead, add these platform constraints directly into your project’s AGENTS.md (or AI system prompts / rules). That way, coding assistants like Cursor won't generate code incompatible with your runtime.

A few practical rules to bake in:

Target deployment: Cloudflare Workers (V8 isolate runtime, not full Node.js).
Stick to Web Standard APIs and verified isolate-compatible packages.
Always verify compatibility before introducing Node built-ins, filesystem calls, or native modules.
Check CPU execution limits and timeouts before writing asynchronous or background tasks.
Run a build and dry-run smoke test immediately after changing deployment configs.

Having these boundaries explicitly written down eliminates hours of debugging hallucinated, incompatible code generated by LLMs.

3. Dodging the "Surprise Serverless Bill"

A viral post recently surfaced showing a developer getting hit with a massive cloud bill out of nowhere:

https://x.com/shmily7/status/2107481028726251762

Other seasoned devs have shared similar horror stories and preventative tips:

https://x.com/mcwangcn/status/2104926120457953565

With "Vibe Coding" becoming second nature, one overlooked risk is that AI often writes broken polling, retry, or recursive logic. Left unchecked, this can hammer your endpoints endlessly and burn through your compute quotas and API credits before you notice.

Common culprits:

setInterval polling an API indefinitely without an exit condition.
Retrying failed requests instantly with no exponential backoff or retry caps.
React components re-mounting repeatedly, spawning duplicate polling loops in the background.
Webhook failures triggering infinite retry cascades.
Background workers getting stuck processing the same payload in a loop.
Aggressive client-side polling that stays active even after users switch tabs.

Individually, these look minor. But when paired with pay-per-request pricing, a bit of traffic, or upstream AI API costs, your bill can spiral very fast.

Here is my pre-launch checklist to keep bills under control:

1. Have AI Audit Your Loops and Workflows

Don't just ask the AI to implement the feature—explicitly ask it to look for edge cases in retries, recursion, loops, and background tasks. Verify that every poll has a teardown, every retry has backoff and limits, and requests are properly debounced.

2. Set Up Hard Budget Alerts

Configure spending alerts across your cloud hosts, managed databases, object stores, and third-party AI providers. Keep in mind that many platforms only notify you when a budget is crossed rather than cutting off the service. Alerts alone won't save you if your logic goes into an infinite loop overnight.

3. Track Usage Metrics, Not Just Vanity Traffic

Keep an eye on actual operational metrics: CPU execution time, function invocations, bandwidth egress, database row reads/writes, and storage operations. If you see a spike out of proportion with visitor growth, track down the offending endpoint immediately.

4. Have an Exit Plan Ready

If your traffic takes off to the point where serverless unit economics stop making sense, or you outgrow runtime constraints, be ready to migrate to a VPS or container setup.

With AI tools, refactoring deployment pipelines and writing migration scripts is faster than ever. But you still need to test thoroughly—especially around database connections, file uploads, cron jobs, environment variables, and webhook handlers.

The goal of frugal infrastructure isn't just cutting costs today—it’s making sure your resource usage scales predictably with your actual business.

4. Vercel vs. Cloudflare: Why I Lean Toward Cloudflare

Many developers spin up a Next.js template by default and deploy it straight to Vercel. It’s convenient, frictionless, and great for getting started.

Personally, though, I've grown weary of both the Next.js developer experience and Vercel’s vendor lock-in.

If you're curious about this perspective, this post breaks down the vendor dynamics well:

The Hypocrisy of Vercel

My preferred stack today is TanStack Start, built on top of Vite. Now that TanStack Start has hit 1.0, the developer experience feels so much cleaner and lighter.

Anyone who has worked on a non-trivial project with Next.js knows the pain of the dev server crawling and devouring all your RAM. No matter how powerful your laptop is, it somehow finds a way to peg your memory. The community has brought this up for years, and while recent releases mention improvements, I honestly have zero desire to go back.

Here is a quick look at how the free tiers compare:

(Note: Quotas are based on current official documentation as a general point of reference. Platform limits change over time, so always verify on their official pricing pages before committing.)

4.1 Vercel Hobby (Free Tier)

Resource	Allowance Reference
Fast Data Transfer (CDN Egress)	100 GB/month
Fast Origin Transfer	10 GB/month
Function Invocations	1,000,000 requests/month
Active CPU Time	4 hours/month
Provisioned Memory	360 GB-hours/month
Image Optimization	5,000 source images/month
Edge Image Caching (Read/Write)	300K / 100K ops/month
Build Limits	Max 45 mins/deployment; up to 100 deployments/day
Function Specs	Up to 2 GB memory / 1 vCPU; up to 300s timeout (depending on config)

Vercel shines with its Next.js ergonomics, preview environments, and seamless Git workflow.

However, for solo builders, it’s not just the 1M invocation cap you need to monitor—active CPU time, origin egress, and image optimization overages can trigger charges unexpectedly even if you think you're well within the free tier.

Docs: Vercel Pricing

4.2 Cloudflare (Free Tier)

Resource	Allowance Reference
Workers Invocations	100,000 requests/day (~3M requests/month)
CPU Time	10 ms per invocation
Static Assets (Workers Assets)	Free and unmetered (per platform guidelines)
KV Storage	100,000 reads/day; 1 GB storage
D1 Database	Daily read/write row quotas apply; storage included per plan rules
Durable Objects	Free request/compute allowances available depending on storage setup
R2 Object Storage	10 GB storage; 1M Class A ops/mo; 10M Class B ops/mo; Zero egress fees
Hyperdrive	Free query pooling tiers
Queues	Free monthly message operation limits

Cloudflare’s biggest advantage is the breadth of its ecosystem. Beyond compute (Workers), you get out-of-the-box object storage, databases, edge key-value stores, and message queues on a unified global edge.

R2 in particular is a game-changer for media-heavy tool sites. Free egress means you aren't penalized simply because users are downloading audio, video, or image assets from your storage.

One caveat: Cloudflare manages products under separate billing line items. A generous free tier on Workers doesn't automatically mean unlimited DB or KV usage. Track your CPU time, operations, and row limits independently.

Docs:

5. Beyond Hosting: Essential Free Tools

Hosting is only half the battle. Several third-party services offer generous free tiers that allow indie hackers to build a solid operational foundation on day one:

Tool	Core Use Case
Sentry	Exception monitoring, error stack traces, and performance bottlenecks
Google Analytics 4	Traffic sources, user acquisition, and conversion funnels
Microsoft Clarity	Free session replay, heatmaps, and UX interaction tracking

For a newly launched tool site, here is the order I recommend integrating them:

Error Tracking: Catch runtime crashes before users bother reporting them.
Product Analytics: Understand traffic sources, drop-offs, and which features actually get used.
Billing Alerts: Watch third-party AI APIs and compute limits like a hawk.
CI/CD Automation: Use GitHub Actions so deploying updates is a simple git push.

You don’t need to set all of these up on day one. Hook up the pieces that directly safeguard stability and inform product decisions first, then layer on the rest as you grow.

6. Wrap-up: My Reusable SaaS Starter

Every time you kick off a new project, setting up the same plumbing—auth, error tracking, analytics, styling, and deployments—gets tedious.

To cut down on boilerplate fatigue, I packaged my go-to setup into an open-source starter repo:

GitHub: LLmoskk/saas-starter

It reflects the stack I personally enjoy building with, and serves as a clean starting point for quick turnaround MVPs. You can easily clone it and have an AI agent adapt it to your preferred services.

Every solo developer eventually benefits from having their own starter kit. Standardizing the repetitive grunt work early frees up your time to focus on the only thing that actually matters: building a product people want.

Building My First Global SaaS Tool from Scratch

jy H uang — Sun, 27 Sep 2026 11:41:50 +0000

After some encouragement from my colleagues, I finally decided to build my own SaaS tool for the global market.

On September 8, I got a Mastercard that supports international payments. Right after that, I bought a domain, initialized the project, and started building.

The first version went live on day one.

As soon as it was deployed, I submitted the site to Google Search Console (GSC) and Bing Webmaster Tools, hoping to get it crawled and indexed as early as possible.

This post is a record of that process: choosing a domain, setting up the stack, deploying the product, working with AI coding tools, and figuring out a development workflow that works for a solo developer.

Choosing a Domain

I wanted to build a music-related utility site, so the first step was finding a suitable domain.

After comparing registrars, I found that the same domain was cheaper on Spaceship than on Namecheap, so I went with Spaceship.

I had read quite a few discussions about domain selection before starting. My main takeaways were:

If your budget allows, .com is usually the safest choice. .ai and .app are also worth considering.
Keep the domain short and easy to remember. Ideally, include a keyword related to the product.
Avoid hyphens, obscure English words, and random letter combinations whenever possible.

One reason .ai and .app can work well is search behavior.

People often search for phrases such as xxx app or xxx ai. If your domain naturally matches that intent, it can make the product easier to understand and remember.

At this stage, though, I did not want to spend too much money on a domain.

So I ended up buying:

musictool.tools

It costs roughly €6 per year.

Good enough for an early-stage experiment.

Setting Up the Project

For an SEO-driven product targeting international users, I prefer a stack that supports Server-Side Rendering (SSR).

The main reason is simple: search engines can receive relatively complete HTML directly, which reduces the amount of work required for crawling and indexing.

Because of that, I did not want to build the site as a purely client-rendered SPA.

This is also one of the reasons frameworks such as Next.js have become so popular among SEO-focused products.

That said, I personally find the Next.js development experience a bit heavier than I would like, so I chose TanStack Start (RC) instead.

For project initialization, I used an open-source stack generator I had used before:

https://better-t-stack.dev/

Once the initial scaffold was ready, I started adapting it to my own requirements with the help of AI.

Here is the stack I ended up using.

Engineering and Tooling

Category	Technology	Purpose
Monorepo	pnpm workspaces + Turborepo	Multi-package management and parallel builds
Language	TypeScript	End-to-end type safety
Code Quality	Oxlint + Oxfmt	Linting and formatting
Environment Variables	@t3-oss/env-core + Zod	Server and client env validation (`packages/env`)

Frontend and Full-Stack Framework

Category	Technology	Purpose
Full-Stack Framework	TanStack Start	SSR, file-based routing, Server Functions
Routing	TanStack Router	Type-safe routing and SSR integration
Build Tool	Vite 8	Development and production builds
SSR Runtime	Nitro	Server-side rendering and Vercel deployment support
UI Library	React	Component-based UI
Styling	Tailwind CSS v4	Utility-first CSS
Component Library	shadcn/ui (`packages/ui`)	Shared UI primitives
Icons	lucide-react	Consistent icon system
Theme	next-themes	Dark mode
Animation	Motion	Page and component animations
Notifications	Sonner	Toast notifications

Data and State Management

Category	Technology	Purpose
Server State	TanStack Query	Data fetching, caching, and SSR integration
Client State	Jotai	Shared UI and session state
Forms	TanStack Form	Form state and validation
API Layer	oRPC	End-to-end type-safe RPC with OpenAPI integration
ORM	Drizzle	TypeScript-first database access
Database	PostgreSQL	Primary data storage
Local Database	Docker Compose	Local PostgreSQL development environment

Authentication and Internationalization

Category	Technology	Purpose
Authentication	Better Auth	Sessions, social login, and TanStack Start integration
Login	Google OAuth	Third-party authentication
Internationalization	Paraglide JS + inlang	Compile-time i18n and locale-based URLs for SEO

AI

Category	Technology	Purpose
AI SDK	Vercel AI SDK	Streaming responses and Server Actions
Model Provider	@ai-sdk/google	Google model integration

Infrastructure and Third-Party Services

Service	Purpose
Vercel	Hosting, CI/CD, and Serverless Functions
Cloudflare	Domain DNS
Google OAuth	User authentication
Waffo Pancake	Subscription payments and Webhooks
Resend	Transactional email and user feedback
Cloudflare R2	S3-compatible object storage with presigned uploads
Google Analytics 4	Production traffic analytics
Microsoft Clarity	User behavior analytics and session recordings
Sentry	Frontend and backend error monitoring

Most of these services provide free tiers, which is more than enough for an early-stage solo project.

Payments

For payments, I chose Waffo, mainly because it is relatively friendly to independent developers.

I discovered it somewhat randomly while browsing online.

Stripe usually requires more preparation depending on where you are based, including considerations around business entities and banking.

I have not opened a Hong Kong bank account yet, so Waffo was the more convenient option for me at this stage.

The integration itself was straightforward.

I followed the official documentation, gave the relevant docs, prompts, and Skills to the AI coding agent, and let it handle most of the implementation.

If your setup allows it, Stripe is still worth evaluating based on your own business requirements.

Deploying the Product

Launching a small SaaS product today is much easier than it used to be.

Modern Serverless infrastructure is mature enough that lightweight SaaS tools often do not need a manually maintained server running 24/7.

Platforms such as Vercel and Cloudflare can handle most of the infrastructure for you while scaling automatically when necessary.

For this project, I connected the Git repository directly to Vercel.

Every push automatically triggers a new build and deployment.

There is almost nothing to manage manually.

At the current stage, deployment costs are also close to zero.

For object storage, I use Cloudflare R2.

Its free tier is generous enough for the early stage of the project, so storage has not added any meaningful cost yet.

The main expenses currently come from third-party APIs used by some features. Those require a small amount of prepaid credit, but the overall cost is still manageable.

For solo developers, the infrastructure barrier to launching a project has become extremely low.

You can build the first version almost entirely on free tiers.

Once the product has real users and revenue, you can upgrade infrastructure based on actual usage instead of guessing in advance.

My Development Process

The initial infrastructure setup took roughly one day.

After that, I moved on to actual feature development.

If you are unfamiliar with the target market, I think it makes sense to start with an AI-assisted research phase.

You can use AI Research tools to study competitors, identify common features, understand user expectations, and map out the basic product landscape.

In my case, I already knew this domain fairly well and had a clear idea of what I wanted to build.

So I went straight into AI Coding.

My development process has two main stages:

Design the feature.
Break down the requirements and implement them.

Designing with AI

For design work, I mainly use Pen.

After connecting it to DeepSeek and enabling x6, the overall design workflow became quite efficient.

My AI Coding Workflow

For implementation, I mainly use Matt's workflow.

The process looks roughly like this:

/grill me

Discuss the requirements with AI in detail and clarify the implementation approach.
/to-spec

Convert the discussion into a complete specification and high-level implementation plan.
/to-tickets

Break the plan into smaller tasks that can be implemented independently.
/implement-spec

Implement the feature step by step based on those tasks.
/code-review

Ask AI to review the implementation, then do a final manual review myself.

I have found this workflow surprisingly comfortable.

It reduces the amount of improvisation during implementation and gives the coding agent much clearer boundaries.

Letting `AGENTS.md` Accumulate Project Knowledge

One practice that has worked particularly well for me is asking AI to record mistakes, corrections, and project-specific rules in AGENTS.md.

Whenever something goes wrong, I try to convert that mistake into a reusable rule.

That gives future coding sessions access to the context accumulated from previous work.

Over time, the project starts developing its own operating manual.

This helps reduce repeated mistakes and makes future implementation more consistent.

The process becomes a kind of feedback loop:

Build → Find problems → Update rules → Build again

As the project's Harness becomes more complete, AI-assisted development also becomes much smoother.

For features that resemble something already implemented, a clear requirement and good task decomposition are often enough for the AI agent to handle most of the work.

I still review the result at the end.

Fully autonomous coding without verification is not something I am comfortable with yet.

The Token Problem

The biggest frustration during development has actually been Token limits.

I started with Cursor's $20 monthly plan.

I burned through the quota in roughly four days, mostly while using Grok.

After that, I switched to the $20 Codex plan.

The overall experience was decent, but I frequently had to wait around five hours for the usage quota to reset.

That interrupted the development flow more often than I expected.

I also used Tibo after its quota reset, but that still was not enough.

Later, Z Code gave users a huge Token allowance, on the order of hundreds of millions of Tokens.

There has been some controversy around it recently, but by then I had already used it extensively.

Eventually, I adjusted my workflow.

The current version looks like this:

Use GPT 5.6 or GPT 6 for requirement analysis, architecture, and task decomposition. Then hand clearly defined implementation tasks to lower-cost models such as GLM.

At first, I was skeptical about this setup.

I assumed that anything even moderately complex should be implemented by the strongest available model.

After trying it in practice, my view changed.

If the architecture has already been thought through and the tasks are broken into sufficiently small units, models such as GLM can handle a surprisingly large amount of real implementation work.

They perform especially well when:

The task boundaries are clear.
The expected behavior is explicit.
The implementation path is already defined.
The relevant project context is available.

For this type of task, the output is often good enough for my needs.

After eventually exhausting my Z Code quota as well, I subscribed to Command Code's $10 plan and started using DeepSeek 4.1 Flash more often.

Among Chinese models, the ones I currently find most practical for coding are GLM and DeepSeek.

They occasionally enter what I jokingly call "thunderous deep-thinking mode" and spend far too long reasoning about a very simple problem.

Still, their coding ability is already quite solid.

One small lesson from my own usage:

Start with the reasoning level set to "High." Unless the task is genuinely difficult, there is usually little reason to leave it on "Extra High" all the time.

Expensive Models Do Not Need to Do Everything

One of the biggest changes in my AI coding workflow has been realizing that the most expensive model does not need to handle every task.

A stronger model can focus on:

Requirement analysis
Architecture
Technical design
Edge cases
Task decomposition

Then a lower-cost model can handle:

CRUD implementation
UI adjustments
API wiring
Repetitive refactoring
Well-defined feature work

This creates a fairly practical division of labor.

You get the reasoning quality of stronger models where it matters most, while keeping Token costs under control during implementation.

For a solo developer, that balance can make a significant difference.

Learning SEO Along the Way

Recently, I have also been spending more time learning SEO.

Before building this project, my understanding of SEO was fairly shallow.

I assumed that semantic HTML, good page titles, and a clean page structure covered most of the important work.

Once I actually started building a global tool site, I realized there is much more to it.

For example:

Keyword research with tools such as SEMrush
Search volume analysis
Keyword difficulty analysis
Site architecture planning
Core keyword optimization
Long-tail keyword targeting
Content planning
Continuous page optimization

Ultimately, all of this has the same goal:

Increase the site's visibility in search engines.

When someone searches for a problem related to your product, you want your site to appear as high as possible in the results.

That gives you a chance to turn search traffic into:

Search → Click → Visit → Sign up → Use → Pay

I am still very early in this process, so I am learning as I go.

Final Thoughts

That is where the project stands for now.

My main goal with this post was to document what it looks like to start building a global SaaS tool from scratch as a solo developer.

The infrastructure is cheap.

Deployment is easy.

AI can already take over a meaningful amount of implementation work.

The harder part is gradually building a workflow that makes all of those tools work together reliably.

For me, that currently means:

Research → Design → Spec → Tickets → Implement → Review → Update AGENTS.md → Repeat

I am still learning, especially when it comes to SEO, distribution, and turning the project into something that consistently attracts users.

If I discover anything useful along the way, I will keep sharing what I learn.

Try it
Free account with starter credits, no card required: musictool.tools

Welcome to give me feedback on any suggestions for improving the website.👏