Pieter Levels Says Vibe Coding Saves Him ~$25K/Month by Replacing SaaS

Key Takeaways

• Indie hacker Pieter Levels (@levelsio) says he has replaced a large part of his paid SaaS stack with vibe-coded internal tools, estimating the result at roughly $25,000 per month in savings.
• His replacements include image resizing, NSFW detection, screenshots, monitoring, moderation, workflow automation, photo editing, maps, uptime monitoring, blogging, customer support, and scraping.
• The strongest replacement candidates are not usually complex SaaS platforms. They are narrow, high-volume services built around mature open-source components such as Sharp, NudeNet, Nginx, OpenFreeMaps, Patchright, Redis, and Telegram bots.
• Levels does not advocate self-hosting everything. He still pays for domains, email sending, object storage, backups, VPS hosting, and LLM APIs because these services have infrastructure, reliability, compliance, or scale advantages that are difficult to reproduce economically.
• The bigger lesson is that AI coding is changing the traditional build-vs-buy equation. A service that was rational to rent for $500 or $2,000 per month may become rational to rebuild if an AI coding agent can produce the required 20% of functionality quickly.

Pieter Levels Says Vibe Coding Is Saving Him About $25,000 per Month

The idea comes from a recent X post by Pieter Levels, the indie developer behind the @levelsio account.

Levels says he has progressively replaced many of the SaaS products and operational services used across his websites with tools he built himself through vibe coding.

His estimate: about $25,000 per month in savings.

That figure should be understood as Levels' own reported estimate, not an independently audited cost study. The more important part of the post is the architecture behind the savings.

The replacements are surprisingly practical.

Instead of rebuilding Stripe, Cloudflare, or an entire hyperscale infrastructure platform, he targets narrow services where the underlying technical primitive already exists.

The pattern looks like this:

Expensive SaaS API
→ identify the 10-20% of features actually used
→ combine mature open-source components
→ use AI coding to build the integration layer
→ deploy on existing infrastructure
→ remove recurring SaaS markup

That is the part of vibe coding that matters economically.

The SaaS Products Pieter Levels Says He Replaced

Levels listed a broad set of services that he now handles with internally built alternatives.

The individually stated savings add up to roughly $20,800 per month before counting the weather API, blog platform, and any other costs included in Levels' overall estimate.

That is why the headline figure should be described as approximately $25,000 per month according to Levels, rather than presented as an accounting total that can be reproduced directly from the itemized list.

Why These SaaS Products Are Replaceable

The services in Levels' list share an important characteristic: most are not fundamentally new technologies.

They are packaged infrastructure.

A commercial image resizing API, for example, may provide a polished API, authentication, billing, dashboards, scaling, retries, observability, global delivery, and support.

But the core operation may still be:

Input image
→ resize
→ crop
→ compress
→ convert format
→ cache
→ return asset

The same is true for many screenshot, monitoring, automation, and scraping products.

Before AI coding, the question was whether saving a few hundred or a few thousand dollars per month justified several days or weeks of engineering work.

Vibe coding reduces the cost of that engineering layer.

The economic threshold moves.

1. Image Resizing API → Sharp + Redis

Levels says replacing an image resizing API with a Node.js service based on Sharp and Redis saves around $1,500 per month.

This is one of the clearest examples of where internal tooling can make sense.

Sharp already handles most common image operations:

• resizing;
• cropping;
• rotation;
• compression;
• JPEG, PNG, WebP, and AVIF conversion;
• metadata handling;
• compositing.

The custom application mainly needs to provide the surrounding infrastructure:

Request
→ validate image
→ calculate transformation key
→ check cache
→ process with Sharp
→ store result
→ return cached URL

Redis can be used for caching metadata, locks, rate limits, queues, or deduplication.

The hidden engineering work is not image resizing itself. It is protecting the service against malformed files, huge images, memory exhaustion, repeated transformations, and abusive requests.

For a company already operating image-heavy products, however, this can be an unusually strong build-vs-buy candidate.

2. Google Vision NSFW Detection → NudeNet

Levels reports replacing Google Vision-based NSFW detection with a Python service using NudeNet, with claimed savings of around $2,500 per month.

The economic logic is similar.

Commercial computer-vision APIs charge for convenience and managed scale. If a product only needs a narrow classifier, an open-source model can reduce per-request costs substantially.

A typical internal moderation pipeline might be:

Upload
→ basic file validation
→ local classifier
→ confidence score
→ allow / block / review

But this replacement has an important limitation.

A commercial moderation service may provide broader category coverage, continuous model improvements, global infrastructure, service-level guarantees, and abuse protections.

A self-hosted model must be evaluated against the application's real data.

False negatives and false positives can cost far more than the API bill if moderation decisions affect user safety or platform compliance.

3. Cloudflare Streaming → Nginx on a VPS

Levels says he replaced Cloudflare video streaming with his own Nginx-based VPS setup and estimates about $250 per month in savings.

This can work well when the workload is controlled.

For straightforward video delivery, the architecture can be simple:

Video file
→ VPS
→ Nginx
→ browser

But a managed video platform can also provide:

• transcoding;
• adaptive bitrate streaming;
• global CDN delivery;
• HLS packaging;
• analytics;
• signed URLs;
• automatic optimization;
• large-scale bandwidth handling.

The internal version is attractive when the product does not need most of those features.

The mistake would be comparing an Nginx server with the full feature set of a managed video platform and assuming they are identical.

They are not.

The goal is to replace the subset actually being used.

4. Screenshot API → Custom Browser Service

Levels says he replaced API Flash with his own screenshot service, saving roughly $250 per month.

A browser screenshot API is another classic vibe-coding candidate.

Modern browser automation can handle:

• screenshots;
• Open Graph images;
• viewport simulation;
• page-to-PDF rendering;
• custom CSS injection;
• element screenshots;
• delayed rendering.

A simple architecture can be:

POST /screenshot
→ queue
→ browser worker
→ load URL
→ wait for page state
→ capture image
→ save result

The difficult parts are concurrency, browser crashes, SSRF protection, hostile pages, memory leaks, timeouts, and bot detection.

If screenshots are mostly generated from pages controlled by the same company, the operational problem becomes much easier.

5. New Relic + IPHub → error2telegram

Levels says he replaced parts of New Relic and IPHub with an internal system called error2telegram, saving around $250 per month.

This illustrates another useful principle:

many small teams do not need the full feature set of enterprise observability software.

An internal monitoring layer may only need to answer a few questions:

• Is the server alive?
• Is disk usage dangerous?
• Did an application start throwing errors?
• Is a suspicious IP attacking several sites?
• Did a background job fail?
• Which VPS needs attention?

Those events can be pushed directly to Telegram.

For a solo founder or very small engineering team, that may be more actionable than a sophisticated observability dashboard.

The tradeoff is obvious: deep tracing, historical analytics, complex alert routing, compliance controls, and enterprise incident workflows are much harder to reproduce.

6. Human Moderators → xAI-Based Moderation

The largest individual saving in Levels' list is not a SaaS subscription.

It is labor.

He says replacing human moderation across his sites with xAI-based moderation saves around $10,000 per month.

This is where AI changes operating economics more dramatically than traditional automation.

A modern moderation stack can combine:

Submission
→ deterministic filters
→ text/image classifier
→ LLM policy check
→ confidence score
→ approve / reject / escalate

The strongest systems do not blindly send every decision to one LLM.

They use layered controls.

Low-risk cases can be approved automatically. Clear violations can be blocked. Uncertain or high-impact cases can be escalated.

That architecture can reduce human workload significantly without assuming AI moderation is perfect.

7. IFTTT → Telegram Bot

Levels says a Telegram bot replaced IFTTT workflows and saves roughly $100 per month.

This replacement is technically simple but strategically important.

A surprising amount of automation SaaS usage is just:

Trigger
→ condition
→ API request
→ notification

Examples include:

• check a feed and send an alert;
• monitor a payment event;
• run a scheduled API request;
• notify when a server changes state;
• post a message after a deployment.

When the workflows are stable and internal, a few webhook handlers and cron jobs can replace a surprising amount of subscription software.

The boundary appears when a company needs hundreds of third-party integrations, non-technical workflow editing, complex branching, audit logs, and enterprise permissions.

At that point, rebuilding Zapier or IFTTT becomes a product of its own.

8. Photopea → Custom Photo Editor

Levels says he replaced an embedded Photopea editor inside Photo AI with his own vibe-coded photo editor, estimating around $100 per month in savings.

The interesting point is not the $100.

It is product ownership.

If a photo product only needs a limited set of editing functions, a full Photoshop-style application is unnecessary.

A focused editor might only need:

• crop;
• rotate;
• zoom;
• erase;
• brush;
• undo;
• background controls;
• basic adjustments;
• export.

Vibe coding makes these product-specific editors much cheaper to build.

Owning the editor also gives the product tighter UX control and removes dependency on a third-party embedded interface.

9. Mapbox → OpenFreeMaps

Levels reports replacing Mapbox with an implementation based on OpenFreeMaps, saving around $500 per month.

This works when the application mainly needs map rendering rather than the entire location platform.

A lightweight open mapping stack can cover:

• map tiles;
• markers;
• custom styles;
• location visualization;
• basic interactive maps.

But Mapbox also provides capabilities such as geocoding, directions, routing, traffic data, search, navigation, and location intelligence.

Replacing map rendering does not automatically replace all of those services.

This distinction is critical when evaluating SaaS alternatives.

10. UptimeRobot → Uptime Canary on Kuma

Levels says his uptime monitoring now costs around $5 per month, using an Uptime Canary application running on Kuma, for estimated savings of roughly $50 per month.

Uptime monitoring is almost the perfect example of a narrow internal service.

At its simplest:

Every N minutes
→ request URL
→ check HTTP status
→ record latency
→ retry
→ alert on failure

Commercial products add polished dashboards, status pages, multiple regions, escalation policies, historical metrics, and integrations.

For a small portfolio of sites, a self-hosted system may be enough.

11. Ghost → Custom Blog Platform

Levels also says he replaced Ghost with his own blog platform.

No individual savings figure was provided.

This is less about infrastructure cost and more about how small the required feature surface can become.

A personal or company blog may only need:

• Markdown;
• posts;
• tags;
• RSS;
• sitemap generation;
• SEO metadata;
• images;
• an admin interface.

A full CMS is useful when editorial workflows are complex.

For a solo developer, the custom version can be dramatically smaller.

12. Human Customer Support → Featurebase + AI Bot

Levels estimates roughly $5,000 per month in savings after moving customer support toward Featurebase plus an AI support bot.

Again, the largest saving is human labor rather than SaaS licensing.

AI support works best when the system can retrieve reliable product information and understand enough customer context to answer common questions.

A stronger architecture looks like:

Question
→ classify intent
→ retrieve documentation
→ retrieve allowed account context
→ generate answer
→ confidence check
→ human escalation

Billing disputes, account security, legal complaints, refunds, and unusual edge cases should generally have stricter escalation rules.

The opportunity is not eliminating humans from every support interaction.

It is preventing humans from repeatedly answering the same predictable questions.

13. ScrapingBee / SerpAPI → Patchright

Levels says he now runs his own scraper for around $1 per month using Patchright, replacing ScrapingBee and SerpAPI usage and saving roughly $250 per month.

Scraping is a useful example because the code is often the easy part.

A basic architecture is straightforward:

Scheduler
→ queue
→ Patchright browser
→ load target
→ extract data
→ normalize
→ store
→ retry failures

The hard parts are:

• proxy quality;
• anti-bot detection;
• CAPTCHA handling;
• browser fingerprints;
• IP reputation;
• retries;
• rate limiting;
• target-site changes.

This means a low-volume internal scraper can be extremely cheap while a general-purpose commercial scraping platform remains difficult and expensive to reproduce.

The important question is not whether a scraper can be written.

It is whether it can maintain the required success rate at the required volume.

The Services Pieter Levels Still Refuses to Replace

The most useful part of Levels' post may actually be the list of services he does not want to rebuild.

He says the remaining external services include:

• Cloudflare Domains;
• Cloudflare Email Sending;
• Cloudflare R2 Storage;
• Backblaze B2 for backups;
• Hetzner for VPS hosting;
• xAI for LLM inference.

His reasoning shows where the vibe-coding strategy reaches its economic boundary.

Replacing these services would mean taking responsibility for infrastructure that benefits from major economies of scale.

Domains

Going beyond using a registrar and attempting to replace the domain-registration layer means dealing with registries, accreditation, renewals, abuse processes, and critical infrastructure.

That is very different from building a screenshot API.

Email

Running an SMTP server is easy.

Running a reliable email delivery operation is not.

A serious system must manage:

• IP and domain reputation;
• SPF;
• DKIM;
• DMARC;
• bounces;
• complaints;
• suppression;
• spam filtering;
• abuse;
• deliverability.

This is exactly the kind of operational burden that can make a cheap managed service worth paying for.

Object Storage and Backups

Replacing R2 or Backblaze with local disks sounds inexpensive until reliability requirements are included.

Then the system needs:

• redundant drives;
• replication;
• backup verification;
• disaster recovery;
• monitoring;
• replacement hardware;
• off-site copies.

Storage providers spread those costs across enormous infrastructure.

VPS Hosting

A VPS provider owns the physical servers, networking, power, cooling, hardware replacement, data-center access, and connectivity.

Self-hosting the server at home may save a line item while creating an entirely new operations problem.

Frontier LLMs

Running local models can make sense for some workloads, particularly at high sustained utilization.

But replacing a frontier-model provider may require expensive GPUs, inference optimization, model upgrades, redundancy, monitoring, and capacity planning.

For many small companies, buying inference remains more efficient.

The Real Vibe Coding Strategy: Replace Software Layers, Not Economies of Scale

Levels' stack suggests a useful rule.

Vibe code the thin software layers. Keep paying for the heavy infrastructure layers.

Good replacement candidates often look like:

• image transformation APIs;
• screenshot APIs;
• file converters;
• small scraping workloads;
• webhooks;
• scheduled jobs;
• internal dashboards;
• basic monitoring;
• uptime checks;
• lightweight CMS features;
• moderation workflows;
• support automation;
• simple mapping interfaces.

Poor replacement candidates often include:

• payments;
• banking;
• domain registries;
• high-deliverability email;
• globally redundant object storage;
• large-scale CDN infrastructure;
• physical server hosting;
• frontier-model training and inference.

The difference is not whether something can technically be built.

Almost anything can.

The difference is whether owning it creates economic leverage.

The Hidden Cost Behind '$0/Month'

Several replacements in the post are described as costing roughly zero.

That does not necessarily mean the service has zero economic cost.

Usually it means the incremental cost is close to zero because the underlying infrastructure is already running.

If a company already pays for a Hetzner VPS, adding a tiny screenshot worker may not materially change the monthly server bill.

But a realistic calculation should still consider:

• compute;
• bandwidth;
• storage;
• backups;
• monitoring;
• security patches;
• maintenance;
• debugging;
• failures;
• developer time;
• migration work.

This matters because the wrong conclusion from Levels' post would be:

Every SaaS product is overpriced and should be self-hosted.

The better conclusion is:

AI lowers the minimum size of an internal tool that is economically worth building.

A New Build-vs-Buy Formula for the Vibe Coding Era

The traditional decision could be simplified as:

Engineering cost > SaaS subscription
→ buy the SaaS

Vibe coding changes the inputs.

A better framework is:

Potential annual savings
=
SaaS fees
- infrastructure
- expected maintenance
- migration cost
- failure risk
- operational burden

Then evaluate five questions.

1. How much of the SaaS is actually being used?

A team may pay for a platform with 100 features while using three.

Those three features are the true replacement target.

2. Is there a mature open-source primitive underneath it?

The presence of libraries such as Sharp, FFmpeg, Chromium, Redis, PostgreSQL, MapLibre, or mature ML models changes the economics dramatically.

AI does not need to invent the underlying technology.

It mainly needs to assemble it into the required product.

3. Is the workload predictable?

Stable internal workloads are easier to self-host.

Highly bursty or global workloads often benefit from managed infrastructure.

4. What happens when the replacement fails?

A broken social-image generator is inconvenient.

A broken payment system can stop revenue.

Criticality should strongly influence the build-vs-buy decision.

5. Can the internal replacement remain intentionally small?

This is the most important constraint.

If the requirement is image resizing, build image resizing.

Do not accidentally build Cloudinary.

If the requirement is screenshots, build screenshots.

Do not accidentally build Browserless.

If the requirement is five internal automations, build five workflows.

Do not accidentally build Zapier.

The 80/20 SaaS Replacement Playbook

A practical cost-reduction workflow looks like this:

Step 1: Export the SaaS bill

List every recurring software and API expense from the last 90 days.

Record:

• monthly cost;
• annualized cost;
• usage volume;
• business criticality;
• features actually used.

Step 2: Sort by annualized savings

A $20/month tool is rarely worth rebuilding first.

A $2,000/month API deserves attention.

Step 3: Identify commodity primitives

Look for services whose core function can already be handled by mature open-source software.

Examples:

Image resize → Sharp
Video processing → FFmpeg
Screenshots → Chromium
Uptime → Kuma
Maps → OpenFreeMaps / MapLibre
Browser automation → Patchright
Automation → cron + webhooks
Moderation → classifier + LLM

Step 4: Build only the required subset

Define a deliberately narrow specification.

Avoid feature parity.

Step 5: Run both systems in parallel

Do not cancel the SaaS immediately.

Compare:

• success rate;
• latency;
• accuracy;
• uptime;
• resource usage;
• operational effort;
• real monthly cost.

Step 6: Add rollback

The original provider should remain easy to restore during the migration period.

Step 7: Cancel only after the replacement proves itself

The goal is lower cost without creating fragile infrastructure.

Common Failure Modes

Treating reported savings as universal benchmarks

Levels' numbers come from his own products, usage levels, infrastructure, and workflows.

Another company may have completely different economics.

Ignoring maintenance

AI can write the first version quickly.

Someone still owns production.

Ignoring security

File processing, browser automation, scraping, and URL screenshot services all process potentially hostile input.

Isolation, network restrictions, validation, and resource limits matter.

Replacing cheap SaaS instead of expensive SaaS

Saving $15 per month while creating a permanent maintenance burden is usually a bad trade.

Chasing feature parity

Internal replacements win because they are smaller than the SaaS product.

Feature parity destroys that advantage.

Automating high-risk decisions without escalation

Moderation and customer support can produce large savings, but uncertain cases still need safe fallback paths.

Why This Matters for SaaS Businesses

The deeper implication of Levels' post is not simply that founders can save subscription fees.

It is that AI coding can increase software margins.

A modern SaaS business may have a cost chain like:

Revenue
→ payment provider
→ cloud hosting
→ image API
→ video API
→ monitoring
→ support platform
→ automation service
→ scraping API
→ AI API

Every layer takes part of the margin.

Vibe coding makes it possible to collapse some of the simpler layers into internally owned software.

The emerging architecture looks more like:

Open-source primitive
+
AI-written integration layer
+
existing VPS/serverless infrastructure
+
managed services where scale really matters

That is a much more useful interpretation than the simplistic idea of 'self-host everything.'

Conclusion

Pieter Levels' reported ~$25,000 per month in savings offers a strong case study for how vibe coding is changing the economics of operating internet businesses.

The most compelling replacements are narrow, high-volume services where mature open-source technology already exists: image resizing, screenshots, scraping, monitoring, uptime checks, workflow automation, moderation, customer support, and basic mapping.

At the same time, Levels' remaining SaaS stack is equally instructive.

He still pays for domain infrastructure, email delivery, object storage, backups, VPS hosting, and LLM APIs because those services benefit from reliability, physical infrastructure, network scale, or operational expertise that is expensive to reproduce.

The practical rule is straightforward:

Buy the infrastructure with strong economies of scale. Vibe code the thin software layers whose recurring markup is larger than the cost of owning them.

For teams trying to reduce SaaS spend, the best next step is to rank recurring tools by annual cost, identify which expensive products are mostly wrappers around mature open-source components, and test one deliberately narrow replacement before attempting anything broader.