DEV Community

Lingchong Hu
Lingchong Hu

Posted on • Originally published at lingchong.substack.com

The Ice Cream Stands in the Middle of the Beach: why rational AI startups fail together

This is not a startup guide. It is closer to something I can finally put into words after a few years of building, watching, and getting things wrong myself.

AI has made it much cheaper to build. The financing and organizational logic around startups has not caught up.

The graveyard of wrappers

In the first wave of the AI boom, a product could wrap a large model, add some prompt engineering, put a new skin on a chat box, and still raise a decent round. Model capabilities jumped every few months, and the demos looked magical.

Looking back, most of those products are gone. Investors have narrowed their range, for understandable reasons. If your moat is a prompt, the next model release is your competitor. Jasper raised $125 million at a $1.5 billion valuation in October 2022 to sell AI copywriting; ChatGPT arrived a month later and gave the core of that product away. When Claude Code and Codex arrived, the same thing happened to a generation of coding tools. None of these startups had suddenly become worse at what they did. The underlying models had simply absorbed into infrastructure the capability they were charging for.

A model upgrade is not a normal competitor. A normal competitor still has to understand your product, reproduce the workflow, and fight for customers. A model provider only has to move capability one step forward, and an entire section of your product can disappear. Windsurf learned a harsher version of this in 2025: in the middle of its $3 billion acquisition by OpenAI, Anthropic cut off its Claude API access, the deal collapsed, and the company was carved up — Google licensed the technology and hired the founders, and Cognition took what remained. The model provider is your supplier, your competitor, and sometimes the party that decides how your story ends.

The complication is that some of the fastest companies of the past two years are also wrappers. Cursor wraps models. Perplexity wraps models. Harvey wraps models. So the line is not wrapper versus not-wrapper. The line is what you actually own: a capability the model does not have yet, which the next release will quietly take back, or a workflow, distribution, and industry knowledge that no model release automatically grants. Too many teams mistook the first for the second — they took the small gap between what a model could not do yet and what it would soon do for a durable market.

The investor's ledger did not change

A graveyard of products does not mean the Silicon Valley ledger has changed. A venture investor can still accept ninety-nine zeros out of a hundred bets if the remaining company becomes a unicorn. For that investor, the math is perfectly rational. The investor is not buying a quiet little business that earns steady money. The investor is buying an option on changing an industry.

That means the familiar startup game still rewards the biggest story. You can build patiently, but if the story is not large enough, it is hard to raise enough money for the traditional startup setup. Tenfold or hundredfold growth, a platform, and network effects fit the ledger better than: “Let us solve one small, real problem first and see whether anyone pays.”

The problem is not storytelling. Every financing pitch has to describe a future. The problem begins when the future story arrives before today's evidence. Then the team starts arranging reality to protect the story instead of letting reality change it.

Pushed far enough, arranging reality becomes literal. Builder.ai raised about $450 million and collapsed in 2025 after an internal probe restated its revenue to roughly a quarter of what had been reported. The founder of Nate, an AI shopping agent that turned out to run on a call center, was charged with fraud. Those are extreme cases, but they grew from an ordinary seed: a story that had to stay bigger than the evidence.

When burning money becomes the reason to raise it

The usual story says a startup raises money to survive. A team needs salaries, an office needs rent, and the company needs recruiting, management, and marketing. So the company has to keep raising the next round.

I have come to think the causality is often reversed.

For many teams outside embodied AI, robotics, and hard technology, moving from a demo to an early product, contacting early customers, and testing demand does not require a room full of employees. Two or three energetic founders, plus two or three Claude and Codex accounts, can already travel that distance.

Hiring the team and taking the space first creates a large survival cost. That cost then proves that funding is indispensable. After the funding arrives, expanding the team starts to look like the reasonable thing to do because the money has to be spent.

Burning money justifies fundraising, and fundraising creates more burning. Soon the team no longer exists to test demand. The demand has to look enormous so the team can continue to exist. An assumption that should have been disproved in two weeks becomes a strategic direction nobody can admit is wrong because dozens of salaries now depend on it.

The fantasy of replacement

AI has also made the word “product” feel emptier. Most products do not create a blue ocean from nothing. They imagine replacing part of an existing way of working. Automated job-search agents and dating agents were popular ideas when I was in school. Both relied on large-model capability and the same inference: the old process is annoying, so people must want to hand it to an agent.

But a tedious process does not automatically need to disappear. The process itself may carry embedded value that only insiders of that industry really understand — sometimes it is an unspoken rule, sometimes someone's interests depend on the friction staying exactly where it is. And even when a process should disappear, users may not want it removed through an agent.

A project also starts out loaded with assumptions nobody has tested yet. Take a job-search agent. It has to capture current job listings across platforms, which means solving access to APIs and data. It has to keep obtaining that data legally, which brings platform terms and compliance into the product. It has to understand the user's background. It then has to match that person to suitable roles. Finally, it has to submit applications in one step while dealing with different application systems, identity checks, and anti-automation defenses.

Any one of those five links can disprove the whole idea. If there is no legal way to secure the data source, that is not a small issue to optimize later. It rejects the proposed implementation. If users do not want to hand their career judgment to an agent, better marketing copy will not rescue it. The demand assumption was wrong.

This is why actual implementation has to test whether demand is real. At that point, a team should not keep burning money to defend the old story. With only two or three founders and a few Claude and Codex accounts to support, it can pivot quickly and test a different need.

Thus: payment, not willingness to pay.

“I would use that if it existed” and “I might buy it when it is ready” are not validation. When an early user actually pays, you have evidence that you found something beyond politeness, curiosity, or excitement about new technology. You found work that is worth solving.

The most important technical members of the early team

Who belongs on an early team depends on the largest risk you need to retire.

If the product is easy to build but you do not know whether anyone will pay, the risk is demand. The testing tools are you and your Claude, and the reachable audience around you. If the demand is obvious but you do not know whether the thing can be built—robots, rockets, or new drugs are the examples I have in mind—then the risk is technical, and engineers are the testing tool.

The absurdity of the wrapper boom was that many people were building demand-risk products with a technical-risk cost structure. They hired a room full of engineers to test a need that could have been disproved without that room.

At the beginning, Claude and Codex may be the most important technical members of your team, alongside early users willing to try the rough product. A real technical adviser who understands the field can still matter a great deal. That person can review the work—really, review both you and your Claude—and point out where the implementation misses an industry standard or where an outsider cannot see the trap.

More specialists should enter when early users have arrived, real payments are happening, the direction of iteration is clearer, and servers, SEO, marketing, and a sales pipeline have to run. An engineer may take over technical work from a founder. The next person may work in marketing, sales, HR, or management. It may be someone dedicated to fundraising so the founders can focus on market share and keeping the team supplied.

Demand moves quickly now, and it often has to be tested in parallel. That makes the pool around the founders more important than a fixed headcount. The pool can include technical people and people from different industries who hold real needs. You connect the right person when the need appears. Unless the ambition is extraordinarily large—building a humanoid robot and beating every competitor, for example—you usually do not need to support a technical team before you have validated demand.

Why every stand moves to the middle

To put it a little harshly, founders who sell stories are doing what businesses have always done: trading on an information gap. They use the investor's incomplete knowledge of the technology and the industry to obtain a large investment. The better projects may reach a Series A or B. The worse ones may find investors whose information gap is so wide that nothing comes back at all.

It is a miserable investment experience. Investors do not understand what the teams are doing. The teams do not understand where the future is. Then both are flattened by the next model upgrade.

Blaming founders alone would be too easy. Investors rationally buy power-law stories because one win in a hundred can be the best outcome for a fund. Founders rationally tell the stories investors will buy because without those stories they cannot fund the traditional team they were taught to build. Talented people rationally move toward the hottest, best-funded narratives because the salary, equity, and next job look safer there.

Each side is playing a rational game. Together, they can produce the worst result for everyone.

Imagine a very long beach. Every ice cream seller wants to be closer to the largest number of customers, so one stand after another moves toward the middle. The first few may make good money. Later, all the stands crowd the center. Customers at the edges do not want to walk that far, while the center has more stands than customers. Each seller tried to maximize an individual outcome. The beach did not gain much business; it gained a row of stands splitting the same crowd.

That is the question I care about as a founder: if AI has already changed how we produce, can we choose a way of building companies that fits the new production method instead of crowding around the same product in the middle?

The path we have been testing

Our starting point is simple. Needs are free to move and can be explored in parallel. Technical teams should be attached when needed, while Claude and Codex can carry much of the earliest implementation. One person can own the need. Technical help can join when time allows, or the founder can complete the first validation alone.

The need has to connect to a real workflow in a real industry. We use AI to reproduce the work, then pick up the small problems that have become cheap to solve in an age of abundant productive capacity. Word and Excel files can be read automatically. Images can go through OCR. Scattered work can be brought into one place. We let the data move, then look for the part that deserves more attention.

The person connecting us to the industry has to understand it for real. That person needs access to real needs and must be able to explain the upstream and downstream work, the details, and the quiet rules outsiders miss. People have inertia. Personal habits are hard to change; industry habits are tied to a chain of interests and can be painful to move. A clever prototype does not make that resistance disappear.

Technical people can enter after the person responsible for demand has drawn a prototype in Figma or Claude and made the workflow clear. We call this project-by-project joining of demand and execution an organization that looks like a law firm: the person who understands the industry and holds the client finds the need and owns the outcome; the people who can deliver connect when needed and take responsibility for the implementation.

A founder in this model is closer to the conductor of a concert, bringing in the resource the work needs at that moment. If agents can drive markets one day, perhaps even marketing can be removed. For now, people still have to uncover needs, find investment, move the market, and work with customers.

This pooled way of working also uses the information gap created by rapid AI iteration. You enter an industry, obtain the important demand information, use the agility of a small business to make a stronger product first, and then compete with the old products in that industry through disruptive technology, the way Dollar Shave Club once went after Gillette's expensive razors.

This route is not free. Bootstrap validation makes founders carry the opportunity cost themselves. There may be a long stretch without salary, without the glow of a funding announcement, and without the emotional reassurance of a large team moving fast. You trade your own time for a low burn rate and accept an uncertain return in exchange for the freedom to keep pivoting. That cost belongs honestly in the ledger.

A company should earn its reason to grow

The kind of modern startup I believe in now does not build a large team to match a story and then pray that the market finds a reason for the team to exist. It keeps looking inward and outward with some humility. Build the assumption so reality can disprove it. Move forward when someone pays. Bring in the kind of expertise the next step requires.

There is still room for a story, but it should extend from evidence that has already happened. It should not force everyone to protect a future fiction. The opportunity AI gives founders is not only faster code. It lets us replace “believe first because we need to raise” with “build first, sell first, then decide whether this deserves belief.”

You do not need to own a company before you are allowed to look for demand.

Real payment comes first. Only then does a company have a reason to grow around it.

I would genuinely like to hear about the real workflow you need help with—not the impressive pitch, but the work that keeps resisting the tools you have. Tell me where it breaks and what you already do to get through it.

The site where this essay first appeared, lingchonghu.com, is physical evidence for the argument: 29 demos, the whole site in Chinese and English, and a journey system, made by a few founders with Claude and Codex accounts. That is what low-cost validation looks like in our own hands.


Originally published on my Substack.

Top comments (0)