--forcepushed--fp
  • Home
  • Articles
  • Resources
  • Projects

Build smarter, ship faster, and stand out from the crowd.

Subscribe or follow on X for updates when new posts go live.

Follow on X

Self-Hosting Isn’t Expensive — Your Time Is

Background

There are a lot of cloud and hosting options today:

  • AWS Lambdas
  • Cloudflare Workers
  • Coolify
  • Edge runtimes
  • Firebase
  • Nuxt
  • Render
  • Vercel

I’ve gone into detail on many of these here:
https://forcepushed.com/articles/solo-dev-hosting/

If you’re an inexperienced solo developer and don’t yet know how to deploy your SaaS, website, or web app, deciding to “do it yourself” can feel genuinely intimidating. That’s normal. There’s a lot of surface area, and the tradeoffs aren’t always obvious from blog posts or pricing pages.

What is obvious, though, is that hosting decisions tend to get framed around cost — and often in the wrong way.

Put Your Business / SaaS First

Most managed platforms exist for a reason: they absorb a huge amount of operational complexity. In practice, a good PaaS is like having a DevOps employee baked into your SaaS.

They handle:

  • Deployments
  • Scaling
  • CI/CD
  • Rollbacks
  • Preview environments
  • Infrastructure failures
  • A large chunk of security and networking concerns

That saves you time — and time is almost always the most constrained resource in a business.

If you’re building a real product, put your business hat on. Pass infrastructure costs to the end user. Deployment itself shouldn’t be your core concern; your product and business model should be.

Higher bills are often a good problem to have. They usually mean usage is growing. And if cost becomes a real issue, you should already have proof of traction — which is exactly what funding, pricing changes, or optimization decisions are based on.

Don’t solve problems that haven’t shown up yet.

I’m not going to fault anyone for living the $5 VPS life if that’s genuinely what they enjoy. But if your goal is to grow a business and make money from users, serverless and managed platforms usually cost marginally more money and save orders of magnitude more time.

Labor cost is the number one constraint in almost every tech business.

Don’t spend a dollar of your time to save a dime in your wallet.

Also: “expensive” is subjective. A $1,000 bill might be catastrophic for one person and irrelevant for another. The question isn’t is Vercel expensive? — it’s:

Is the platform delivering positive ROI for your business?

Only you can answer that, and the answer changes as your product matures.

Hosting Considerations, Responsibilities, and Risk

You’ve probably heard stories like this:

“My project went viral, traffic exploded, and I got hit with a massive bill.”

These stories aren’t fake — but they’re also missing context.

Yes, traffic spikes can push you into higher tiers. The real questions are:

  • Is the growth sustained or a one-time spike?
  • Can your business afford the new baseline?
  • Is your pricing or monetization aligned with usage?

There are mitigation strategies:

  • Soft and hard spend limits
  • Firewall rules
  • Rate limiting
  • Better caching

But cost isn’t the only responsibility to think about.

What about:

  • Failovers and outages?
  • Monitoring, alerting, and logging?
  • Backups and recovery?
  • Support responsiveness?
  • Ease of use for non-engineers?

Then there’s developer experience:

  • Continuous deployment
  • Preview branches
  • Automatic scaling
  • Environment isolation

These are hard to build and maintain correctly. That’s what platforms like Vercel are actually selling.

And don’t forget team growth. Every additional collaborator often means another paid seat — including designers and product managers who need preview deployments to review work.

For context: at ~100k page views/month, ~50 optimized static images, some user-uploaded image optimization, middleware on authenticated routes, and dynamic data fetching, my bill sits around $17 for Speed Insights plus $20 for a single Pro seat.

Honestly, I’m about to drop Speed Insights and sit at $20/month.

At that level, it’s cheap. And the hours saved are worth far more than the dollars spent.

Why Not Just Do It Yourself?

If you’re a solo dev building a SaaS, you’re no longer “just a developer.”

You’re also:

  • CTO
  • CEO
  • DBA
  • DevOps
  • Marketer
  • QA
  • Sometimes the cleaning staff

My take: you should invest some time learning the basics of deployment and how your framework (Next.js or otherwise) actually works. That knowledge pays off long-term, and you don’t need to learn everything at once.

Learn just enough to move to the next step.

Yes, you can get surprisingly far on a €5/month VPS with low traffic. At that point, you are the cloud provider. You own the entire stack — for better or worse.

At a minimum, learn:

  • How Docker containers work
  • How a reverse proxy works
  • Basic Linux and networking concepts

Grab a cheap VPS from Hetzner or Contabo and you’ll save money — if you value that learning experience.

But don’t optimize prematurely. Make improvements only when something is genuinely broken:

  • Outages
  • Customers can’t buy
  • You need infrastructure changes to ship a feature

One of the biggest mistakes people make is defaulting to managed platforms without understanding them — which can absolutely lead to unnecessary costs.

Vercel works great if you know what you’re doing. If you don’t, it can get expensive fast.

There are also platform limitations to consider: bandwidth caps, opaque usage metrics, and pricing that’s hard to predict unless you understand how your app behaves.

How Much Work Is Required to Keep Costs Down?

Caching. Really understanding caching.

This is where most people get tripped up.

Next.js caching gets a bad reputation, but many complaints come from people who haven’t read the docs or experimented with how the pieces interact.

Good caching does two things:

  1. Improves performance
  2. Keeps costs down by letting one expensive render serve many users

Serverless scaling is the entire point of platforms like Vercel. If your unmonetized app goes viral on a $5 VPS, it’ll just crash. On serverless, it’ll scale — and you’ll get the bill.

That’s not a failure of the platform. That’s the business model working exactly as advertised.

You can mitigate this with:

  • Spend limits
  • Ads
  • Paid tiers
  • Proper caching
  • Rate limiting

Which leads to the real question:

Is it better to learn a provider-specific abstraction — or to learn how the system actually works?

There’s no universal answer, but the latter knowledge tends to age better.

When It’s Time to Do It Yourself

Some clear signals:

When your Vercel bill costs more than a DevOps engineer.

When a simple mistake — like a useEffect stuck in a loop calling an API — creates a runaway bill.

When your app gains traction and you realize the framework or architecture you chose isn’t suitable at scale.

The worst case is when you’re not the technical decision-maker.

I once reviewed a $260 bill and traced it back to a developer triggering an API call inside a useEffect that updated the same state it depended on — an infinite loop.

The app “worked,” but the mistake was costly. That’s not an advanced bug. That’s a rookie one.

On Vercel specifically:

  • Don’t use middleware on every route
  • Understand ISR and tagging
  • Avoid unnecessary revalidation

In reality, massive bills are rare unless:

  • You statically generate hundreds of thousands of pages (e-commerce)
  • You push large amounts of data through functions (e.g. file processing)
  • You need enterprise features

For example: HIPAA compliance with a BAA agreement. We paid ~$400/month for a terrible marketing-site builder just for that feature. On Vercel, it’s enterprise-only — starting in the low five figures per month.

That’s not “expensive.” It’s enterprise-priced.

Final Thought

Hosting isn’t the problem.

Lack of understanding — or optimizing too early — usually is.

Spend money to buy time. Spend time to buy leverage. Know which one you’re doing.