The Startup Trap
The most dangerous startup decisions are rarely obviously bad ones.
A big customer brings revenue. A platform gives you leverage. A new hire adds capacity. A feature helps close a deal. Scaling accelerates growth.
The problem often appears one or two decisions later.
The customer starts shaping the roadmap. The platform becomes impossible to leave. The hire institutionalizes an assumption. The cheap feature becomes a permanent obligation.
I went through Itamar Novick and Simeon Simeonov’s 75 startup anti-patterns and found a common thread: startups get trapped when reasonable decisions quietly reduce their future choices.
The interesting question isn't just “Is this a good decision?”
It’s “What path does this decision put us on?”
A startup has ten employees and six months of runway. A large prospective customer appears and offers a contract worth $500,000, but wants a few changes to the product. The changes aren’t unreasonable, the customer is credible, and the money would materially extend the company’s runway.
Of course you take the deal.
Engineering builds the requested features. The customer becomes the company’s most important account, so supporting it becomes a priority. Sales now has a recognizable logo and starts approaching similar companies. Those prospects have similar requirements, so the product becomes more enterprise-friendly. The next hire has enterprise experience. The fundraising deck now describes the company as an enterprise platform because, increasingly, that’s what the numbers show.
Eighteen months later the founders are running an enterprise software company.
Perhaps that’s a great outcome. But notice something important: nobody necessarily decided to build an enterprise software company. A series of individually rational decisions made the decision for them.
This is what makes Itamar Novick and Simeon Simeonov’s collection of 75 startup “anti-patterns” interesting. The list includes familiar mistakes like premature scaling, elephant hunting, featuritis, death by pivot, founderitis and platform risk. Taken individually, many are useful warnings. Taken together, though, they point to something more fundamental about how startups go wrong.
The most dangerous decisions aren’t usually bad decisions. They’re reasonable decisions that change the environment in which the next decision gets made.
Decisions create their own gravity
We tend to think about startup decisions as discrete events. Should we build this feature? Take this customer? Hire this person? Raise this round? Build on this platform?
The usual analysis compares the immediate cost with the immediate benefit. The feature costs two weeks and may close a customer. The hire costs $200,000 and should increase sales. The platform saves six months of engineering. The funding round gives us two more years.
But important startup decisions rarely end when the decision is made. They create new constraints, incentives and constituencies that influence everything that follows.
Take a feature that requires two days to build. In isolation, the cost is almost irrelevant, particularly now that software development is becoming cheaper. But once customers use the feature, sales can promise it. Support has to understand it. QA has to test it. Future architecture has to remain compatible with it. Removing it becomes a product decision of its own.
The cost of building the feature fell dramatically. The cost of having decided to have the feature did not.
This distinction matters more as execution gets cheaper. The obvious conclusion from cheaper software is that startups should experiment and build more because the cost of doing so has fallen. That’s partly right. But lower execution costs also lower the friction that previously forced companies to prioritize. When saying yes costs two days instead of two months, companies can accumulate decisions faster than they accumulate understanding.
The bottleneck moves upstream. The scarce resource is no longer simply the ability to build. It’s the ability to decide what deserves to become part of the company.
This is why featuritis and overengineering are better understood as decision problems than engineering problems. Building something isn’t merely an expenditure of engineering capacity. It’s the beginning of a path.
Revenue chooses a direction
The same dynamic explains one of the stranger startup anti-patterns: bad revenue.
It seems almost absurd to tell an early-stage company that revenue can be bad. Revenue extends runway, validates willingness to pay and reduces dependence on investors. All of those things are true.
But revenue also has gravity.
Return to our $500,000 customer. Once that customer represents a meaningful portion of the company’s revenue, prioritizing its needs is rational. Once those needs have shaped the product, finding similar customers is rational. Once similar customers become the sales pipeline, hiring people experienced in serving them is rational.
At no point does anyone need to make an obviously bad decision. In fact, refusing each next step may appear irresponsible given the previous one.
This is what makes “elephant hunting” more interesting than simply warning startups not to chase big customers. The first-order consequence of landing an elephant is revenue. The second-order consequence is that the organization starts adapting itself to hunt elephants.
Revenue therefore has strategic characteristics beyond its amount. A million dollars from one customer requiring continuous adaptation tells you something very different from $200,000 generated by hundreds of customers independently discovering, purchasing and successfully using the same product. The former may be financially more valuable today; the latter may contain considerably more information about what the company could become.
The useful question isn’t simply whether revenue is good. It’s what future decisions this particular revenue will make seem rational.
Scaling turns beliefs into structure
Premature scaling follows the same pattern.
The usual argument against scaling too early is financial: hiring ahead of product-market fit increases burn and shortens runway. That’s true, but cash is reversible in a way organizations are not.
Imagine a founder believes a particular customer segment is the right market. With five employees, that belief is still cheap. They can test it and change their mind.
Now hire a VP of Sales and ten account executives around that assumption. Territories appear. Quotas appear. Sales collateral appears. Customer success starts supporting the customers sales brings in. Product receives requests from those customers. Managers are hired to manage the people serving them.
What began as a hypothesis has become an organization.
And organizations don’t evaluate hypotheses neutrally when people’s jobs depend on the answer.
This is the deeper cost of premature scaling: it institutionalizes beliefs before those beliefs have earned the right to become institutions. The company gradually loses the ability to distinguish between “this is true” and “we have built ourselves around this being true.”
This suggests a better principle than simply staying lean: keep assumptions cheap to reverse until the evidence justifies making them expensive to reverse.
There is an important corollary. Optionality itself isn’t the goal. Once something genuinely works, continuing to preserve every possible direction becomes costly. Competitors accumulate distribution, customers develop habits, and temporary technological advantages disappear. At some point, concentration beats flexibility.
The strategic problem is therefore not maximizing optionality. It is deciding when you know enough to spend it.
Borrowed leverage
Platforms provide perhaps the cleanest example of this trade-off.
A startup building on Apple, Shopify, Google, OpenAI or another large ecosystem can acquire capabilities that would otherwise require enormous amounts of capital and time. Avoiding that leverage simply because dependency is theoretically dangerous would often be a terrible decision.
The interesting problem comes later.
As the startup succeeds, it naturally becomes more optimized for the platform. Its product uses platform-specific capabilities. Its engineers develop specialized knowledge. Customers arrive through platform distribution. Economics are modeled around platform pricing. What began as a shortcut becomes part of the company’s architecture.
The paradox is that the platform relationship may become more dangerous precisely as it becomes more successful.
If the platform changes its economics when the startup has ten customers, changing direction is painful but possible. If it does so when the startup has ten million users whose behavior depends on the platform, the theoretical option to leave may have almost no practical value.
This is why platform risk shouldn’t simply be measured by the probability that a platform changes the rules. The more interesting question is whether success on the platform creates bargaining power or merely increases switching costs. If it is the latter, growth is simultaneously increasing enterprise value and strategic fragility.
The same logic applies far beyond technology platforms. A dominant distribution partner, a critical supplier, a single acquisition channel or even one unusually productive employee can create the same structure: leverage today in exchange for constrained choices tomorrow.
When the evidence changes
This brings us to perhaps the hardest pair of anti-patterns: pivoting too quickly and persisting too long.
Founders are told to have conviction and listen to the market, to move quickly and be patient, to ignore skeptics and follow the evidence. These statements can all be correct because none tells you what to do when the evidence is ambiguous.
Suppose a product launches and sales are poor. The market may not care about the problem. Or the company may be targeting the wrong customer. The positioning may be wrong. Distribution may be ineffective. Pricing may be wrong. The product itself may be inadequate.
“We aren’t selling enough” is an observation. It isn’t yet a diagnosis.
The death-by-pivot founder interprets every disappointing observation as evidence against the highest-level strategy. The escalation-of-commitment founder does the opposite: every failure is attributed to execution so that the original strategy never has to be reconsidered.
Both are making the same analytical mistake. They aren’t identifying which assumption the evidence actually tested.
This is why I prefer to think about startup strategy as a hierarchy of hypotheses rather than one large hypothesis called “the company.” A weak acquisition channel should cause you to reconsider the channel before reconsidering the product. Customers consistently understanding the product but refusing to pay should eventually cause you to question something deeper. The response should be proportional to what was actually learned.
This preserves something startups routinely destroy: accumulated knowledge. A pivot that changes five assumptions when the evidence invalidated one throws away information almost as effectively as refusing to pivot at all.
The company eventually learns the founder
There is one final anti-pattern that operates differently because it affects the mechanism making all the other decisions.
Founder arrogance, confirmation bias, groupthink and yes-men are normally described as psychological problems. That framing understates their importance. The real problem is that organizations adapt around the people who lead them.
Imagine a founder who reacts badly when an assumption is challenged. Nobody needs to explicitly decide to hide bad news. Employees simply learn that challenging assumptions is expensive. The most capable people learn first.
Over time, presentations become more agreeable. Ambiguous evidence gets framed positively. Problems arrive with solutions attached or don’t arrive at all. The founder can actually become more confident because the information reaching them increasingly confirms their worldview.
The same thing happens when a technical founder consistently rewards product discussions while avoiding distribution problems, or when priorities change after every investor conversation. The organization observes what gets attention and adapts.
Eventually founder psychology becomes company architecture.
This is more dangerous than ordinary confirmation bias because the founder is no longer merely interpreting information selectively. The organization has started selecting the information before the founder ever sees it.
The trap
This is the thread connecting many of Itamar Novick and Simeon Simeonov seemingly unrelated anti-patterns.
Featuritis isn’t really about too many features. It’s about small product decisions accumulating future obligations.
Bad revenue isn’t really about revenue. It’s about today’s customer changing which customers the company will be equipped to serve tomorrow.
Premature scaling isn’t primarily about burn. It’s about converting uncertain beliefs into organizational structure.
Platform risk isn’t simply that somebody else controls the platform. It’s that success can progressively increase the cost of independence.
And founderitis isn’t merely about ego. It’s about the organization gradually reshaping its information flows around the founder’s beliefs.
In each case, the first-order decision can be entirely rational. The danger appears one or two decisions later.
That’s why anti-patterns are useful to founders. Not as a checklist of things to avoid—almost everything on the list is appropriate under some circumstances—but as a reminder that the relevant unit of analysis isn’t the decision itself.
It’s the path the decision puts you on.
Startups have one enormous advantage that incumbents spend billions trying to recreate: very little is fixed yet. The product can change, the organization can change, the customer can change, the business model can change. Early decisions consume pieces of that flexibility in exchange for revenue, speed, scale or leverage.
That’s exactly what they’re supposed to do.
The mistake is spending that optionality before you’ve learned enough to know what you’re buying with it.