I Built My First AI Tool Site in 17 Days: From MVP to Payments and SEO

I built my first AI tool site in 17 days.

It is called BG Remover, a simple web tool for removing image backgrounds and downloading transparent PNGs.

I did not choose this idea because it was a new keyword or an empty market. It was not.

I chose it because I wanted to complete the full loop of building a tool site for global users: MVP, deployment, login, credits, pricing, payments, SEO, analytics, and early distribution.

The main goal was not perfection.

The goal was to complete the full loop.

Why I Chose a Background Remover

Background removal is not a new market.

There are already many strong products in this space. I knew that from the beginning.

So why did I still choose it?

Because for my first tool site, I wanted a clear and familiar problem. I did not want to spend all my energy guessing whether users understood the use case.

Everyone understands this problem:

I have an image. I want the background removed. I want a transparent PNG.

That made it a good first project for learning the full process:

• ship an MVP
• deploy it publicly
• add Google login
• add usage credits
• add pricing
• connect payments
• prepare SEO
• submit to Google Search Console
• start distribution

For this first site, I cared more about completing the system than picking the perfect keyword.

The MVP Was Simple

The first version only needed to do one thing:

Upload an image, remove the background, and download the result.

I used an existing background removal API instead of building my own model.

That was a practical choice.

As a first-time builder, I did not want to get stuck building the hardest technical part before I even had a product online.

The lesson here was simple:

For a first MVP, speed matters more than technical pride.

Once the tool worked, I started seeing the real gap.

A demo can process an image.

A product needs accounts, limits, pricing, trust, and operations.

Adding Google Login Changed the Product

At first, the tool was just a page with an upload box.

Then I added Google sign-in.

That made the product feel more serious, but more importantly, it created the foundation for everything else:

• user accounts
• monthly credits
• usage history
• pricing plans
• subscriptions
• future product analytics

I used Cloudflare D1 to store users, login events, usage events, subscriptions, and payments.

One small design decision I like:

I do not store "remaining credits" directly.

Instead, I store the user's plan and usage events. The remaining credits are calculated from successful usage in the current month.

That feels safer because plans, payments, and monthly resets can change later.

A UX Mistake I Had to Fix

One mistake I made early:

Users could upload an image first, then get told they needed to sign in.

Technically, that was fine.

But as a user, it felt annoying.

If someone has already selected an image, they have already invested effort. Blocking them after that creates frustration.

So I changed the flow.

Now logged-out users see the sign-in requirement before uploading. Logged-in users see their plan, monthly limit, used credits, and remaining credits before they process an image.

This was one of the most useful product lessons from the project:

If a rule affects trust, show it before the user takes action.

Pricing Was Also Part of the Product

I added a simple pricing page:

• Free: 3 images / month
• Starter: $8.99 / month for 25 images
• Creator: $19.99 / month for 80 images

The rules are clear:

• 1 successful background removal uses 1 credit
• failed uploads do not use credits
• unsupported files do not use credits
• oversized files do not use credits
• monthly credits do not roll over
• there are no automatic overage charges

I wanted the pricing page to answer one basic question:

Will I be surprised later?

For small tools, trust is part of conversion.

Payments Are More Than a Button

I connected PayPal subscriptions.

At first, I thought this would mostly mean adding a checkout button.

It was more than that.

A real payment flow needs:

• subscription plans
• checkout creation
• webhook handling
• webhook verification
• database records
• user plan updates

The actual loop is:

User pays -> PayPal sends webhook -> database updates -> user gets the right plan

That was an important shift for me.

Payment integration is not finished when the button appears. It is finished when the user's access changes correctly after payment.

SEO and Analytics

After the product worked, I added the SEO basics:

• title and description
• canonical URLs
• robots.txt
• sitemap.xml
• JSON-LD structured data
• image alt text
• Google Search Console
• Google Analytics

This was not advanced SEO.

It was the minimum setup to help Google discover and understand the site.

I also learned not to panic when a tool reports an issue. For example, Google Search Console may say a sitemap cannot be fetched shortly after submission, even if the sitemap is actually accessible.

Now I try to verify the real URL first before changing code.

Early Distribution Was Slower Than I Expected

I prepared a Product Hunt draft, but I did not launch it immediately.

I also submitted the site to SaaSHub and Uneed.

That taught me another lesson:

Not every backlink platform gives fast exposure.

Some directories have long review queues. Uneed's free queue, for example, was far longer than I expected.

So I started separating distribution channels into two groups.

Long-term assets:

• Product Hunt draft
• SaaSHub
• Uneed
• directory listings

Faster publishing channels:

• Dev.to
• Hashnode
• Medium
• Indie Hackers
• selected Reddit communities
• X, after warming up the account

This article is part of that second group.

I want to share the build process, not just drop a link.

What I Learned

The biggest lesson is that building the tool is only part of the work.

For tool sites, I now think the most important parts are:

1. Finding real demand
2. Shipping fast
3. Making the product trustworthy
4. Preparing SEO early
5. Distributing consistently
6. Iterating based on signals

I can now build and launch a small tool site.

But I still need to get much better at demand discovery and site operation.

That is probably where most of the upside is.

What I Will Do Differently Next Time

For my next tool site, I want to spend more time before coding on:

• keyword research
• search intent
• competitor pages
• long-tail SEO pages
• monetization paths
• distribution channels
• whether the problem is urgent enough

I also want to build more SEO pages earlier, not just one homepage and one pricing page.

For example, a background remover could have pages for:

• product photos
• profile pictures
• ecommerce images
• transparent PNGs
• social media images

Each page should solve a specific search intent.

That is something I did not do enough in the first version.

Final Thoughts

This project is still early.

It may or may not become a meaningful business.

But it helped me move from "I want to build tool sites for global users" to "I shipped my first one and understand the loop much better."

The full path looks like this:

idea -> MVP -> login -> credits -> pricing -> payments -> SEO -> analytics -> distribution -> iteration

My next goal is to keep building more small tool sites, improve my demand discovery, and get better at turning useful tools into real USD revenue.

If you are also building small tools, I hope this post helps.

And if you try BG Remover, I would love feedback on the onboarding, pricing clarity, or anything that feels confusing.