How We Think About Pricing Compute for a Scraping Tool

We Threw Out the Per-Seat Playbook

Per-seat pricing is a lie when the cost is compute.

When we started pricing Trawl, the default SaaS playbook handed us a tidy answer: charge per seat, tier by features, ship it. We threw it out. Scraping isn't a seat problem. It's a compute problem. And once you actually internalize that, per-seat stops looking like the safe default and starts looking like the dishonest one.

The bill should tell the truth about what you used. For a scraping tool, that truth is compute, not headcount.

This is the story of how we landed on usage-based credits, and why I think it's the only model that doesn't lie to your customers about what a scraping tool actually costs.

What You'll Learn

• The thing per-seat pricing gets wrong
• Proxies are the clearest proof
• Not all operations are equal
• Why this lets us give a real free trial
• Transparency is a feature, not a footnote
• What we'd tell another builder
• Key Takeaways
• FAQ

The thing per-seat pricing gets wrong

A seat-based price assumes your cost scales with people. For most tools, that's roughly fine. Another login is another row in a database.

But a headless scraping platform doesn't work like that. The people who log in are almost irrelevant to what it costs us to serve them. What costs money is the work a run does:

• Browser and CPU compute time. A real headless browser, rendering a real page, running real JavaScript, is the dominant cost of any non-trivial scrape.
• Proxy bandwidth. Every byte that moves through a proxy has a price, and that price is anything but uniform (more on that below).
• AI fix and extraction calls. When a page breaks a scraper and the system repairs it, or when it pulls structured data out of the mess, that's an AI call with a real per-call cost.

None of that scales with headcount. A solo founder running ten thousand hard scrapes costs us far more than a fifty-person team that logs in to glance at a dashboard once a week. Per-seat pricing would bill the team a fortune and the founder almost nothing, which is exactly backwards from the cost we actually incur.

Flat pricing looks neutral. It isn't. It quietly taxes light users to subsidize heavy ones, and pretends a cost driver exists where it doesn't.

So we metered on the cost driver itself.

Proxies are the clearest proof

Want one concrete reason flat pricing can't work for scraping? Look at proxies.

Proxy tiers don't cost a little more as you climb. They cost dramatically more. The cheap tiers are a fraction of the expensive ones. And here's the part that breaks any flat model: a "hard" site forces a pricier tier. Sites with aggressive anti-bot defenses simply won't yield to the cheapest path, so a run against a hard target burns a fundamentally more expensive resource than the same run against an easy one. If you want the deeper version of why some targets are so much harder, we wrote about scraping without getting blocked: proxies, stealth and CAPTCHAs.

So the cheapest and most expensive paths to a successful scrape are nowhere near the same price. A single flat number has only two options: overcharge everyone scraping easy public pages, or quietly bleed money on everyone scraping the hard ones. There is no flat number that's fair to both.

Usage-based credits let the price follow the resource. Easy run, small cost. Hard run, more. Nobody subsidizing anybody.

Not all operations are equal

The same logic climbs one level up, to the operations themselves. A plain scrape is the cheap case. An AI-assisted fix that repairs a broken extraction, or AI content generation, is materially more expensive to run. So it carries more credit weight.

We meter on operation type, not on a single undifferentiated "request" count. A "request" that triggers an AI repair and a "request" that pulls a static page are not the same unit of work, and charging them as if they were would be its own little lie. (Curious how those repairs actually work? Here's why self-healing scrapers beat retry logic.)

This is the principle we actually designed against. What we meter on, and what we refuse to:

The left column is what costs us money to deliver. The right column is what per-seat and feature-gated models charge for. The bill should track the left column, because that's the column that tracks the value you actually got.

Want to put this to the test on your own targets? Try Trawl free and watch the meter follow the work, not your org chart.

Why this lets us give a real free trial

Here's the part that surprised me most: pricing on compute didn't just make the paid plans fairer. It unlocked a better free experience.

Feature-gated freemium means "free" is a deliberately crippled version of your product. You hide the good parts behind a wall and hope frustration converts. We didn't want to ship a worse Trawl to the exact people deciding whether to trust us.

Because we meter compute, we could do something simpler and more honest: give new users a real, bounded grant of actual compute. Not a fake tier. The full product, with a one-shot allowance of real runs against real sites. You get to use the thing you're evaluating, on your own targets, before you pay a cent.

This is our positioning, not a universal law. But letting people use the real product earns more trust than a perpetually crippled freemium, and honestly, it's just a nicer thing to do.

The grant is one-shot. It doesn't auto-renew. That's deliberate. It keeps our cost-per-signup bounded and predictable, so we can offer a genuinely useful trial without it turning into an unlimited free-compute faucet. The math only works because the trial is finite and known. That's the trade that lets us give away the real product instead of a demo of it.

Transparency is a feature, not a footnote

Usage-based pricing comes with a debt: if you bill by consumption, the customer has to be able to see their consumption.

Silent exhaustion, running out of credits mid-task with no warning, is a failure. We treat it as one. The product surfaces when credits run low, clearly, with the upgrade path right there. You should never hit a wall you didn't see coming. "Your balance is getting low, here's how to top up" is part of the product, not fine print buried in an invoice.

That's also why the model splits cleanly into plans plus top-up packs. Predictable users subscribe to a plan sized to their normal volume. Bursty users, the ones with a big one-off extraction job, buy a top-up pack and keep moving. Nobody should have to jump a tier, and pay for features they don't need, just because they had a heavy week.

You're buying capacity, not seats. And capacity is something you can buy more of without renegotiating your whole relationship with the product.

What we'd tell another builder

If you're pricing anything where the cost lives in the work and not the headcount, scraping, rendering, inference, any compute-heavy job, meter on the cost driver.

It's more honest. It aligns your incentives with your customer's: we don't profit from idle seats, and we don't bleed on power users. And it frees you to give away a real trial instead of a hobbled one.

None of this is novel. Usage-based and credit pricing has become common across infrastructure-shaped products and scraping tools for exactly these reasons. We didn't invent the shape. We just refused to do it halfway.

The bill should tell the truth about what you used. For a scraping tool, that truth is compute.

Key Takeaways

1. Scraping cost is compute, not seats. Browser time, proxy bandwidth, and AI calls drive cost; headcount doesn't.
2. Flat pricing is dishonest here because it taxes light users to subsidize heavy ones; harder targets force pricier proxy tiers that cost far more than the cheap ones.
3. Operation type matters: an AI-assisted fix is weighted more than a plain scrape because it costs more to run.
4. Metering compute unlocks a real free trial: a bounded, one-shot grant of the actual product beats crippled freemium every time.
5. Transparency is mandatory: visible balances and a clear upgrade path, never silent exhaustion.
6. Plans plus top-up packs equal capacity, not tiers: bursty users buy more capacity without jumping a feature tier.

If you want pricing that tracks the work instead of the org chart, Trawl is built that way from the meter up: usage-based credits, a real one-shot trial, and a balance you can always see.

FAQ

Why credits instead of seats?

Because for a scraping tool, cost scales with the work a run does, browser compute, proxy tier, AI calls, not with how many people log in. Credits make the bill track the real cost driver, so light users aren't subsidizing heavy ones.

Does the free grant renew?

No. The free grant is one-shot and doesn't auto-renew. It's a bounded allowance of real compute so you can evaluate the full product on your own targets before paying, kept finite on purpose so we can offer it sustainably.

What happens when I run out of credits?

The product is designed to warn you as your balance gets low, with an upgrade path right there, so exhaustion isn't a silent surprise. When you do run out, you can either move to a plan sized to your volume or buy a top-up pack to keep going.

Do I have to upgrade my whole plan just for a busy week?

No. That's why the model splits into plans plus top-up packs. Predictable usage fits a plan; a one-off heavy job is a top-up pack. You buy more capacity without jumping a feature tier.

Why does a "hard" site cost more than an easy one?

Sites with aggressive anti-bot defenses won't yield to the cheapest proxy tier, so reaching them consumes a fundamentally more expensive resource. Usage-based credits let the price follow that resource instead of averaging it into a flat fee everyone pays.

Is an AI fix charged the same as a plain scrape?

No. A plain scrape is the cheap case; an AI-assisted fix or AI generation is materially more expensive to run, so it carries more credit weight. We meter on operation type rather than a single undifferentiated request count.

Why not just offer one simple flat price?

Because the cheapest and most expensive paths to a successful scrape are nowhere near the same cost. A single flat price has to overcharge easy public-page scraping or lose money on hard targets. There's no flat number that's fair to both.

Does usage-based pricing make my bill unpredictable?

It's designed to stay predictable. Subscribe to a plan sized to your normal volume, watch a visible balance, and add a top-up pack only when you have an unusually heavy job. You buy capacity, and capacity is something you can plan around.

Disclaimer: You are responsible for ensuring your use of Trawl complies with applicable law and the terms of service of any site you target. Trawl is an orchestration layer for scraping public data; how you use it, including what you scrape and whether you have the right to, is your responsibility. Scrape public data only, and respect site ToS and robots directives.

Written by Pierre | June 2026