Firecrawl is one of our favorite products at Autumn. It is the context API for searching, scraping, and interacting with the web at scale. It's open source with over 175K GitHub stars, used heavily inside coding agents through their MCP server and CLI, and it bills billions of credits per month.
They're scaling incredibly quickly as agents have taken off. At peak they send Autumn more than 5,000 requests every second.
Before Autumn
Micah was a few weeks into a big billing rework because their existing engine was struggling to keep up.
Our in-house billing system had been around for a while and hadn't received enough attention. Its logic was scattered across the codebase, so complexity built up over time. The SQL function handling balances, expirations, and rollovers alone had grown to more than 800 lines.
Since billing problems usually ended up in a support ticket, most of the work fell on him and his team. When we first met, he was fairly blunt that he didn't think we were a fit. His view was that Autumn suited new companies that hadn't built a complicated billing system yet, and that migrating would cost more than finishing the refactor he'd already started.
However, after we chatted it was clear that billing was going to be an ongoing problem as they continued to scale. Pricing changes, new products, multi-team structures and spend control for enterprises were things we could provide out of the box, freeing up time for product work. Autumn forward-deployed an engineer to work with them for the migration, and after just a few weeks, they went live on April 1st.
Updating pricing every week
Between April and the end of August, Firecrawl updated their pricing 16 times. Micah described it as being able to run billing changes and experiments every week. Some of the most notable ones have been:
- Enabling many more tiers and credit packages to be bought, making expansion a smaller jump.
- Experimenting with one-off top-ups vs automatic upgrades as a mechanism for growing accounts.
- Figuring out the right price points for auto top-ups.
- Changing credits granted in lower tiered plans.
- Giving additional credits for putting down a payment method.
- Granting endpoint-specific credits to encourage use of new features.
- Adjusting pricing and adding rollovers to sales-led contracts.
This is possible because Autumn natively handles the logic to subscribe to plans, and upgrade / downgrade between them. New plan versions can be created, with customers grandfathered on old tiers. Pricing plans can be updated to change credit amounts or add new features without DB migrations.
The lift to run an experiment is reduced 10x. Through this process, the Firecrawl team learned a few things about what worked.
Smart upgrades vs. auto top-ups
Most credit products handle "I ran out" with a one time top up. The economics of it aren't ideal, because top ups are priced at a premium per credit, so the heaviest users end up paying the most per unit. For the company it's lumpy revenue that rarely converts into expanding subscription revenue.
Someone on Micah's team suggested doing it differently, and they built what they call "smart upgrades." When a user hits their ceiling, instead of selling them another pack, Firecrawl moves them to the next subscription tier and charges the prorated difference. Autumn sends the alert when credits run out, the upgrade is attempted, overage credits are allowed while the payment processes, and the new credits are granted once it clears.
After running this experiment for a few months, they actually returned to auto top-ups in August.
We have very different types of customers using Firecrawl. Some use it as part of their development workflow, connecting our MCP or CLI to their coding agent. For them, a small subscription often makes the most sense. Others use Firecrawl in production, where usage scales alongside their business. Smart Upgrade worked especially well for that group.
Smart upgrades solve a problem that only one of those cohorts has. For a developer running Firecrawl inside a coding agent, usage is roughly flat, and being nudged up a tier is a decision that ends in higher contraction.
So self-serve moved back to top-ups, and smart upgrades was kept for larger customers, where it's especially helpful in reducing procurement friction for fast-growing customers.
Promo credits, restricted to a single endpoint
Firecrawl wanted to encourage deeper adoption of their search endpoint by granting specific credits to customers that only worked for the search endpoint.
With Autumn, complex drawdown logic for credits is handled out of the box. All they had to do was create a standalone balance of search credits and grant it to customers.
Firecrawl just reports to Autumn that a search happened. Autumn checks the customer's balances, sees they have search-specific credits and draws from them first. If none remain, it automatically falls back to their default credit system that all endpoints draw from.
They run searches until the free credits are gone, then keep going on their normal balance. All the credits were granted with an expiration, so after a few months, everything is automatically cleaned up.
Where they are now
I warned them ahead of time how complicated our billing was, but the team has been incredible to work with. There's no way we'd be able to iterate as fast as we are without Autumn.
Micah's original objection was that migrating would cost more than finishing the refactor he'd already started. We're glad that he didn't give in to the sunk cost fallacy.
Since then, they've been using Autumn extensively. Firecrawl went from a billing system that required an increasing amount of effort to maintain to one where they ship pricing experiments confidently every week. We're proud to help them grow even faster.