Mercor is on the Forbes AI 50, for the second year in a row. It is an annual list of the leading private AI companies, produced with Sequoia and Meritech. We went from $0 to $500M run rate in 17 months, crossed $1B in annualized revenue run rate earlier this year, and we pay out over $2 million every day to more than 30,000 weekly active contractors across the world.

Growth like this is a privilege and a stress test. Moving from $200K to over $14M a week on the platform in a short timeframe exposed every place where our early-stage processes, data models, and controls hadn't kept up with our scale. Some of those gaps we closed on our own terms. Some of them we closed after they bit us. We’ll talk about both kinds of lessons.

The job from here is to build through the next 50x. This is more than just an engineering challenge; it is fundamentally a human one: there are not many engineers in the world who have built systems that move billions safely at this kind of growth rate, and we need more of them. What follows is the record of what we've built and where we're heading.

What Mercor's Payments System actually does

Mercor is a two-sided marketplace at the forefront of AI; we bill leading AI labs and enterprise clients for access to the best global talent, and we pay independent contractors everywhere for their expertise and work.

Our payments infrastructure has to do two things, simultaneously: invoice clients across multiple, complex billing structures and contractual terms while paying out thousands of experts across dozens of countries and currencies. We have to get this right, all the time, every time. Each of those transactions touches a chain of systems that all have to agree: contracts, work tracking, billing logic, payout orchestration, ledgering, and reconciliation. When any layer in that chain disagrees, someone doesn't get paid. At $2M a day, it's a very real existential and reputational risk to the entire company.

It's worth pausing on what "someone doesn't get paid" actually means. These aren't anonymous transactions. They're a software engineer in Atlanta who depends on Wednesday's payout to cover rent. A contractor in São Paulo who has no visibility into why their earnings haven't cleared. If we fail a payment, we're deeply affecting someone's livelihood. That weight is something the payments team at Mercor carries deliberately, and it's a big part of why we treat reliability, auditability, and transparency as first-class obligations rather than as things we'll get to later.

The team building this sits at an unusual intersection in the company: the breakneck pace, intensity, and ownership culture of a hyper-growth AI startup, with the transaction volume, "always correct," and compliance responsibilities of a scaled fintech. Those two cultures don't naturally coexist, and building a team that holds both is part of the work. Our payments and financial infrastructure group brings experience from Scale AI, Google, Airbnb, Robinhood, Two Sigma, Doordash, and Amazon: people who have built and scaled financial systems through exponential growth before. They are people who joined Mercor precisely because the problems here are hard in interesting ways, and because getting them right matters.

Five things we learned building payments at speed

1. A ledger is a first-class primitive, not a side effect

When you're moving fast, it's tempting to treat your ledger as a byproduct of your service: a table that simply records what happened. That framing creates a ceiling you don't notice until you're already past it.

A proper ledger must be a resilient, independently searchable source of truth, and natively integrated across your end-to-end operations. When it isn’t – when billing logic, payout state and revenue recognition are all entangled in a single mutable data structure, the system works fine at low volume and starts to actively resist you at scale. Changes become high-risk. Debugging requires holding the whole system in your head. Finance can't close cleanly at period end.

The architectural shift we're making at Mercor is a move from mutable, monolithic payment records to an immutable, append-only ledger: every financial event is written once and never updated, with a canonical state machine (accrued → approved → payable → paid → reversed) that makes the current state of any payment, readable and reconcilable at any point in time. This is the foundation for accurate revenue recognition, clean ERP integration, and the kind of auditability that a Series C company with our transaction volume requires.

The ledger also connects downstream to every system that needs to read financial state: revenue reporting, data analytics treasury forecasting, expert earnings visibility, and the audit trail. Building it right means all of those systems get reliable data without each team maintaining their own bespoke view of financial truth.

2. Manual processes are risk surface, not just tech debt

Early-stage teams make a rational bet when they operate something manually: it's faster to ship, and automation can come later. That bet has a time limit, and the clock moves way faster than you expect.

What makes it insidious is what happens in the intervening period. Engineers build on top of the manual process, designing around it rather than replacing it. Operations start treating it as normal. Workarounds accumulate. Runbooks get longer. New engineers onboard and inherit the process as if it were intentional.

One of the most instructive examples is payout dispatch. Weekly payout dispatch started as a reasonable script that one engineer could run in a few minutes. Over time it grew into a multi-hour orchestration involving manual SQL validation, cross-referencing forecasting numbers across multiple payment providers, treasury balance confirmation, and a group sign-off ritual before anything moved. At millions of dollars a week, the process was absorbing 10+ engineering hours per week - time that could be spent scaling and automating systems. Correctness depended entirely on the specific person running it and the conditions under which they ran it. Nobody intentionally designed it that way. It just happened.

The solution isn't just to automate for efficiency's sake, but to make the system's behavior deterministic. This is the goal of the fully automated payout dispatch system we're shipping. Zero human operational oversight required for the weekly cycle, knowing exactly who, when, and how much to pay, with intelligent monitoring and alerting that surfaces anomalies proactively rather than relying on human spot-checks.

Every manual step is a potential failure mode, and the longed you wait, the more it costs. Every month a manual process runs in production, another layer of complexity grows on top of it. The time to replace it is always earlier than it feels. The sooner you treat manual processes as temporary scaffolding rather than permanent infrastructure, the sooner you can build the safety systems that let you move faster, not slower.

3. Automation requires canonical data

A critical, yet often underestimated, principle in payments engineering is this: automation doesn't lower risk if the underlying data is unreliable; it merely amplifies existing risks. A manual process running on unreliable data might generate a few errors weekly, but an automated one will produce thousands.

At Mercor, task-based payments proceed through a complex series of systems: contracts, work tracking, ingestion, pricing, ledgering, and invoicing. This process only functions smoothly if the output from each stage is understood by the next. Our core challenge stemmed from that fact that upstream data sources were never designed to be financially authoritative. Task statuses were vague, transitions were non-deterministic, and some crucial data resided completely off-platform.

This data deficiency can manifest in two ways:

• Inaccurate Bonus Payouts: When a contractor completes a task, the project lead records completion in a manual, off-platform spreadsheet and must manually issue the corresponding bonus. This can lead to forgotten bonuses or mistyped amounts. Crucially, the source of truth for a contractor's earnings becomes a hand-edited cell in a spreadsheet.
• Inefficient Invoicing and Reporting: Before every billing cycle, our accounting team spends a significant time manually verifying payment amounts by cross-referencing disparate upstream tables. This data might be scattered across different tools and data sources. The necessary solution is to establish a single, canonical definition of "task complete" that every tool adheres to and every downstream system trusts.

We treat upstream data architecture as a first-class citizen of our payments infrastructure, rather than agnostic input. This requires establishing and enforcing strict, canonical work completion signals across the platform: deterministic triggers that every tool must adhere to and every downstream system can trust without manual validation. From there, the end-to-end chain of work tracking, ingestion, pricing, ledgering, and invoicing runs seamlessly and automatically.

4. Observability investment compounds early

One of the best decisions the team made early was to invest in continuous monitoring, alerting, and payments tracking.

Real-time payout status, unified earnings views, and forward payment forecasting aren't the most glamorous infrastructure work (and most of the company doesn't know it's there unless it breaks), but they have a measurable impact on the thing that matters most in a payments system: trust. Experts depend on Mercor to provide reliable cashflow and want to make sure they get paid for their hard work. We invested early in automated forecasting and reliable payment status data, and surfaced this to our experts via a redesigned Earnings dashboard. Today, Earnings is the third most visited page on the Mercor Work Platform. Since launching these features, payout-related support tickets have dropped significantly.

On the operational side, we built centralized monitoring across our payment providers, tracking payout success rates, provider-specific failure modes, treasury balances, and reconciliation gaps, with structured alerting that catches anomalies before they become incidents. When something goes wrong, the team can trace it in minutes rather than hours.

Building observability into the system early and treating it as core infrastructure rather than a nice-to-have is what gave the team the feedback loops needed to move faster as complexity grew.

5. Controls aren't a compliance checkbox. They're load-bearing infrastructure.

At Mercor, we're building toward a world where many of our operations can run autonomously, where agents can operate projects, dispatch payouts, generate invoices, and close the books.

This comes at a tradeoff. Manual processes have one advantage: a human in the loop. The operator entering a discretionary bonus catches a typo before it ships. The engineer running the weekly payment dispatch can notice if the numbers look off. When you automate, these human controls go away, so the controls that replace them have to be well-designed, because there's no one left to catch what the system misses.

We've invested in applying agentic controls across our billing orchestration. We implemented a two-phase commit pattern across payment-triggering actions: every action first creates a pending record with a complete audit event, including the agentic initiator, amount, billing account, reason, timestamp. The audit trail is written before money moves, never as a side effect after.

On top of that, we built a threshold-based approval routing engine: configurable spend limits with automatic escalation requiring approval above defined thresholds. Large payments get flagged proactively and require explicit sign-off before they execute. We also invested in an aggregation service that monitors total spend and bonus activity across the platform in real time, so the system itself knows when something is trending toward an outlier before anyone has to ask.

The most effective controls are structural ones. By creating a system where it is architecturally impossible to issue a payment without a threshold check or an audit record, we enable automation to scale safely. Because proactive safeguards are built directly into the core platform, agentic functions can manage tasks like orchestration, dispatch, and bonus approvals while remaining strictly governed.

What we've shipped

Since October, the team has shipped:

• Automated treasury forecasting: Automated forecasting of our float eliminated overdraft risk and shifted treasury operations away from engineering, establishing a clean separation between financial operations and product development.
• Expert earnings visibility: Real-time payout status, unified earnings views, and forward payment projections, now the third most visited page on the Work Platform, with a measurable reduction in "where is my money" support tickets.
• Billing canonicalization: Billing Accounts introduced as the primary financial primitive, linking projects and contracts to financials and establishing Finance as the owner of revenue recognition.
• Centralized observability: Real-time KPI dashboards, structured alerting across payout providers, and incident runbooks that have significantly reduced production incidents and mean time to resolution.
• 100% bonus auditability: Immutable audit records on all on-platform bonus activity. Every payment now carries initiator attribution, billing account, reason code, and a complete approval history. Two-phase commit architecture ensures the audit trail is written before money moves, not after.
• Time agnostic billing: Migrated billable data to UTC, eliminating a class of timezone-related billing errors that had real cost implications at scale.

These represent a shift from a payments system that was outrunning its infrastructure to one with the controls, visibility, and data quality needed to scale further.

What we're building

The foundation is almost in place. The next phase is where it gets interesting.

Correctness as a primitive: Shipping ledger-backed payouts, where all money movement is written and executed from a universal, immutable, append-only ledger with absolute correctness. That means zero double payouts and a payout failure rate below 0.01%.

Canonical payment state machines: Decomposing the current tightly coupled orchestration into a state-based billing model that cleanly separates what is owed from how money moves. This is the unlock for faster development, safer launches, and future capabilities including multi-instrument wallets, accruals, and dynamic pricing.

Completely autonomous payout dispatch: Fully automated weekly payout execution with zero human operational oversight required. The target is 95%+ of payouts executed at or ahead of SLA, with zero orchestration regressions.

Human data tasks as a native billing construct: Native task-based payouts and invoicing based on canonical task completion signals, targeting automation of 90% of task-based payment activity.

Budgets and approvals: Threshold-based approval routing for all non-billable spend, with configurable per-expert and per-account thresholds, automated escalation tiers, pattern-based fraud detection, and real-time spend dashboards for Finance and account owners.

Plug-and-play and self-service: Shifting payment operations away from a reactive model by enabling Finance, Ops teams and AI agents to proactively manage payouts, fixups, and disputes through self-service tooling with end-to-end audit trails and role-based permissions.

The scale is already exceptional. The engineering to match it is what comes next.

Come build with us

Mercor is growing faster than most companies ever will, and the payments system is where a lot of that growth has to be absorbed. Some of what we've built, we built because we saw it coming. Some of it we built because we had to. All of it is load-bearing, and all of it needs to get better.

We're building a team of exceptional engineers who know what scale looks like and will build the financial backbone that supports the next phase of growth. This includes automating payout orchestration, building an immutable operational ledger, designing settlement and reconciliation pipelines, improving end-to-end observability across payout to processor to bank, hardening controls and fraud detection across the marketplace, and decoupling processor dependencies from core infrastructure.

This is a place for people who care deeply and build boldly, who want the pace and ownership of a hyper-growth startup with the rigor of a fintech, and who understand that at our volume, those two things are the same job. You'll work in-person with a team of ambitious, diverse people on problems that matter, with direct exposure to the research, labs, and startups at the AI frontier. The problems are genuinely hard, the stakes are genuinely real, and the people working on them are genuinely exceptional.

If that sounds like your kind of work, we'd like to talk.

View the role at mercor.com/careers →

Mercor is a profitable Series C company valued at $10 billion, trusted by 6 of 7 Mag 7 companies. We work in-person five days a week in San Francisco.