The 45-Day Cash Trap: Why Profitable App Studios Run Out of Money
Your app earned £120,000 last month. Your bank balance says £18,000. You're not failing — you're cash-delayed.
On paper, the studio is healthy. Revenue is growing, margins are solid, users are paying. But the accrual P&L and the bank statement tell completely different stories. This isn't a spending problem. It's not poor planning. It's a structural feature of how Apple and Google handle developer payments — and it affects every studio that earns through in-app purchases or subscriptions.
The gap between "earned" and "received" averages 45 days. For some transactions, it exceeds 60. And the cost of that gap goes far beyond the obvious.
The anatomy of the cash trap
Follow one transaction through the entire pipeline.
A user subscribes to your app on 1 January for £9.99/month. Apple records that revenue in the current earning period, which operates on a 4-5-4 fiscal calendar rather than standard months. This particular earning period closes on 31 January. Apple then begins a processing window — handling refunds, verifying chargebacks, aggregating transactions across millions of apps. That processing takes approximately 33 days.
Your payout arrives around 5 March. Apple takes its 30% commission (or 15% if you qualify for the Small Business Program). If your studio operates in a non-USD currency, add another 1–3 days for FX conversion plus the platform's exchange spread.
Total elapsed time from the user's purchase to cash in your bank: 63 days.
That same user's subscription was one of thousands. The aggregate — let's say £120,000 in monthly revenue — follows the same pipeline. The money is real, confirmed, sitting in Apple's processing queue. But it isn't yours yet.
Meanwhile, on 1 January — the same day that user subscribed — your payroll was due. On 3 January, AWS billed your infrastructure. On 5 January, your UA campaigns needed daily budget. On 10 January, a freelance artist invoiced for character designs delivered in December.
Revenue and expenses operate on different clocks. Revenue follows Apple's fiscal calendar. Expenses follow the real one.
The payroll crunch: the 1st vs the 15th
Every UK employer knows the rhythm. Payroll runs on the 1st (or last business day of the prior month). It's non-negotiable — late payment triggers HMRC penalties and erodes team trust faster than almost anything else.
Apple's payouts typically land between the 10th and the 28th of any given month, depending on where the fiscal period falls. Google pays between the 15th and the 30th. Neither reliably arrives before the 1st.
For a studio with 10 employees at an average salary of £4,500/month, payroll costs £45,000 on the 1st. The next Apple payout — carrying perhaps £60,000 — doesn't arrive until the 15th at earliest. For the first two weeks of every month, the studio is running a £45,000 deficit against revenue that's already been earned and confirmed.
What does the founder do? The options are all bad. Put £45,000 on a business credit card at 24% APR. Draw on an overdraft that costs 10% and requires the business premises as collateral. Delay payments to contractors and hope they don't leave. Cut UA spend during a window when CPIs might be at their monthly low.
Every option has a cost. Most have a cost that compounds.
The growth paradox
The most counterintuitive part of the cash trap: growth makes it worse.
Consider a studio growing at 15% month-over-month — a healthy trajectory for an app that's found traction.
| Month | Revenue | Operating Costs | Cash Buffer (theoretical) | Frozen Capital |
|---|---|---|---|---|
| 1 | £80,000 | £64,000 | £16,000 | £120,000 |
| 3 | £105,800 | £84,600 | £21,200 | £158,700 |
| 6 | £161,000 | £128,800 | £32,200 | £241,500 |
| 9 | £245,000 | £196,000 | £49,000 | £367,500 |
| 12 | £373,000 | £298,400 | £74,600 | £559,500 |
Frozen capital = monthly revenue × 1.5 (based on 45-day average delay). Operating costs assumed at 80% of revenue.
By month 9, the studio earns £245,000/month with a £49,000 theoretical margin. Healthy business. But £367,500 is frozen in the pipeline at all times — nearly two months of operating costs locked up in processing. The "buffer" exists only on the accrual P&L. The bank account sees a different picture: costs arrive before revenue, every single month, and the absolute gap grows with every growth milestone.
Your P&L says you're winning. Your bank account says you're barely keeping pace.
This is why app revenue hit $171 billion globally in 2024 while studios of all sizes — from indie developers to mid-market teams — report the same cash flow pressure. The problem isn't revenue. It's timing.
It's not about planning better
Many founders carry quiet shame about this. They assume cash flow trouble means they're managing money poorly — that a better spreadsheet or tighter budgeting would fix it.
It wouldn't. No amount of planning changes the fact that Apple processes payouts 33 days after closing an earning period. No budgeting strategy alters Google's 15–30 day payment window. The delay is mechanical, built into the infrastructure of both platforms, and applied uniformly regardless of your studio's size or financial discipline.
Even venture-backed studios with substantial runway experience this gap. They've simply papered over it with investor capital — capital that has its own cost in dilution and governance.
The structural nature of the problem matters because it changes the solution set. You don't solve a timing problem with better planning. You solve it by either accepting the cost (and it is a real cost — see our breakdown of the actual numbers) or by finding a mechanism that aligns your cash inflows with your cash outflows.
The industry has normalised this pain. Studios treat the monthly crunch as just "how it works." But normalised and inevitable are different things.
Solutions exist — but choose carefully
Several categories of tools address the payout timing problem. Each carries trade-offs that are worth understanding clearly.
Credit lines and overdrafts are the most common bridge. They're fast to deploy but expensive — 20–30% APR for revolving credit, 8–12% for overdrafts — and come with hard limits that don't scale with your revenue. For a studio with £250,000/month in payouts, the maths on credit card interest alone runs into five figures annually.
Revenue-based financing and factoring is a growing category where providers advance capital against confirmed app store payouts. Models vary significantly: some require redirecting your store payouts to the provider's account, others work differently. The critical question isn't just the fee — it's the ownership structure. Where does the money go? Whose account holds your payouts? How easily can you disengage?
Equity or venture capital eliminates the cash problem entirely, but the price is ownership dilution and a fundraise process that takes months. Not a practical answer to a cash gap that recurs every 30 days.
Waiting it out remains the default for most studios. It carries zero direct cost and maximum opportunity cost — every month of frozen capital is a month of UA you didn't run, hires you didn't make, and compound growth you didn't capture.
Whatever approach you evaluate, start with one question: who controls the money? Whether your payouts land on your account or someone else's determines your leverage, your flexibility, and your ability to walk away.
Calculate your actual gap
If your studio is profitable on paper but consistently tight on cash, you're not alone and it's not your fault. It's the 45-day cash trap — a structural feature of the app store economy that affects studios at every scale.
The cost is quantifiable. For a studio earning £80,000/month, roughly £120,000 sits frozen at any given time, costing between £28,000 and £270,000 annually in direct financing costs and missed growth opportunities. You can calculate your specific figure using the App Revenue Intelligence Report — enter your payout data and get a personalised breakdown.
We built Amps33 specifically for studios caught in this trap — because confirmed revenue shouldn't be stuck in someone else's processing queue. See how it works →