1
1 Comment

I charge $5 per 1,000 results. My niche Apify Actor tripled its revenue in month two

I charge roughly $5 per 1,000 results for a very narrow product: an Apify Actor that turns public LoopNet and Crexi listings into one structured commercial real estate dataset.

It is not a huge SaaS business. It is not a generic AI wrapper. And I still cannot attribute every dollar to a marketing channel.

But the first two complete revenue months surprised me:

The numbers

May 2026

  • Revenue: $55.82
  • Platform costs: $17.60
  • Profit: $38.22
  • Margin: 68.47%

June 2026

  • Revenue: $177.98
  • Platform costs: $10.82
  • Profit: $167.16
  • Margin: 93.92%

Revenue increased by 3.19x in month two.

Here is what I think made the product useful, what I still do not know, and why I am now paying much more attention to attribution.

The product is deliberately narrow

Commercial real estate brokers and analysts often search LoopNet and Crexi separately, then move the useful rows into a spreadsheet or another internal workflow.

The scraping itself is only one part of that job.

The user still needs to normalize fields, preserve the original listing URLs, compare records from two sources, identify possible duplicates, and export the result in a format that is actually usable.

That is the job my Actor is designed to handle.

A user provides supported LoopNet or Crexi search URLs. The Actor collects the public listing data and returns a structured dataset that can be exported to CSV, Excel, JSON, or consumed through the API.

It is intended for public, on-market listing research. It does not claim to provide closed-sale comps or replace a full commercial real estate data platform.

That narrow boundary has helped me explain the product more clearly.

Why charge per result?

The pricing is simple:

  • $0.05 to start a run
  • $0.005 per dataset result
  • approximately $5 for 1,000 results

I wanted the price to follow the amount of usable data returned, rather than asking a new user to understand crawler runtime, memory consumption, or internal request counts.

Usage-based pricing also creates an engineering constraint: a result needs to be useful enough to justify the event being charged.

Returning 1,000 inconsistent rows quickly is not the product. Returning a dataset that is easier to inspect, filter, and move into the next workflow is the product.

The technical work was mostly about trust

The crawler is important, but much of the product work happens after a page is fetched.

The Actor has to:

  • recognize supported LoopNet and Crexi URL patterns and reject unsupported routes instead of pretending they worked;
  • map two different source structures into a consistent output;
  • preserve source URLs and source-specific context;
  • expose duplicate signals without silently merging records that may represent different listings;
  • handle missing fields without inventing values;
  • stop cleanly when a source naturally returns fewer results than requested.

These choices are less exciting than saying “I built a scraper,” but they are closer to the reason someone can use the output.

One lesson from this project is that a niche data product is judged less by the number of pages it can crawl than by the number of manual decisions it safely removes after the crawl.

I cannot fully explain the 3.19x growth

I can see referrer traffic in Apify Insights, but I cannot yet connect every referrer to a specific paid run or dollar of revenue.

For July so far, the visible referrer mix for this Actor is approximately:

  • 38% unknown or unattributed
  • 27% Google
  • 24% from Apify surfaces combined
  • 4% Indie Hackers
  • the remainder from smaller sources

That tells me Indie Hackers has sent traffic. It does not prove that an Indie Hackers visitor became a paying user.

The 38% unknown share is the uncomfortable part. I know the product is being discovered, but I do not know enough about how.

So the honest explanation for the revenue increase is not “I found one perfect growth channel.”

It is that usage increased while my attribution remained incomplete.

What I would do earlier next time

1. Instrument acquisition before revenue becomes interesting

At $0 revenue, attribution feels optional. Once revenue starts moving, historical gaps are difficult to reconstruct.

2. Show the output before listing the features

For this kind of product, a sample dataset communicates the value faster than a long crawler feature list.

3. Keep the promise narrower than the technology

“Scrape commercial real estate” is broad and difficult to trust.

“Turn supported LoopNet and Crexi searches into a structured public-listing dataset” is a smaller and more testable promise.

4. Treat unknown traffic as a research problem

An unknown source is not a channel. It is missing information. I now need better ways to connect discovery, Actor starts, repeat usage, and revenue without adding unnecessary friction for users.

Where the product is now

The Actor is live here:

https://apify.com/kazkn/commercial-real-estate-brokerage-intel?fpr=8fp2od

I am continuing to improve the data workflow and the documentation, but the more interesting business question for me now is attribution.

For builders selling through a marketplace: what did you instrument first to connect an article or referrer to actual paid usage?

I am especially interested in approaches that work when the marketplace owns most of the checkout and product experience.

on July 14, 2026
  1. 1

    One extra data point I deliberately left out of the headline: from July 1 to July 14, the Actor generated $131.94 in revenue, with $5.83 in platform costs and $126.11 in profit.

    I am not calling that another growth month because July is incomplete and the figures can still change.

    My next experiment is better attribution. If you sell through a marketplace, do you rely on first-touch attribution, last-touch attribution, referral parameters, or simply ask users how they found you?

    I would love to hear what has produced information you could actually act on.