From Internal Tool to Paid Product: Pricing a Data API From Real Costs

For months, my crawling service was an internal tool. It fed product data to my own websites and nothing else. Then I realized the thing I was paying a vendor for before had become something I could sell, at a lower price, with numbers I could defend. This post is about that step: from internal tool to product, and how I priced it.

Start with the cost you have actually measured

The temptation with pricing is to look at competitors and pick a number slightly below theirs. I did look. A well-known scraping vendor charges around US$50 for 5,000 requests, or about US$10 per 1,000. But a price based only on competitors tells you nothing about whether you make money.

So I started from my own logs. Over one measured window of 14,190 requests, the success rate on my main proxy route was about 88%, and data transfer was around 3 GB. At the bandwidth price I pay, that came to roughly US$0.24 per 1,000 successful pages. A heavier product page, at around 480 KB, costs me roughly 12 Vietnamese dong to fetch. That is a fraction of a US cent.

That number is the floor. Everything else is built on top of it: server time, failures, support, and margin.

Decide what a request is

Customers should not pay for my failures. In the DatPilot Data API:

• a request that returns valid data consumes one credit
• a request that fails on my side, because of a block, a timeout, or a parsing error, refunds its credit

This changes my incentives in a good way. Every failed request costs me, so I care about pass rates as much as the customer does.

Prepaid packages, not subscriptions

My first customers are small Vietnamese businesses and developers. Many of them dislike recurring billing and prefer to top up a balance, the way they pay for phone credit. So the API uses prepaid packages:

Package	Requests	Price (VND)
Starter (Khởi đầu)	2,000	149,000
Personal (Cá nhân)	10,000	590,000
Team (Đội nhóm)	50,000	2,490,000
Business (Doanh nghiệp)	200,000	7,900,000

Credits never expire. The price per request drops with volume, and even the smallest package works out well below the vendor price I used to pay. These are first prices, not final ones. I will adjust them once I have real usage from real customers.

Run it on separate infrastructure

The paid API runs on its own crawler instance with its own database, using the same code as my internal service. That separation matters:

• a heavy customer cannot slow down my own research pipelines
• usage records for billing are clean and isolated
• I can deploy and restart the customer-facing side without touching internal jobs

Free credits, without inviting abuse

Developers want to try an API before paying. Free credits are the obvious answer, and also the obvious target for abuse: one person, a hundred email addresses, a hundred free trials.

My approach:

• Credits are earned by completing small tasks, like creating a first API key, making a first call, or completing a profile, instead of being handed out in one lump. The total is capped per person.
• Duplicate detection. Accounts that share a device, email, or phone number cannot claim the same rewards twice. Weaker signals, like a shared IP address, only reduce the limit rather than blocking, because offices and mobile networks share IPs legitimately.
• Sign-up protection. A hidden honeypot field, a minimum time to fill the form, rate limits per IP, and a block on disposable email domains.

None of these are perfect alone. Together they make farming free credits more trouble than paying for a small package.

Write the customer-facing text carefully

Two rules for everything a customer sees:

1. No vendor names. The product page, docs, and error messages describe what the API does, not which upstream services it uses. That is an implementation detail, and it can change.
2. Errors in plain language. A customer gets “the page could not be fetched, your credit has been refunded”, not an internal stack trace or a proxy status code.

What I would tell another founder

• Price from your measured cost upward, then sanity-check against competitors.
• Refund your own failures. It builds trust and forces you to fix reliability.
• Separate customer infrastructure from internal infrastructure on day one.
• Design free tiers for abuse before you launch them, not after.
• Treat first prices as an experiment. Write down what would make you change them.

The DatPilot Data API is live for Vietnamese customers at app.datpilot.com. It started as a fix for my own problem. That is my favorite way for a product to start, because the first customer was me, and I already knew exactly what it needed to do.