Read this before you take Google's $200K

A founder I know took a Google for Startups Cloud Program offer in early 2025. Scale tier. Two hundred thousand dollars in credits across two years, gated by an investor reference and a few onboarding calls. He told his cofounder it was the best deal in the round. Eleven months in, he opened the invoice screen and found a $9,300 charge that the credits had not absorbed.

The bill was for Claude 3.5 Sonnet. He had been routing inference through Vertex AI on the assumption that anything Google billed him for was on Google’s tab. It was not. The credits had quietly stopped applying the moment a request hit the Anthropic SKU.

This is the post I wish someone had handed him before he wired his architecture to a billing relationship he did not understand. The credits are real. The program is the most generous in cloud right now. But there are four traps inside it that have already bankrupted founders who showed up prepared. None are in the marketing copy. All are in forum posts written after the bill arrived.

$200,000 in Google Cloud credits over 24 months on the Scale tier

$72,000 burned in seven hours by Milkie Way’s recursive Cloud Function

$82,314 charged to one founder in 48 hours from a leaked Gemini API key

$0 the dashboard suggests Year 2 will cost. ~$40K/mo what it actually costs at a scaled workload.

Across founder reports the pattern compresses into four reminders. First, read the SKU exclusions page before wiring a stack to a credit pool — every “Google’s paying my bill” story ends with a Marketplace SKU somewhere in the invoice. Second, free credits are not free; they’re a discount on a workload you’ve already underwritten at retail, and if the retail workload doesn’t pencil, the credit is a trap rather than a subsidy. Third, “the credits are the plan” is one of the most expensive sentences a founder can say out loud, and the runway crunch from it is usually predictable eight to fourteen months out. Fourth, treating $200K of GCP credits as runway is a 24-month horizon and zero discipline; treating them as a 20% discount on your real cloud bill is an 18-month horizon and a balance sheet.

The credits are real

Before the warnings, the offer. The program runs three tiers. Start tier hands $2,000 to any incorporated startup. Build covers most accelerator-backed companies. Scale is the headline number, $200,000 across two years for venture-backed companies, with a $350,000 variant for AI-focused teams routed through specific partners.

Year 1 covers up to 100 percent of the bill against the credit cap. The discount logic is automatic. You enable billing, the credits draw down, you ship.

The acceptance posts confirm the program is funding real AI startups at the top tier. From Doppel:

Excited to share that we were just accepted into the Google for Startups Cloud Program and approved for the Scale tier as an AI startup, with $350K in Google Cloud credits.

A huge unlock for us as we keep building.

— @doppelfun Mar 11, 2026

This is genuinely useful money. Many of the companies that got something built in 2024 and 2025 got it built on this credit pool. The complaint below is not that the program is a scam. It is that the program documents what it covers in language that is technically correct and operationally misleading, and the gap has cost specific founders specific amounts of money. Those amounts are large enough that you should read this before signing the perks form.

It is also the largest of the comparable programs. Fernanda Kipper’s working list of the alternatives:

Startup Credits Kit 👇🏻🤝

AWS Activate: Up to $100,000 in credits - ()

Google for Startups: Up to $200,000 in credits - ()

Microsoft Founders Hub: Up to $150,000 in Azure credits + OpenAI - ()

Linear for

— @kipperdev Mar 12, 2026

Trap one: Claude is not covered

The most expensive misunderstanding inside the program is that Vertex AI is one product. It is not. Vertex hosts Google’s first-party models (Gemini 2.5 Pro, Gemini Flash, the Vertex-trained derivatives, Imagen, Veo) and a separate set of partner models served through what Google internally classifies as Cloud Marketplace SKUs. Claude 3.5 Sonnet, Claude Opus, Mistral Large, AI21, and the Llama 3 partner endpoints sit in the second bucket.

Marketplace SKUs are formally excluded from startup credits. This is documented on Google’s discount exclusions page, which lists “third-party Marketplace SKUs” alongside committed-use discounts and professional services. The marketing perks page does not link to the exclusions page. The exclusions page does not enumerate which Vertex models count as partner models. You have to know.

Founders have been finding out the hard way for over a year. From a Reddit post titled “Google startup credit screw up”:

Google Cloud for Startups has a major ‘gotcha’: Credits only cover first-party Google services. If you’re using Claude (Opus/Sonnet) via Vertex AI, Google classifies that as a Marketplace / third-party purchase and it is excluded from GCP Startup Credits.

The same pattern surfaces on Azure, which tells you this is structural. The Register reported in March 2026 on a founder charged $1,600 for Claude through Azure AI Foundry while holding Microsoft for Startups credits. He spent weeks getting bounced “between Microsoft and Anthropic like a support ticket nobody wants to own.” Anthropic’s billing math has its own bug too. An open Claude Code issue shows actual Vertex token cost roughly 7x higher than what the CLI reports.

What this means in practice. If your inference stack is Anthropic-heavy in production, you are paying full retail for the dominant cost line in your business. The credit pool will quietly cover storage, networking, Cloud Run, and Gemini calls. The Claude bill accumulates alongside it. Founders who modeled “we have $200K from Google” without separating those two pools have woken up to invoices in the four and five figures while their dashboard still shows credits remaining.

The fix is small. Before the architecture diagram, list every SKU you intend to consume and email Google’s startup-success contact to confirm in writing, with the SKU codes, that each one is covered. Treat any answer that is not “yes, in writing” as a no.

The Vertex marketing page treats Claude as a first-class citizen. The billing exclusions page treats it as Marketplace. Both pages are technically correct. The combination is a tax on founders who do not read footnotes — the most common version we see is a founder running 80% of inference on Claude via Vertex on the theory that “Google’s paying for it,” then opening a $10K-plus invoice in month four with the credit balance still nominally full.

Trap two: the silent cliff in year two

The Scale tier is described as a $200K, two-year credit. Most founders read that as “Google pays my cloud bill for two years.” That is not how the math works.

The structure, confirmed across the Akave breakdown and several founder reports, is:

• Year 1: credits cover up to 100 percent of your bill against the cap.
• Year 2: credits cover roughly 20 percent of your bill against the cap.
• Year 3: zero. Full retail.

The program calls this a “graduated” credit. From the founder’s seat it is a 5x cost step.

Run the math on a realistic AI-startup trajectory. You spend Y1 building. By month nine, your monthly GCP bill (gross of credits) has crept to $8,000 a month. You are not stressed because the dashboard shows the credits absorbing it. The Y2 boundary hits and the same workload, growing modestly with usage, is now billing you about $6,400 a month out of pocket on a $8,000 gross bill. If you scaled compute meaningfully during Y1 and the gross bill is $20,000 a month, Y2 is $16,000 a month landing on a runway you sized for “we have credits.”

The Akave write-up phrases the trap precisely:

Google Cloud Scale covers 100% of your bill in Year 1, 20% in Year 2, and nothing in Year 3. By then, your architecture is built around services that are cheap to adopt and expensive to unwind.

This has been quietly eating funded companies. AI startups spend 40 to 60 percent of burn on infrastructure, per YBAWS’s compute-trap analysis, against roughly 10 percent for traditional SaaS. A 5x step on the dominant cost line shows up in the cash-flow statement before the founder has the muscle memory to look for it. By then you are running Firestore, BigQuery, and a fine-tuned Gemini, none of which port off GCP without quarters of work.

Darren Mowry, Google Cloud’s VP of global startups, said it himself in February: “Are you building a startup on borrowed infrastructure time?” His own program is the borrowed time he is asking about.

What you should actually budget for. Take whatever your projected Y1 monthly run rate is and model 80 percent of that as a real Y2 line item from month thirteen onward. Then model 100 percent of the Y2 trajectory as a real Y3 line item. If those two numbers do not work against your runway, you do not have a credit problem. You have a unit-economics problem disguised as a credit win.

Founders consistently underestimate the Year 2 cliff because the GCP billing dashboard does not draw it for them. The credit balance is a single number that ticks down; the coverage rate behind it changes silently at month 13. If you have not modeled month 25 as a real line item on your runway sheet, you do not have a runway sheet — you have a credit balance.

Trap three: $72,000 in seven hours

The single most cited cloud horror story in the founder community is Sudeep Chauhan’s. In March 2020 his startup, Milkie Way, was prototyping a recursive Cloud Function that wrote into Firestore. The function had a trigger that re-fired on its own writes. They left it running while they had dinner.

His own write-up of the bill:

In March, 2020, when COVID hit the world, our startup Milkie Way too was hit with a big blow and almost shut down. We burnt $72,000 while exploring and internally testing Cloud Run with Firebase within a few hours.

The follow-up post named the number that did the damage:

One Hundred Sixteen Billion: that’s the number of times our test code read Firestore database in less than an hour.

He had budget alerts configured. They fired. They did not stop anything. Budget alerts on GCP are informational. They cannot disable billing on a project, only notify you that the project is bleeding. By the time the third alert hit his inbox the bill was past $50,000. The Register’s coverage of the incident put the headline plainly: “Billing budget? Free plan? All useless when buggy code went into overdrive.”

The Milkie Way story is famous because Google eventually forgave it. They did so under public pressure on Hacker News and Medium. They did not refund automatically and they took weeks to decide.

The pattern repeats every quarter. A student in September 2025 had a $55,444.78 bill from a Gemini API key leaked to a public GitHub repo, twenty-four hours of unauthorized inference. An anonymous founder wrote in February 2026:

Between Feb 11 and 12, our Google Cloud API Key was compromised and generated $82,314.44 in charges. Our normal monthly spend is $180. 455x more than normal.

Source: r/googlecloud.

Google did, in late 2025, finally add hard project-level spend caps for the Gemini API. That fixes one of the failure modes above. It does not cover Cloud Run, BigQuery, Firestore, GCS, or anything else. The only platform-wide spend kill switch on GCP is the billing-disable Cloud Function pattern that Google itself documents as a workaround. You have to deploy it. It is not on by default. Most founders do not deploy it until after their first scare.

The single most upvoted comment under the Milkie Way Hacker News thread captured what every founder I have shown this section to has said back to me:

The fact that cloud providers don’t have a simple ‘This is how much I can afford, don’t ever bill me more than that!’ box on their platforms makes development a lot scarier than it really needs to be. This is my worst nightmare.

That comment is from 2020. The box still does not exist.

Trap four: Google does not refund

The most operationally important fact about a GCP runaway bill is that Google’s published policy is no refunds. They have a goodwill program internally called Runway Spend that they sometimes apply to first-time billing accidents. The program is discretionary. It is not contractual. It is not advertised. And it has a carve-out that has caught several founders flat-footed.

From a 2026 r/googlecloud post on a $120,000 GCS storage-class bill:

When we contacted GCP and opened a ticket, they said that the charges were assessed under their Runway Spend classification. However, according to their internal policy, billing accounts that procure GCP services through a reseller or partner are not eligible for Runway Spend credits.

If you bought GCP through a reseller, and many accelerators route their member companies through Carahsoft, SADA, or DoiT for procurement convenience, you have no Runway Spend access. The program that discretionary-forgave Milkie Way is not available to you.

Compare this to AWS, where customer-facing billing teams have visible authority to issue one-time goodwill credits for first runaway-cost incidents. GCP’s posture is closer to “the bill is the bill.” The cases that get forgiven get forgiven because they get loud, not because there is a process.

The takeaway is operational. Treat your GCP bill the way you would treat a credit card you cannot freeze. Set the kill-switch function. Set quotas at the API level, not just budget alerts. Rotate keys on a real cadence. Audit reseller status before you sign the credit T&Cs. The recovery path you are imagining does not exist.

The day-zero FinOps checklist

If you are taking the credits, the work begins on day one, not at month thirteen when the cliff hits. The founders who walk out of this program with a working balance sheet have all done some version of the following inside the first thirty days. The ones who do not have done some version of the obituary photographs above.

The architecture choices that decide whether you survive Y2

The structural problem with the Scale tier is not the program. It is the architecture decisions founders make in Y1 because the credits are absorbing the cost. A workload designed for “free Y1” is almost never the same workload that survives full retail in Y2. Three architecture patterns separate the founders who walk out of the program with a healthy P&L from the ones who walk out scrambling for a migration plan.

The first pattern is multi-cloud routing of inference at the application layer, not at the infra layer. Most founders default to “deploy on GCP, call Vertex” because it is the path of least resistance. The pattern that survives Y2 is a thin inference router (often a 200-line wrapper around the application) that can swap between Vertex, the Anthropic API direct, OpenAI, and any other endpoint without redeploying the underlying service. This sounds like premature optimization. It is not. The router becomes the lever you pull at month thirteen when Y2 pricing kicks in. Founders who have the router at month one negotiate Y2 from a position of strength. Founders who do not are price-takers.

The second pattern is keeping state portable. Firestore, BigQuery, and Spanner are the three GCP services with the highest lock-in cost. Firestore in particular is a structural trap: the data model does not port cleanly to anything else, and the migration cost is measured in engineer-quarters. The founders who survive Y2 use Firestore as a cache or a session store, not as the primary system of record. The system of record lives in Postgres or in object storage with a portable schema. This is a Y1 architecture decision, and it is irreversible by Y2.

The third pattern is GPU economics. AI workloads burn GPU credits faster than any other line. Y1 is forgiving because credits absorb whatever you throw at them. Y2 is not. Founders who survive design from day one against a fixed GPU budget per inference, even when the budget is theoretical. They benchmark cost-per-thousand-tokens against the cheapest viable provider and use that as the unit they will be measured against in Y2. The founders who do not benchmark have no idea what their unit economics actually are until the cliff hits.

What to ask your Startup Success Manager

The single most underused asset in the program is the Startup Success Manager. Most founders treat the SSM as an account executive whose job is to upsell. The SSM’s actual job, in the way the program is internally structured, is to keep your account from churning at Y2. They have access to private pricing levers the public docs do not mention, and they get paid on retention. The conversation goes very differently if you walk into it understanding that.

Eight questions to bring to your first SSM meeting, before you architect anything:

1. Can you confirm in writing which of the following SKUs are excluded from credits, with SKU codes? (List every Vertex partner model, every Marketplace product, and every regional variant you might use.)
2. What is the exact percentage of coverage in Y2, and on what date does it transition?
3. Does my account have direct GCP procurement, or am I procured through a reseller? (Asks the question that determines Runway Spend eligibility.)
4. What is the process for requesting a Y1-end private pricing agreement, and when should I open it?
5. Can I get a written commitment that the covered-SKU list will not change mid-program? (Reference the HN thread on silent scope changes.)
6. What is the discretionary refund policy, and what triggers it? (Force them to tell you “Runway Spend” exists, since they will not volunteer it.)
7. Can my account be enrolled in BigQuery slot commitments at a startup discount?
8. What is the multi-year commit discount available for a renewal, and what is the smallest commit that unlocks it?

The answers to these questions are uneven across SSMs because the program is not consistently trained. A persistent founder gets concrete numbers. A non-persistent founder gets a deck. The difference between the two outcomes, measured at month thirty-six, is often six figures.

Founders outside the US should also know about Google’s regional pre-seed cohort, which sometimes pays better than the headline Cloud program for the right profile:

Are you a founder in India?

Google’s AI Futures Fund + Accel Atoms just launched a pre-seed AI India cohort.

Capital, Cloud credits, early Gemini/Veo/Imagen access for founders in India.

Apply now, link in comment

— @minchoi Nov 25, 2025

When to take it anyway

This piece should not read as “skip the program.” It should read as “know what you are signing.” The program is the right move for some founders and the wrong move for others, and the difference is mostly about your stack and your discipline.

Take the credits if all of these are true. Your inference is Gemini-native or you are CPU/storage/network-heavy with no partner-model exposure. You have at least one engineer who can spend a half-day a week on FinOps hygiene (billing exports, kill-switch, key rotation, region audits). You can model Y2 at 80 percent out of pocket against your runway and the math still works. You buy GCP directly, not through an accelerator’s reseller channel.

Be careful about the credits if your stack is Anthropic-first, you are pre-PMF and have nobody on FinOps, your runway is sized to the credit pool, or your investors will model the company’s cloud cost net-of-credits in their next round and ask hard questions about Y3.

Skip the program entirely if the only reason you are taking it is the headline number. The credits are valuable as a subsidy on a workload you were going to run anyway. They are dangerous as a reason to choose a workload. The founders who get hurt by the program are mostly founders who designed an architecture they could not have afforded at retail and then forgot retail was coming.

A few disciplines, if you do take it. Screenshot the covered-SKU language on day one and keep the PDF. Google has silently changed credit scope mid-program before. Enable BigQuery billing export so you can pull SKU-level data later. Deploy the billing-disable Cloud Function before you deploy your application. Request a meeting with your Startup Success Manager 60 to 90 days before Y1 ends, walk in with a credible AWS or Azure migration plan in hand, and ask for a private pricing agreement or a bridge credit pool. Founders who do this routinely get 20 to 40 percent off retail for a multi-year commit. Founders who do not ask get retail.

The version of this program I would take is the one where I treat the credits as a discount on a workload I have already underwritten at full price. The version that has bankrupted people is the one where the credits are the plan. Take it with eyes open or do not take it.