Ruvo bet on payroll, and the bet is right. Volume from remote-dev payroll is compounding at ~24%/month while the whole business sits flat near $1.92M/mo. The engine works.
But the goal you confirmed — $20M two-way per month by December, a 10× — needs ~40%/month for seven straight months. No amount of optimizing today's book gets there: the most aggressive combination of every current lever tops out at ~$11.6M (58% of goal). $20M is a step-change: it needs a new high-volume channel added on top of the engine, not just a faster version of it. (EOR = Employer of Record, e.g. Deel or Remote — the platforms foreign companies use to pay workers abroad.)
This is the recon report — the first pass of a system Warmode runs continuously. We re-rooted your growth metric on the real production ledger, audited what you can and can't measure, modeled the business as a tree, and found where the leverage is. Future passes update the same model on live data instead of restarting from scratch.
Ruvo moves money for Brazilians — USD, BRL and stablecoin over Pix, off-ramp, crypto and card. The ledger is healthy and the core thesis holds: payroll devs are the engine, and they're growing. Most of them invoice their foreign employers through a pejota — a Brazilian sole-proprietor company (a CNPJ) that remote developers register to bill abroad.
The problem is not the engine. It's the slope a 10× goal demands, made harder by two things: an activation funnel where only 17% of signups ever transact, and volume that leans on a handful of large accounts ("whales").
The north star is total two-way settled volume — every dollar that successfully moves in or out (inflows + outflows), converted to USD. We picked it because it reproduces the number Ruvo already reports and matches what Ruvo's own model targets. The reported "$2M for May" reconciles to $1.92M on this definition.
The chart below is the core of the diagnosis. The solid line is the path required to hit $20M by December (≈+40%/mo). The dashed line is the current trend (≈+2.4%/mo). The gap between them is the whole problem.
We broke the north star into a tree of 25 drivers. Each driver is tagged by funnel stage and by how well we can see it (instrumented / derivable / blind), so coverage gaps are visible instead of hidden. The spine reads simply: volume = active accounts × volume per account; active = newly-activated + retained; activation = ready-state × first value. The full interactive map is linked below.
The chart shows the three real segments by monthly two-way volume. Payroll (accent line) is the one that's climbing; business and individual are flat-to-noisy. Note the Mar→Apr "business" jump — that was pejota devs miscoded as businesses, not real multi-customer companies (which are only ~2% of accounts).
The single biggest constraint is the activation funnel: of every 2,100 signups, only 355 ever transact. Each step roughly halves the cohort, so there's no one villain — but it caps how fast any segment can grow.
To make the goal concrete, we back-calculated it from the funnel. $20M two-way is about $10M of one-way user-chain volume to drive. We work that backward through the rates we measured and the ticket sizes we assume. Coefficients used: avg $7k/mo per payroll dev (A), $15k/mo per real business (A), 17% activation (M), install→signup 35% (A), visit→install 4% (A). The punchline on each path is the net new active accounts you'd need to add every week for 30 weeks.
Now the reality check. The book grows at +2.4%/mo today; the goal needs ~+40%/mo — roughly 16× the current rate, held for seven straight months. Even the proven payroll engine, growing at +24%/mo and applied to the entire book, lands only $8.7M (43%). The most aggressive composite of every current lever ceilings at $11.6M (58%). The conclusion is not that $20M is unachievable — it's that it requires a discontinuity: a new high-volume channel (enterprise treasury / EOR-at-scale deals) layered on top of the engine. These numbers show exactly how big that channel has to be.
The model says it plainly: the right engine is in place and compounding, but no combination of optimizing it reaches $20M. Push payroll via EORs, unblock it by compressing pejota KYB, protect the whales — and open an enterprise channel for the step-change. If that channel doesn't materialize, the honest call is to re-time the 10×.
Competitive read. The "receive USD cheaply" step is a race to zero — Husky (Nomad-owned) charges ≤1% at commercial rate, Wise is mid-market, Nubank just removed FX spread on its global account, and Deel already pays Brazilian contractors via Pix at near-zero provider fee. Ruvo cannot win on conversion price. The deeper threat is EOR disintermediation: the same EORs that pay devs into Ruvo (Deel, Remote) can pay out locally and absorb the value.
The wedge. Ruvo's data points away from "move the wire" and toward "own the account + treasury" — the business/CNPJ cohort behaves like sticky, higher-margin treasury (larger, irregular balances), not one-shot salary conversion. The defensible position is the full account (Pix + USD + card + savings) for the cross-border dev/business who lives in both currencies — not the cheapest single transfer. Full analysis: findings/phase5/competitive.md (29 sources).
The app's spending/holding surface is clean and on-message (named "payroll" on the US-bank add, free fast crypto-to-crypto, in-app pricing transparency). But the funding paths — the first-deposit moment — are exactly where the 17% activation and 23-day ready-state lag live. This isn't abstract: our own walk-through hit both leaks first-hand.
Three checklists — fix what you can't see, grow the engine, and the next experiments to run — followed by a dated two-week plan to start.
This diagnosis is built on the production ledger as source of truth; RudderStack events are a cross-check (only ~10 days deep). Segment classification is DB-native (by employer counterparty), validated against Ruvo's hand-labels. Numbers are directional, sized to prioritize — every figure is tagged measured / derived / assumed in the working files.