EconomicoLearn
Your $100k in cloud credits is hiding your real burn rate.
Free credits make your infra line read near-zero and your burn look fantastic. Then they run out or expire in a month you didn't model. Here is how to see that cliff coming.
You have $100,000 in AWS or GCP credits. Your infrastructure line reads close to zero, your burn looks fantastic, and your runway spreadsheet says you are fine. Then, in the words of one founder, “credits just expired and we’re not yet break-even, and the sudden cost increase is tough.”
I am not neutral on this one. We got hit by it ourselves at the company I run, the month our AWS credits finished and the real bill switched on. I want to walk it carefully, because it is the most invisible item on this list. It does not feel like a problem until it is one.
How do credits distort the number?
Work it through. Say you have $100,000 in cash and spend $8,000 a month on infrastructure, all of it covered by a $100,000 credit. Your cash burn is $5,000 a month while the credit lasts, so a spreadsheet that holds today’s burn constant shows twenty months of runway. But the credit covers only twelve and a half months at that pace. After that, cash burn rises to $13,000 a month. You run out in about fifteen months, not twenty. The credit saved real cash; the mistake was treating that temporary saving as permanent.
The scary part is the timing. Credits do not taper. They run out. Founders describe the cliff in almost identical terms:
“Watched one company end up with a $250k AWS bill when their credits expired (which they could not pay).” (Hacker News)
“Stripe Atlas cost me US$500. For that I got a Delaware C-Corp, an SVB bank account, and $5k of AWS credits that expired after 12 months. Our AWS bill in that first 12 months was roughly $5k.” (Hacker News)
That second one is the whole lesson in a sentence. The credit exactly covered a year of real cost, which means for that entire year the true run-rate was invisible. It only appeared the month it had to be paid in cash.
So should I not take the credits?
Take the credits. They are real value and worth a lot, especially early. This is not an argument against credits. It is an argument against letting them hide the truth.
The mistake is booking the credit as “free.” When your infra genuinely costs $8,000 a month and a credit is paying for it, the honest picture has two numbers, not zero: the real $8,000 cost, and the credit drawing down against it. Keep both and two useful things happen. You can see the true underlying burn, the one you will actually pay later. And you can see how much credit is left and roughly when it runs out, which is the date your burn steps up.
- Apr −$8,000 $40,000
- May −$8,000 $32,000
- Jun −$8,000 $24,000
- Jul −$8,000 $16,000
- Aug −$8,000 $8,000
- Sep −$8,000 last $8,000 used — then full price $0
Founders who have been through it end up managing credits like the runway asset they are:
“You want to actually understand your cloud cost burn rate and know when your credits will run out, because otherwise the real number is hidden until they do.” (YC founder on private YC forum)
Some even arbitrage across providers to buy time:
“We’re about to run out of our free $100K of AWS credits (it took a year to burn) and we’ve got hundreds of thousands more in Azure and GCP credits sitting unused, so I’m weighing a mid-quarter migration just to buy more runway.” (YC founder on private YC forum)
The fix is visibility, not discipline
You do not need to be more disciplined. You need books that show the discount and the true cost at the same time, so you can estimate when the discount ends before the full bill arrives. That is a property of how your books are kept, which is the thread running through this whole series.
Which brings us to the tool most founders reach for to keep those books, and bounce straight off.
Try it
Once the activity is recorded, ask for the basis.
How much of my AWS credit is left?
What's my real infra cost, credits aside?
When do my credits run out?