DEV Community: Lingchong Hu

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

Lingchong Hu — Sat, 01 Aug 2026 19:18:51 +0000

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.

Every iPhone leak spoiled a launch. This one published Apple's business model.

Lingchong Hu — Tue, 07 Jul 2026 19:00:22 +0000

A few weeks ago a ransomware crew called World Leaks dumped more than 200,000 files — roughly 630GB — onto the dark web, exfiltrated from Tata Electronics, one of the contract manufacturers assembling iPhones in India. Not spy shots of an unreleased phone. The dump reportedly includes full mainboard schematics for the iPhone 18 Pro, component spec sheets, bills of materials covering hundreds of suppliers, per-part purchase prices, order allocation ratios, the factory's own yield records on incoming parts — even drop-test photos of prototypes.

Tata's public statement said business operations were unaffected. Technically true, and completely beside the point. Researchers reviewing the dump note the attackers appear to have sat inside the network for weeks at minimum — documents run through this May, event logs span years — with time to scan, filter, and package at leisure, and no alarm ever fired. One analyst's line stuck with me: this wasn't a smashed window. Someone lived in the house for two weeks before anyone noticed the lock was broken.

Why this is different from every iPhone leak before it

Apple's hardware gross margin runs around 36–39%. The Android average is closer to 12%. The chip giants on the same phone — TSMC, Samsung, Micron — each take home maybe 3–5% of an iPhone's value. That gap isn't explained by technology alone. A big part of it is an information structure Apple spent two decades building: one-way transparency.

Every supplier opens its books to Apple completely — materials, labor, depreciation, yield, down to the utility bills. Apple's resident teams verify the numbers on site, then reverse-engineer a purchase price that keeps the supplier exactly profitable enough to stay alive. And between suppliers, strict isolation: the company making a screw never learns what the other company making the same screw quoted, or what share of the orders it got.

That asymmetry is the machine that funds the margin. The leaked BOMs turn it inside out. In the files, the same SIM tray shows one supplier at $0.39 and another at $0.395. Two suppliers of the same screw differ by a fraction of a hundredth of a cent. Trivial numbers — until you multiply by tens of millions of units, across hundreds of parts. That spread is the margin. It's also every supplier's survival line, now printed where everyone can read it. The dump even includes the manufacturer's own test records of whose incoming parts had yield problems — every vendor's quality reputation, publicly executed in one file.

The blast radius is measured in years, not news cycles

A design leak costs you one launch cycle of suspense. This is a different class of damage:

Suppliers now see each other's cards. The resentment that information isolation kept suppressed — who got the bigger allocation, who got the extra half-cent — surfaces at the next negotiation. For every part. Simultaneously.

Competitors get a months-early head start. They used to reverse-engineer Apple's supply chain by tearing down phones after launch. Now they get the complete component map and pricing reference before launch — plus, more dangerous, a directory of exactly which parts are single-sourced with no redundancy. A printed list of chokepoints someone could go squeeze.

The technical window compresses too. The dump reportedly details the first 2nm-class SoC and a shift from PoP stacking to WMCM packaging, with full multi-layer board schematics. The kind of thing rivals normally pay a teardown lab and several months for.

The caveat almost nobody discusses: leaked ≠ true

Here's the twist I keep chewing on. Everyone racing to download and analyze the dump quietly assumes the files are authentic, complete, and current. But the timestamps reportedly cluster around February to April — when the iPhone 18 Pro would still be in early validation. Trial-stage quotes are not mass-production contract prices. Supplier lineups turn over between validation and ramp.

If you re-price your contracts, re-plan your roadmap, or pick a fight with your biggest customer based on this dump as if it were Apple's final hand, you may be playing exactly the move that whoever released the files wanted you to play. In any high-stakes game, what gets released, when, and to whom can itself be a move. The failure mode that kills you isn't your cards being seen. It's playing someone else's fake cards as if they were real.

What I take away as a builder

The most brutal detail of the whole story: Apple's information wall wasn't breached by a smarter competitor. It was pushed over from inside a partner Apple itself chose, on infrastructure that was supposed to run Apple's own security requirements. Twenty years of protocol, undone by one contractor's unwatched network.

I've written before that models are rentable and features are cloneable, so durable advantage has to live somewhere structural. This event is the hardware-world corollary: if your moat is an information asymmetry, it is one breach away from zero. A spreadsheet is not a structure. Notice what Apple keeps even after the leak — the cost-auditing capability, the multi-supplier coordination, the yield-ramp muscle. None of that fits in a file, and none of it leaked. The files hurt; the capability survives. The uncomfortable question for the rest of us: how much of your edge lives in files?

If you build things and think about moats, information games, or how much of your company fits in a spreadsheet — I'd genuinely like to compare notes. Say hi: lingchong@iterant-ai.com.

Everyone's competing on better answers. The answer side isn't where the money is.

Lingchong Hu — Sun, 05 Jul 2026 18:21:39 +0000

Models are becoming utilities and apps get cloned in a week. I think the moat is one layer up — before you've even finished the thought.

The whole industry is grinding on one thing right now: making AI answer better. Bigger models, sharper prompts, another wrapper app every week.

The more I build, the more convinced I am that the valuable part isn't on the answer side at all.

Look at the two layers everyone's fighting over. The model layer is turning into a utility — you rent it by the token, and everyone rents the same thing. The app layer is a cloning race: one feature takes off, and someone ships a copy within the week. Long term, neither layer is defensible. You can't build a moat out of something everyone can rent, or something anyone can copy.

So where does a moat actually fit?

In a place almost nobody is seriously working on: the thought you haven't finished having yet.

Every AI tool today stands downstream of "you already figured out what you want." You sort the idea out in your head, translate it into a prompt, and feed it to the machine. We even turned that translation step into a skill with a name — prompt engineering. Which, if you stop and look at it, is backwards: it's the human accommodating the machine. That's not a stable arrangement. It never has been, for any technology.

Upstream of all that is the moment an idea first surfaces — when you couldn't even articulate it to yourself yet. Whoever catches you there decides everything that happens after: which model gets called, which app opens, which path you take. The entire chain downstream gets routed by that first touch.

We've seen this movie. The search box won the internet not by having the best pages, but by owning the first moment of wanting to find something. Own that moment and you distribute everything behind it.

The intent layer is this generation's search box. Whoever owns it takes the biggest piece on the table.

So what is it, concretely?

A translation layer: from the fuzzy thing in your head to something a machine can execute precisely. It doesn't belong to any model or any app — it sits in front of all of them. Today that translation is done by hand, by you, and we call it "writing prompts." What I want to do is take that job away from the human and hand it to the machine.

Three concrete bets on how

One: stop making the human explain. Flip it — let the machine read your context and work out what you're doing. Most of what you want is already written in the thing you're looking at and acting on. You shouldn't have to say it again.

Two: do this where the context is richest. That's why my first move is the browser, not an input method. An IME only knows you're typing. The page knows which box you're typing into, against what content, for what purpose — that's an order of magnitude more signal. At this stage, depth of context beats breadth of coverage, and it's not close.

Three: in the middle you need a component whose only job is recognizing intent — compressing a pile of messy context into one precise, executable intent that everything downstream can run with. That's the core I'm still grinding on myself. I won't pretend it's solved.

One line I hold hard

The system only goes as far as preparing the intent. Whether to fire it — that last press — is always yours. I'll pave the road right up to your feet. I won't take the step for you.

This one isn't written for people passing by. If you're seriously thinking about where this layer lives and who ends up owning it — I want to meet you. Say hi: lingchong@iterant-ai.com.

We let AI write the code. We just don't let it check its own work.

Lingchong Hu — Sun, 05 Jul 2026 18:21:26 +0000

Everyone's chasing a new word for "AI engineering." The bar it's supposed to clear never actually moved.

AI's had three names for "engineering" in about as many years.

First it was prompt engineering — learn to write the magic words. Then, around the middle of 2025, everyone pivoted to context engineering — stop fussing over wording, start filling the context window with the right stuff. Now, early 2026, the word is harness engineering — the layer wrapped around the model: tools, memory, state, error recovery, verification, permissions.

Every time the word turns over, a wave of people panic that they've fallen behind. I've stopped reacting to it. Because the more I build, the more obvious it gets: the word keeps changing and the thing underneath doesn't.

Here's the thing underneath. Whatever you call the tooling, you're always crossing the same gap — from "the AI produced something that runs" to "I'll put my name on this, and if it breaks in production, that's on me." Getting across that gap is the entire job. The new words are just the industry renaming the same crossing, over and over.

So instead of arguing about vocabulary, let me just show you ours — the actual rules four of us use to get across that gap. Almost none of it is clever. That's kind of the point.

Rule 1: nothing starts without a finish line

If we can't say what "done" looks like before we begin, we don't begin. Then we keep cutting the task down until each piece is small enough to be verified on its own. And at commit time, a hook fires automatically and runs an informedness check — we call the threshold τ — that makes sure a human actually understands every necessary change in that commit. Necessary, not every line. We don't make anyone re-read the AI line by line; that both distrusts the tool and doesn't scale. The point is to pull the change up to the one layer of abstraction a person should own, and be genuinely clear at that layer.

Rule 2: the threshold slides with the blast radius

A low-risk, easily-reversible change gets a light touch — we lean on fast rollback and let it move. The moment something is irreversible or high-impact — data, billing, permissions, migrations — the threshold goes to the ceiling: higher informedness required, and we cross-check it with a second model on a different base. Speed and safety aren't two different settings here. They're two ends of the same knob, and we turn it by consequence instead of turning it all the way to "slow" or all the way to "gamble."

Rule 3, the hard one: verification has to be independent

Independent means the thing that checks is not the thing that wrote. We stack two layers. The first is you — but only if you're genuinely informed enough about this piece, which is exactly the threshold from the last rule. A human who actually understands the change is the first independent verifier. The second layer is a model on a different base, checking the first one's work. The pattern the industry's settling into right now is roughly this: Claude Code writes, Codex checks. Different training, different blind spots — so the blind spots don't line up, and something actually gets caught.

The one thing we never do is let the AI check its own work. Change the prompt all you like; it's still reasoning the same way it did when it wrote the bug, so the blind spot sits there untouched.

The part we never hand off

There's one part of all this we never hand off. You have to know when to let the AI write and when to specify the technical detail by hand — that judgment is learnable. But the actual logic of the problem, the clear line of reasoning through it — that can't be delegated to a model. That's yours, always.

And there's more than one honest way across the gap. Just among four of us the styles diverge hard. One of us works architect-first: before the agent touches anything, he's already cut the thing into layers in his head and knows where every piece goes — heavy on that first verifier, the informed human. Another is bolder: let the agent build it, see it run, then throw several different models at it to check — heavy on the second verifier, the independent model. I used to think those two were opposites. They're not. They're just different weightings of the same two independent checks. We keep both around. Whatever lands the requirement safely is good AI engineering, full stop.

So what's the actual moat?

Not the vocabulary. You may have already noticed the whole thing I just described is what people are now calling harness engineering — a name that only caught fire in 2026, and honestly, we're just starting to figure it out ourselves. I'm not going to pretend we've been doing this all along. prompt, context, harness — and there'll be more words after these. The moat is who can take each new tool and each new name and internalize it fastest into something you can actually ship. Keep up with that — the speed of turning novelty into deliverable work — and you keep up with the whole wave.

If you're wrestling with the same thing — trying to ship AI you can actually stand behind, or just working out your own delivery process and want to compare notes — those are my favorite people to talk to. Say hi: lingchong@iterant-ai.com.

In the AI era, your company will look like a law firm

Lingchong Hu — Fri, 03 Jul 2026 19:49:59 +0000

Everyone says AI lets one person do a team's work. True — but I think most people draw the wrong conclusion from it.

Ten years ago, "being able to build the thing" was itself a moat. People who could write software — and actually finish it — were scarce. Shipping alone made you win.

AI has pushed the cost of building to the floor. Being able to build is no longer the moat. It's the entry ticket.

So where did the game move? To two things: whether you can spot a demand that actually exists, and whether you can stand behind the outcome — all the way to the end.

Here's the trouble: these two almost never live in the same person. People who understand demand usually aren't the ones who can do top-tier work. People who do top-tier work are usually far from the client and the market.

There's a hundred-year-old structure that solved exactly this: the law firm. On one side, partners — they hold the client, understand what the client actually needs, and answer for the outcome of the case. On the other side, associates — they do the casework. Demand and execution get split in two, each pushed to its best, then welded back together by one thing: accountability.

The more I think about it, the more I believe this is the right shape for an AI-era company. It's how we actually run today: I'm up front catching demand, talking to clients, owning outcomes; three architects behind me land the projects one by one and make them solid.

And one thing I'm increasingly sure of: technical service will standardize, the way legal service did. As coding agents get stronger, the "build it" end looks more and more like a repeatable assembly line. Who does the building matters less and less.

Which is exactly why the game moves upstream. The hard, valuable thing now is running the whole chain: from catching a real demand, to delivering it in an increasingly standard way, to answering for the result at the end. Getting that chain to run smoothly — that's the real fight ahead.

Curious how this plays out where you work — who catches the demand, who builds, and who answers for the outcome when it ships? If those are different people, what welds them together?

If you're thinking seriously about how a company or a team should be built in the AI era — I've been chewing on this for a while, and I'd genuinely like to compare notes. Write me: lingchon@seas.upenn.edu