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

Lily Lily — Mon, 10 Aug 2026 12:30:00 +0000

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:

Finding real demand
Shipping fast
Making the product trustworthy
Preparing SEO early
Distributing consistently
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.

DEV Community: Lily Lily