What Happens to Your Cash Flow When Your App Goes Viral
It's Tuesday morning. Your puzzle game just got featured in App Store's "New Games We Love." Downloads are 12x your normal daily rate. This is the best thing that's ever happened to your studio. It's also about to become your biggest financial headache.
The paradox at the centre of this industry is that the best thing that can happen to your revenue creates the worst conditions for your cash. Revenue spikes immediately. Cash from that revenue arrives 30–45 days later. Every growth lever — paid UA, server capacity, support — demands money now, while the window is open. Most studios aren't prepared for this, not because they're badly run, but because nobody explains the mechanics until you're in it.
The First Two Weeks: A Day-by-Day Account
Studio M is a composite scenario built from typical UK app studio dynamics: revenue range, cost structure, App Store payout timing, and UA economics. The numbers are illustrative, not a live case study. The mechanics are real.
Studio M: four people, based in London. A puzzle and casual game, £40,000 per month in net App Store payouts — the confirmed amount Apple will transfer roughly 33 days after each fiscal period closes. Growing at 8% month-on-month. Well-run.
Day 1 — Tuesday: The Feature
At 6 AM GMT, the App Store editorial team refreshes. Studio M's game appears in "New Games We Love" across 12 English-language storefronts. By 9 AM, the founder's phone is showing a number that doesn't look real.
Daily downloads: 800 → 9,500. According to Sensor Tower data, editorial features of this type typically produce a 5–15x download spike, with the effect concentrated in the first 72 hours.
Daily revenue: approximately £1,300 → approximately £16,000.
Slack is on fire. The team is sending each other screenshots. Cash in the bank at start of day: £22,000 — slightly above the typical operating buffer.
The key thing to understand about that £22,000: it is all the studio has access to right now. The £16,000 earned today, and the £155,000+ that will be earned over the next two weeks, are confirmed receivables — Apple will pay them out — but not for 30–45 days, depending on which fiscal period they fall into.
Days 2–3: The First Costs Arrive
Downloads settle at 7,000–8,000 per day. Revenue is running at £12,000–£14,000 daily. The accrual P&L is going vertical.
What no one is watching: AWS auto-scaling.
The game's backend is now handling 10x baseline traffic. Auto-scaling handles it cleanly. The bill doesn't. Daily infrastructure cost goes from around £80 to around £620 — and it bills immediately.
Meanwhile, the support queue has exploded: roughly 15x normal ticket volume. New users encountering first-time issues, older device compatibility problems, a minor sync bug that only surfaces at scale. Two developers are now splitting time between the roadmap and emergency patches.
Cash impact through Day 3: confirmed receivables growing rapidly, cash received = £0. Extra costs already incurred = approximately £1,080 in server overruns. Cash in bank: approximately £20,900.
Days 4–7: The Window Opens
By Day 4, the co-founder has done the UA analysis. The feature is lifting organic efficiency — store conversion is elevated, CPI is lower than normal because organic momentum is doing some of the paid work. This is the compounding window: a period where paid spend amplifies organic rather than competing with it.
The back-of-napkin math points to an optimal UA deployment of £15,000–20,000 this week — three to four times the normal budget. That window won't stay open. Feature placement typically fades within 10–14 days, and the CPI advantage fades with it.
Here's the structural problem.
The next App Store payout arrives in 19 days. It covers confirmed receivables from before the feature — the normal £40k monthly period that ended last week. The revenue currently accumulating in real-time will not be paid out for another 5–6 weeks, across two or three separate payout cycles, depending on which Apple fiscal weeks the spike spans.
The studio has £20,900 in the bank. Deploying £15,000–20,000 in UA leaves £900–5,900. Payroll is in 18 days: £14,000.
Decision point, Day 5: The co-founders sit on a video call at 10 PM.
Option A: Deploy £15,000 in UA now. Bridge the payroll gap on the credit card. Clear it when the confirmed pre-feature payout lands.
Option B: Hold the cash. Skip the UA push. Watch CPI normalise over the next 10 days as the organic lift fades.
They choose Option A. The credit card goes to £15,000. Cash in bank: £5,900.
Days 8–14: Living on the Edge
The feature placement begins to fade around Day 9. Downloads drop from the 7,000–8,000 peak to approximately 3,500–4,000 per day — still well above normal, but declining. Paid UA is tracking ahead of ROAS targets, so the team continues spending while the CPI advantage holds.
By Day 12: server costs still running around £400/day. Payroll lands in 4 days. The prior-period payout — the confirmed pre-feature receivables — arrives in 7 days, so the bridge holds.
But the UA spend that was planned at £15,000 has become £19,500. The window stayed open longer than expected.
Total credit card balance: £19,500. Cash in bank: £2,400.
By Day 14, Studio M has earned approximately £155,000 in confirmed App Store revenue during the viral period. They have received £0 of it. Their bank account holds less cash than a normal Friday two months ago.
Days 30–45: The Payout Cascade
The payouts arrive — but not as one sum. Apple's 4-5-4 fiscal calendar means revenue earned across the feature period spans two or three separate fiscal weeks, each triggering its own payment cycle.
The first payout: ~£47,200. That's the confirmed pre-feature receivables, arriving on schedule. The credit card gets cleared.
The second payout, three weeks later: ~£61,000 (the first fiscal week of the viral period). The third: ~£58,400. The fourth: ~£34,500 (the tail, as downloads normalised). Each one lands 30–45 days after the revenue was earned.
Total confirmed receivables paid out across all periods: approximately £201,100. (The gap between the £155k earned in the 14-day window and the ~£201k total reflects continued elevated downloads after Day 14, plus in-app purchases from the acquired cohort generating revenue across subsequent billing periods.)
By Day 60, Studio M has survived the cash crunch and captured the growth. The experience was more stressful than it needed to be.
The Structural Reason This Happens
What just happened is not a management failure. It's a structural feature of App Store economics.
Revenue is event-driven — virality, features, and seasonal spikes happen in concentrated windows. Your cost response must also be immediate, or the window closes. But cash receipt is calendar-driven. Apple and Google pay confirmed receivables on their schedule, not yours. The gap between those two timescales is where the stress lives.
The faster you grow, the bigger the pipeline of earned-but-unreceived revenue sitting in that gap at any given moment. A studio growing at 15% month-on-month has, by definition, 15% more frozen cash than last month. This timing risk is systemic, not exceptional — it's the default condition for any growing UK app studio with App Store or Google Play as its primary revenue channel.
The studios most exposed are the successful ones. If your app never takes off, you never face this particular crisis.
What Being Ready Actually Looks Like
The difference between Studio M's experience — stressful but navigable — and a studio that misses payroll or watches the UA window close entirely comes down to one thing: preparation. Not talent, not strategy. Preparation.
Know your payout schedule to the day. Not "approximately when," but exactly which fiscal week maps to which payment, and precisely when it clears. Use the Payment Calendar. Viral windows don't give you time to reconstruct this mid-crisis.
Model the scenario before it happens. Run a stress-test: what happens to your cash position if revenue triples for 14 days? Use the Financial Model to map it out cold, before it's real. You'll make better decisions when the moment is theoretical.
Maintain a meaningful buffer. 1.5 months of operating costs is the rule of thumb. For Studio M at £30k/month in costs, that's £45,000. Most studios operate at half that. The buffer exists so that a £15k credit card bridge isn't existential.
Pre-arrange financing — and understand the architecture. This is the step most often missed. But it's also worth being specific about what "pre-arranged financing" means in this context, because not all setups are equivalent.
A credit card or overdraft has a fixed limit and personal exposure. An RBF facility takes 2–4 weeks to onboard and reduces your monthly revenue for the entire repayment period. Some factoring providers require permanently rerouting your App Store payouts through their own account — which means every payout, from that point forward, flows through their systems before reaching you.
A client-owned account model works differently: your confirmed App Store receivables are advanced against, your payouts continue flowing to an account in your name at an FCA-regulated banking partner, and the advance is reconciled when the payout lands. Your revenue is always yours, visible in your account, and under your control. That distinction matters most in exactly the scenario Studio M just navigated — when the window is open, you're already stressed, and the last thing you need is a provider standing between you and your own money.
For a UK studio earning £20k+/month with 12+ months of App Store history, setting up this kind of facility takes 3–7 business days for a first advance. If you already have an active facility, same-day is possible. That means even an unprepared studio that gets featured today has a realistic path to deploying capital within the same week — but only if onboarding is already complete.
Set UA trigger rules in advance. Before the spike, write down: "If CPI drops below £X while organic is elevated, I will deploy up to £Y." Decisions made at 10 PM with £2,400 in the bank and payroll in 4 days are not your best decisions. Pre-set rules are.
Two Scenarios, Six Months Later
Studio M captured the window. Here's a scenario model for what the outcomes could look like six months post-feature — and what they might look like if they hadn't.
The numbers below are illustrative, built from the UA economics in the scenario above (ROAS, cohort LTV, organic baseline lift from acquired users). Real outcomes depend on retention, creative quality, product, category competition, and a dozen other factors. The point isn't the specific numbers — it's the direction and magnitude of the gap that compounding creates.
Scenario A — captured the window: Monthly revenue six months post-feature in the range of £80k–100k. The UA spend during the compounding period acquired cohorts that continued generating revenue. Organic word-of-mouth from those users lifted the baseline. The credit card bridge cost approximately £300–400 in interest over 3 weeks.
Scenario B — played it safe: Monthly revenue six months post-feature in the range of £45k–60k. The editorial feature still generated organic uplift without paid amplification. But without the UA compounding effect, growth tapered faster and the new baseline settled lower. Users not acquired in that window were acquired by studios that were spending.
The gap between these scenarios — call it £30k–45k/month in ongoing revenue — is entirely a function of what was possible to deploy during a 10-day window. The financing cost that enabled Scenario A was in the hundreds of pounds. The difference in trajectory was potentially in the hundreds of thousands over the following year.
This is not an argument for reckless spending. It's an argument for being ready, so that when the moment comes, the decision is considered rather than panicked.
The Setup Checklist
Know exactly when each payout lands — the Payment Calendar gives you this. Run the cash flow stress-test. Maintain 1.5 months of operating costs as a buffer. Set up your financing arrangement before you need it.
If your UK studio earns £20k+/month from App Store or Google Play, Amps33 lets you set up a factoring facility before the moment arrives. Payouts go to your Ampere account — not ours. 3% flat fee, no hidden FX costs, no lock-in after repayment. When the feature hits, you access your confirmed receivables in days, with full visibility and control. See how the client-owned account model works →
The window won't wait. The setup can happen today.
Sources: Sensor Tower — Feature Boost Benchmarks · data.ai — State of Mobile · Apple Developer — Financial Reports and Fiscal Calendar