
Every startup founder has experienced the phenomenon: things feel like they are moving forward. The team is working hard. Revenue is growing. The product is shipping. And then suddenly, a crisis that feels unexpected but was, in retrospect, signaled weeks or months earlier by metrics and operational patterns the team was too busy or too optimistic to read clearly.
Thank you for reading this post, don't forget to subscribe!Google Cloud’s Vice President for startups has been working with early and growth-stage companies long enough to recognize the specific patterns that precede serious operational, financial, and product problems. The check engine light metaphor is apt: the signal appears before the breakdown, but only if you know what you are looking for.
The most fundamental financial health metric for any startup is the relationship between burn rate and revenue growth. When burn is accelerating because the company is investing ahead of revenue in preparation for a growth inflection, that is a strategic choice. When burn is accelerating because cost controls have loosened, hiring has outpaced growth, or efficiency metrics are deteriorating, that is a warning sign.
The specific pattern to watch is the ratio of new ARR added per dollar of net burn. If this ratio is declining quarter over quarter, you are becoming less efficient at converting investment into growth. That trajectory, if uncorrected, leads to a funding situation where you need to raise more capital at a lower valuation or cut costs dramatically.
The 18-Month Rule: Google Cloud’s VP recommends that founders always know their runway to the day and maintain a minimum 18 months of runway before beginning any fundraising process. Founders who start fundraising with less than 12 months of runway negotiate from weakness, which affects both valuation and terms in ways that compound through subsequent rounds.
When more than 25 to 30 percent of a startup’s revenue comes from a single customer, the business has a structural vulnerability that investors and boards should be treating as a critical warning sign regardless of how strong the relationship appears. Customer concentration creates dependency that can materialize as crisis without warning: contract non-renewal, acquisition of the customer by a company with different vendor preferences, or a market downturn that causes the customer to cut spending.
The warning light here is not just the concentration itself but the trajectory. A company that had three major customers 12 months ago and now has revenue concentrated in one has been losing diversification faster than it has been adding it, which suggests a sales or product problem that pure revenue growth metrics might obscure.
One of the most deceptive patterns in startup metrics is the combination of strong new customer acquisition with quietly deteriorating retention. When you are adding customers faster than they are churning, total revenue grows. But the underlying business is becoming less healthy: each cohort of customers is retaining worse than the previous one, the product-market fit signal is weakening, and you are on a treadmill that requires continuously accelerating acquisition spending to maintain growth.
The specific metric to track is not just overall churn rate but cohort-level retention curves. If the retention curves of recent cohorts are below those of earlier cohorts at equivalent time intervals, product-market fit is deteriorating for whatever reason: the market has shifted, the product has not kept up, or acquisition is reaching less-qualified customers.
Engineering teams that are shipping features rapidly but not moving retention or engagement metrics are a warning sign. Feature velocity is only valuable if the features being shipped address the specific reasons customers are not retaining or are not expanding their usage.
The check engine light here is a growing disconnect between engineering output and product metrics. If the team spent the last quarter shipping 15 features and retention did not improve, the problem is not a lack of building. It is either building the wrong things or a more fundamental product-market fit issue that feature development cannot resolve.
Some voluntary attrition is normal and healthy in fast-growing startups. Attrition that clusters in specific teams, functions, or tenure cohorts is a diagnostic signal. When multiple people leave the engineering team within a short window, there is a management, culture, or technical direction problem in that team. When a company’s tenure 18-to-24-month cohort shows unusually high attrition, there may be a promotion pipeline or career development problem.
The check engine light pattern is correlation and clustering, not just rate. A 20 percent annualized attrition rate distributed evenly across the company is different from a 20 percent rate concentrated in the people who are 18 months in. Only one of those patterns tells you something specific.
As startups scale from 20 to 50 to 100 people, the informal communication structures that worked at smaller scale break down. Engineering does not know what sales has promised customers. Customer success does not know what product is building. Finance does not know about commitments made by business development. These communication failures produce operational problems that appear as crises but are actually system failures.
The warning sign is the first time a significant problem is traced back to someone not knowing something they needed to know. That incident is not the problem. It is the first visible symptom of a structural communication breakdown that will produce more incidents if not addressed.
Bottom Line: Every startup has warning signs before its crises. The founders who catch them early have options that founders who ignore them do not. Google Cloud’s VP is right that the check engine light almost always comes on before the engine fails. The question is whether you are watching the dashboard.
Related: AI Startup Equity at Two Prices | What Investors No Longer Want in AI SaaS | Decagon $4.5B Valuation
Google Cloud for startups program






