Mercury vs Relay: Banking for a Custom Software Shop

Say a typical engagement bills a third at kickoff, a chunk at each milestone, and a final payment on delivery, while contractor and staff costs run on a level, ongoing basis regardless of where you are in the client's payment schedule. That mismatch is a cash flow problem before it's a banking problem, but the two platforms handle the symptom differently. Relay lets you open a dedicated sub-account per active engagement, so a kickoff payment for Project A never quietly funds payroll for the team on Project B, and you can see at a glance which engagement is actually cash-flow positive right now. Mercury doesn't structure accounts around individual projects the same way, but its API lets a shop with an internal project management tool pull real-time balances and tag transactions programmatically, which scales better once you're running a dozen engagements at once instead of three.

Most custom software shops lean on a mix of full-time staff and contractors who scale up or down with the pipeline. Relay's free sub-accounts make it straightforward to set aside a contractor reserve the moment a milestone payment lands, so the team assigned to a project gets paid on schedule even if the client's next invoice runs a few days late. Mercury supports the same discipline through its own multi-account structure, and its programmatic ACH capability lets a shop batch contractor payments from an internal tool rather than keying each one into a banking portal by hand. If your contractor roster is large and international, check each platform's current wire and FX pricing for your actual payment corridors before committing, since neither publishes a single flat international rate that applies everywhere.

Shops that run retainer relationships, a fixed monthly fee for an ongoing team, tend to carry a larger cushion of cash between billing cycles than project-only shops do. That cushion is worth putting to work. The 10-year Treasury yield is running at 4.44%¹, and Mercury's Treasury sweep automatically moves cash above your operating buffer into short duration instruments tracking rates like that, instead of leaving a retainer cushion earning nothing in a checking account. Relay doesn't offer that same automated sweep, so a shop that wants both envelope budgeting and yield sometimes ends up running accounts at both, Relay for the day-to-day project accounts and Mercury for the retainer cushion sitting idle between billing cycles.

Development shops that bridge a slow sales quarter with a line of credit are borrowing at a cost set by the broader rate environment, not by either bank individually. Commercial lending is generally priced off the bank prime rate, currently at 6.75%², so a credit line drawn today costs meaningfully more than one drawn a few years back. Track your own burn multiple, net burn against net new signed contract value, and keep it under 2x³ as a working ceiling: a shop pulling on a line of credit every quarter to cover payroll, rather than occasionally to smooth one rough stretch, has a pipeline problem that neither Mercury nor Relay can fix with better account structure.

If your team already has an internal ops dashboard, or wants to build one, Mercury's documented REST API is the more useful foundation: read-only balance and transaction queries plus programmatic ACH give an engineering-literate operations lead a lot to build on. If your shop instead runs its finances through QuickBooks Online or Xero and a project management tool rather than custom tooling, Relay's listed integrations with those platforms, plus limited-permission bookkeeper access, may give you most of the same visibility without anyone writing a line of code, but confirm the current integrations on Relay's site. Neither choice is permanent: several shops start on Relay while small and move toward Mercury's API once an internal finance tool becomes worth building.

Pull up your last six engagements and check two things: how many were milestone billed versus retainer billed, and how many times a contractor payment went out before the matching client payment had cleared. A shop that's mostly retainer work with a stable core team leans toward whichever platform its bookkeeper already prefers, since the cash timing risk is low either way. A shop that's mostly project work with a contractor bench that flexes up and down leans toward Relay's per-project sub-accounts first, specifically to keep that timing gap visible, and can layer Mercury's Treasury sweep on top once there's a genuine cushion of idle cash between projects worth automating. Revisit the answer every couple of quarters, since a shop's mix of project and retainer work tends to shift as the client base matures, and the banking setup that fit a three-person shop rarely still fits once you're running several engagements in parallel with a rotating contractor bench.

Test your shop against your recent work with these steps:

1. Pull up your last six engagements so the check rests on real billing history instead of a general impression of how the shop runs.
2. Count how many were milestone billed and how many were retainer billed, since the two create very different cash timing risk.
3. Count how many times a contractor payment went out before the matching client payment had cleared.
4. If work is mostly retainer with a stable core team, pick whichever platform your bookkeeper prefers, because the timing risk is low either way.