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 expire, overnight, in a month you didn't model. Here is how to see that cliff coming.
By Pelle Brændgaard
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 are actually spending $8,000 a month on infrastructure, all of it covered by a $100,000 credit. Your books show that line as $0. Your net burn looks $8,000 a month lower than it really is. On a spreadsheet that says you have twelve months of runway, you might actually have eight, because the moment the credit is gone, $8,000 a month of real cost switches on.
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 left — then full price $8,000
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 the cliff is on your runway chart months before you reach it, not the day the bill lands. 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 your books are connected, just ask.
How much of my AWS credit is left?
What's my real infra cost, credits aside?
When do my credits run out?