Francesco Formisano for DokeLab

Posted on Oct 29

I Made My First $0.38 With an Apify Actor — Here’s What I Learned

#buildinpublic #api #automation #startup

A few weeks ago, I published my first paid Apify Actor.

A few days later, someone I had never spoken to found it, ran it, and paid for it.

Revenue: $0.38.

Obviously, $0.38 isn't a business.

But seeing the first real customer use something I had built was much more valuable than the number itself.

It meant one thing:

someone had a problem, found my tool, and decided it was worth paying for.

Here's what I learned from building and launching my first paid Actor.

The product

The Actor is called Google Keyword Search Volume & CPC Checker.

The idea is intentionally simple.

You provide a list of keywords and get structured metrics such as:

search volume
CPC
Google Ads competition
competition index
bid estimates
monthly search trends

The Actor supports up to 1,000 keywords per run.

Behind the scenes, the data comes from DataForSEO.

But the user doesn't need to:

create a DataForSEO account
manage API credentials
fund a separate API balance
understand the provider endpoint
implement retries or batching
normalize the response

The workflow is basically:

keywords in → metrics out

That simplicity was deliberate.

The interesting part wasn't the API

Calling the upstream API was probably the easiest part of the project.

The harder questions were around economics.

Every fresh data request costs me money.

So what happens if:

a customer requests 1,000 keywords?
some results are already cached?
the upstream provider returns no useful data?
a request fails halfway through?
Apify billing fails after results have already been delivered?
the same data is requested repeatedly?

Once money is involved, a simple API wrapper becomes a much more interesting engineering problem.

I added two billing events

The Actor uses Apify's Pay Per Event model.

There are two main events.

Keyword result

A useful keyword result delivered to the customer.

Fresh data lookup

A fresh request that requires calling the upstream provider.

This lets cached results and fresh provider requests have different economics.

The idea is simple:

if I have to pay the upstream provider, the pricing model should account for that.

Caching became a product feature

Originally I thought of caching mostly as an infrastructure optimization.

It quickly became part of the product.

If a keyword has already been requested recently for the same location and language, the Actor can reuse the result.

That means:

fewer upstream API calls
faster repeated runs
lower infrastructure risk
more predictable economics

Every result also exposes whether it came from cache.

So instead of caching being invisible infrastructure, it becomes transparent behavior.

Then the first customer arrived

A few days after publishing, Apify showed:

1 paying user
$0.38 revenue
successful runs
real upstream API usage

It was a very small transaction.

But it was also the first time someone outside my own testing environment had gone through the entire flow:

discover → open Actor → run → receive data → pay

That was the first real validation.

The first customer also exposed the real problem

My first assumption was that I would spend most of my time improving the Actor.

More features.

More metrics.

More integrations.

But the analytics told a different story.

At the time of writing, the acquisition funnel is roughly:

26 people viewed the Actor page
3 opened the input page
2 started the Actor
1 became a paying user

The sample is tiny, so drawing strong conclusions would be silly.

But one thing is obvious:

the biggest problem right now isn't infrastructure. It's distribution.

The Actor works.

The billing works.

The provider integration works.

The challenge is getting enough relevant people to discover it.

So I stopped adding features

This was probably the most useful decision.

Instead of immediately building more functionality, I started improving discoverability.

I changed the public name from a product-style name to something people might actually search for:

Google Keyword Search Volume & CPC Checker

I also created several public example tasks targeting different use cases:

bulk keyword search volume
Google Ads CPC and competition
SEO keyword metrics
keyword volume without a Google Ads account
bulk keyword data for AI workflows

Each one represents a slightly different search intent.

I also started publishing what I'm learning

This article is part of that experiment.

Instead of only building products, I'm starting to document:

how I'm designing API economics
how I'm pricing usage-based tools
what actually happens after publishing
what acquisition channels work
what doesn't work
whether a small portfolio of API tools can become meaningful revenue

I'm calling this experiment Building DokeLab in Public.

The interesting part for me isn't pretending the business is already successful.

It's documenting what happens while it's still small enough that every customer and every mistake is visible.

What $0.38 actually taught me

The first sale didn't prove that the product will succeed.

But it did answer an important question.

Before the first customer:

Would anyone actually pay for this?

After the first customer:

How do I find more people with the same problem?

That's a much better problem to have.

What's next

For now I'm focusing on three things:

improving organic discovery
understanding which acquisition channels bring qualified users
resisting the temptation to add features before there's evidence they're needed

If traffic increases but conversions don't, I'll work on the product page and onboarding.

If traffic doesn't increase, I'll work on distribution.

And if people start repeatedly using the Actor, then it becomes worth expanding the product.

Small experiments first.

The Actor

If you're curious about the product behind this experiment, you can find it here: