By the fastCRW team · Pricing/features verified 2026-05-18 · fastCRW launch pricing expires 2026-06-01 · Verify independently before buying.
Disclosure: We build fastCRW. This is a vendor-authored piece, so weight it accordingly — but the whole argument is testable in one config line, and we name where the proxy giants genuinely beat us.
What actually locks you into a scraping vendor
Web scraping vendor lock-in is rarely a contract clause — it is an architecture you backed into. You picked a scraping API, wrote a pipeline against its exact request and response shape, and now the cost of leaving is a rewrite plus a re-test of every downstream parser. By the time the bill, the rate limits, or the roadmap stop working for you, the switching cost is high enough that you stay. That is lock-in: not that you cannot leave, but that leaving is expensive enough to feel impossible.
Proprietary request and response shapes
The deepest hook is the API surface itself. If your code is written against a vendor-specific endpoint shape, field names, and error envelopes, every call site is a dependency on that vendor. Moving to a competitor means remapping inputs, re-parsing outputs, and re-validating extraction schemas across your whole codebase. The more surface area you use, the more the proprietary shape costs to unwind.
Usage-based pricing that scales super-linearly
Per-credit metering looks cheap at prototype volume and turns punishing at production volume. Worse, some providers split extraction onto a separate token subscription, so an extraction-heavy pipeline pays twice. There is no cost ceiling: the bill grows with traffic, and you have no floor to fall back to when a billing change lands. Firecrawl's hosted scrapes run $0.83–5.33 per 1,000 across its tiers (`marketing/competitor-prices.lock.md`, verified 2026-05-18) — fine until volume makes the meter the dominant line item.
No self-host path when the bill or roadmap turns
A cloud-only API gives you no exit. If pricing changes, a free tier gets cut, or the vendor's roadmap drifts away from your needs, your only options are to absorb it or undertake a migration you have been avoiding precisely because it is expensive. With no engine you can run yourself, you are renting capability you can never own.
The two-part escape hatch
An escape hatch is not a feeling — it is two concrete architectural properties. First, a compatible API surface so leaving is a configuration change, not a rewrite. Second, an open-core engine you can self-host so the cloud is never the only place the capability lives. fastCRW is built around both.
API compatibility: leave with a base-URL swap
fastCRW exposes a Firecrawl-compatible REST surface — the same base shape, drop-in after a base-URL swap. The official Firecrawl SDK works against fastCRW by changing the API URL; the overlap surface (/v1/scrape, /v1/crawl, /v1/map, /v1/search) is implemented closely enough that the common pipeline does not change. Because the same shape is also the most widely supported one in the ecosystem, coding to it keeps your exit cheap toward more than one destination, not just toward us.
Self-host the same engine when the cloud no longer fits
The managed cloud and the self-hosted engine are the same code. When the bill, a residency requirement, or a roadmap decision makes the cloud the wrong fit, you run the open-core engine yourself instead of porting to a different product. Self-hosting the AGPL-3.0 engine is free — you pay only for your own server — which puts a hard floor under your worst-case cost: $0 per 1,000 scrapes self-hosted, versus a meter that only goes up.
Why AGPL-3.0 open-core guarantees the exit
The escape hatch only counts if nobody can take it away. fastCRW's engine is a single static Rust binary released under AGPL-3.0 with the source public at github.com/us/crw. You can fork it, patch it, and run it indefinitely regardless of what happens to the company behind it. A proprietary cloud API can deprecate an endpoint or raise a price; an AGPL-3.0 binary on your own disk cannot be revoked.
Lock-in in the wild
Lock-in is not hypothetical. The scraping category has spent the last year demonstrating exactly how cloud-only dependence bites.
Acquisition risk: when your vendor gets bought
ScrapingBee formally joined Oxylabs in January 2026, and Tavily was acquired by Nebius. When a tool you depend on is acquired, you inherit the acquirer's roadmap and pricing direction whether or not they match the reasons you chose the tool. If your only relationship with that capability is a cloud API key, you have no leverage and no exit — the deal is something that happens to you. We cover this in depth in ScrapingBee alternatives.
Free-tier rug-pulls and credit-burn surprises
One-time credit grants and shifting free tiers are a recurring source of surprise. A pipeline built on a generous free tier can break when that tier is cut, and super-linear metering turns a small traffic increase into a large bill. None of this is recoverable on a closed platform — you adapt to the new terms or you migrate. Owning the engine means a billing change at the cloud is an annoyance, not an outage.
Proxy-vendor lock-in vs engine ownership
There is a real distinction between depending on a proxy vendor and owning the scraping engine. Proxy depth and anti-bot are services you genuinely have to rent at hostile scale — and here the honest answer is that Oxylabs and Bright Data win, because fastCRW has no built-in residential proxy pool and no Fire-engine anti-bot. But the engine that orchestrates scraping, crawling, and extraction is something you can own outright. Conflating the two is how teams end up renting capability they could have controlled.
Designing for portability up front
The cheapest escape hatch is the one you build before you need it. A few decisions at integration time keep your migration cost near zero for the life of the pipeline.
Code against a compatible API surface
Write your client against the Firecrawl-compatible surface rather than any one vendor's proprietary extensions. That makes the backend a runtime configuration value instead of a hard dependency: the same code can point at a managed cloud, a self-hosted binary, or a competitor that speaks the same shape. The surface is the contract; the provider behind it is swappable.
Keep migration cost to base URL plus key
The target state is that switching providers means changing two things — the base URL and the API key. No code fork, no parser rewrite, no re-validation marathon. When migration is that cheap, the vendor has to keep earning your business on price and quality every month, which is exactly the relationship you want. See the mechanics in the Firecrawl SDK base-URL swap guide and the broader API compatibility breakdown.
Honest note: response envelopes diverge slightly
Compatibility is not byte-for-byte. fastCRW's response field names and error envelopes have minor divergence from Firecrawl, and a few cloud-only Firecrawl features have no fastCRW equivalent: no multi-URL batched /v1/extract, no /v1/agent, no /v1/deep-research, and no screenshot output (a request for formats: ["screenshot"] returns HTTP 422). Validate that short known list before cutover. It is compatible on the surface most pipelines use, not on every edge — and pretending otherwise would be the kind of overclaim this post is arguing against. Our migrate-from-Firecrawl guide walks the exact checklist.
When the escape hatch pays for itself
Portability is insurance, and like any insurance it pays out under specific conditions. Two stand out.
Cost crossover at volume
At low volume, a metered cloud is convenient and the meter is cheap. As traffic grows, the meter becomes the dominant cost and self-hosting the same engine — $0 per 1,000 scrapes plus your server — crosses below it. Because both run identical code, you do not have to predict the crossover in advance: you watch the bill and flip the backend when the math turns, with no rewrite at the crossover point. The free tier (500 one-time lifetime credits) lets you prove the path before committing. Run the live numbers on /pricing.
Privacy and roadmap independence
The other payout is control. In self-host mode, scraped content and target URLs never leave your infrastructure — a hard requirement for regulated workloads, not a preference. And because you own an AGPL-3.0 binary, your roadmap is decoupled from any acquisition, pricing change, or strategic pivot at the vendor. The deciding factor for many teams is not today's price but the question of who controls the capability next year. For the full self-host-versus-managed trade-off, see self-host vs managed scraping.
Where the proxy giants genuinely win
An escape hatch does not make fastCRW the right tool for every job. For hostile, hardened, anti-bot-heavy targets at scale, Oxylabs and Bright Data are the honest answer: their residential proxy depth and managed anti-bot are real capabilities fastCRW does not ship. If your workload is dominated by hardened targets, rent that depth — and keep the rest of your pipeline on a portable surface so the proxy decision stays separate from the engine decision. Owning the engine and renting proxies where you must is a stronger position than renting both from one vendor.
Sources
- Firecrawl hosted cost ($0.83–5.33 per 1,000 scrapes): `marketing/competitor-prices.lock.md` (verified 2026-05-18)
- ScrapingBee → Oxylabs (formally joined Jan 2026): `marketing/competitor-profiling.md` §line 169. Tavily → Nebius (Feb 2026): `marketing/competitors.md` §line 132 / `marketing/STRATEGY.md` §line 90
- fastCRW repo and pricing: github.com/us/crw · fastcrw.com
Related: Migrate from Firecrawl · Firecrawl API compatibility · Self-host vs managed scraping · ScrapingBee alternatives