DEV Community

RequiemCat
RequiemCat

Posted on • Originally published at imagebackgroundremover.xyz

I built an online background remover and learned a lot from launching it

I built an online background remover and learned a lot from launching it

I recently launched a small web app called ImageBackgroundRemover:

👉 https://imagebackgroundremover.xyz

It removes image backgrounds online and returns a transparent PNG. The main use cases I had in mind were:

  • product photos
  • portraits
  • logos
  • simple content creation workflows

This wasn’t a "huge startup idea." It was more of a practical product: build something useful, keep the scope small, ship it, and learn from real users instead of polishing forever.

Why I built it

There are already a lot of background removal tools out there, so I wasn’t trying to invent a brand-new category.

What I wanted was something that felt:

  • simple
  • lightweight
  • easier to price for smaller users
  • useful for solo sellers, creators, and people who only need this workflow occasionally

A lot of tools in this space are either:

  • very polished but expensive for light usage
  • aimed at teams and larger workflows
  • or a bit too bloated for "I just want a transparent PNG quickly"

So I decided to make a small version focused on doing one thing well.

Tech stack

The project is built with:

  • Next.js
  • Cloudflare Pages
  • Cloudflare D1
  • PayPal for payments and subscriptions
  • Google Analytics 4 for basic tracking

The product currently supports:

  • JPG / PNG / WEBP uploads
  • transparent PNG output
  • free credits after sign-in
  • one-time credit packs
  • monthly subscriptions

The fun part: launching is where the real bugs show up

Like a lot of small projects, building the core product wasn’t the hardest part.

Launching it was.

A few of the issues that showed up only after going live:

1. A subscription plan broke because of a stale PayPal plan ID

One pricing option worked, another one didn’t.

That turned out to be a classic integration problem: the stored PayPal plan ID for one monthly subscription had become invalid, so checkout failed with a resource error.

The fix wasn’t just replacing the bad ID. I changed the logic so the app can:

  • validate existing billing plan records
  • detect invalid PayPal plan IDs
  • automatically recreate plans when needed
  • retry subscription creation instead of failing immediately

That kind of thing is easy to miss if you only test the happy path.

2. GA4 silently stopped receiving data

This one was annoying because everything looked configured.

The real issue was that the production environment variable for the GA measurement ID was effectively empty at runtime, so the analytics script never got injected.

The lesson:

Don’t trust configuration UIs just because a key exists. Always verify that the value is actually present in the deployed runtime.

3. Cloudflare/Git-based deploys can get weird if local fixes aren’t pushed

At one point I had a production deployment working from a direct deploy, but the Git-linked rebuild failed because the commit only existed locally and not on GitHub yet.

That caused a ref-not-found style deployment error.

Another reminder that launch problems are often not coding problems — they’re deployment, runtime, and configuration problems.

What I learned

A few things stood out during this launch.

Shipping small is still worth it

Even in crowded spaces, building a focused version of a familiar tool teaches a lot.

You don’t need a completely original category to learn useful lessons about:

  • UX
  • pricing
  • infra
  • analytics
  • payments
  • landing pages
  • distribution

Integrations fail in very non-obvious ways

Payment systems, analytics, deployment platforms, and runtime config can all fail correctly while still breaking your product.

The bug is often not in your main feature.

It’s in the glue.

Runtime verification matters more than config screenshots

I’m trying to get better at verifying things by actual behavior:

  • does checkout really work?
  • does GA really fire?
  • does the page really include the script?
  • does the deployed environment really have the variable?
  • does the production path behave like expected?

That sounds obvious, but it’s easy to skip when you’re moving fast.

What’s next

Right now I’m focusing on:

  • improving positioning and landing page clarity
  • building better use-case pages
  • understanding which users actually care
  • finding distribution channels that fit a small utility product

I’m also interested in the broader question of how to launch small developer-built tools in crowded markets without overcomplicating them.

I’d love to hear from other builders

If you’ve launched something small, what caused more problems for you after launch?

  • product issues
  • infra and deployment issues
  • payment issues
  • analytics issues
  • or figuring out distribution?

I’m finding that the product itself is often only half the work.

If you want to check it out, here it is again:

👉 https://imagebackgroundremover.xyz

Top comments (0)