Can Software Startups Survive in the LLM Era?

A Hacker News post titled "In LLM era, can software startup survive?" sparked a small but pointed discussion. The post itself contained no lengthy argument—8 points of heat meant it sank quickly—but the anxiety revealed in its 7 comments is worth unpacking carefully: as large models keep lowering the barrier to "writing software," do software startups that make their living from software products still have a moat?

Where the anxiety comes from: LLMs have redefined the cost structure of "building software"

For the past decade or so, the core asset of a software startup has been its engineering team. Taking a product from idea to launch requires product managers, front-end and back-end engineers, QA, and ops—every link is people and time. LLMs have changed this cost structure: code generation, debugging assistance, documentation writing, customer support—human input across a large number of links has been compressed.

This creates a direct contradiction: building software has become easier, but selling software has not. Supply is expanding far faster than demand is growing. When anyone can describe a requirement in natural language and have a model generate a usable prototype, homogeneous utility products will proliferate rapidly. That confusion in the comments—"who exactly are we competing with?"—essentially comes from here.

Moat is a common metaphor in investing and entrepreneurship, referring to a structural advantage that allows a company to fend off competition over the long term and sustain excess profits. Buffett described it as "a castle moat that keeps getting widened." Typical sources include brand, network effects, switching costs, economies of scale, and proprietary technology. In the software industry, code itself has long been viewed as a weak moat—technology can be copied, and the real barriers tend to come from user scale, ecosystem lock-in, and customer relationships. The renewed discussion of moats in the LLM era centers on this dispute: when the cost of code generation approaches zero, do the implicit barriers previously formed by engineering complexity collapse along with it, and which non-code assets will therefore appreciate in relative terms? Understanding this concept helps distinguish between "technological leadership" and "sustainable competitive advantage"—two things often conflated.

Divergence in the comments: is the moat in the code, or beyond it?

The discussion did not reach a unified conclusion, but it roughly falls into two directions.

View 1: The moat was never in the code itself

Commenters holding this view argue that the real barriers for software companies lie in distribution channels, customer relationships, data accumulation, and brand trust. What LLMs reduce is implementation cost, and these assets do not depreciate as model capabilities improve. For a team with stable paying customers and industry know-how, even if code is generated en masse, customer switching costs still exist.

View 2: Small and mid-sized tool companies will be hit first

The other camp is more pessimistic: the closer a business model is to "feature-as-product," the easier it is to replace. Users are no longer willing to pay for a subscription tool that solves only a single point problem, because the model itself can complete similar tasks. If such companies have not embedded their products into customers' workflows, they may lose their reason to exist after a few rounds of model iteration.

It should be noted that these judgments come from limited comments in a single discussion thread. The sample is very small and cannot be treated as industry consensus.

"Feature-as-product" describes a product form in which a company packages a single feature or a few features directly into a standalone subscription product for sale, with the user value proposition highly concentrated in that feature itself. Such products existed in large numbers in the SaaS era—format converters, email templates, simple data analysis tools, and so on. Their fragility lies in the fact that the entire value of the product can be clearly described in one sentence of requirements, and therefore it is also most easily covered by a single capability upgrade of a general-purpose model. The opposite is a "workflow product"—value comes from connecting multiple links, state management, and team collaboration, with high user switching costs, and single-point model capabilities cannot easily replace the whole. This distinction is an important framework for judging the survival probability of a certain type of software company under the impact of LLMs.

A few things software entrepreneurs should note

Putting together the fragmented views in the discussion, there are several practical reminders for people building software products.

First, re-examine your product's "replaceability." If your core value can be approximately reproduced with a prompt plus a model call, then you need to seriously consider a transformation—not a change of tech stack, but a change of value positioning.

Second, treat models as infrastructure, not as a selling point. "We use LLMs" does not in itself constitute differentiation. Users buy results, not technology routes. Hiding model capabilities inside the product experience is the sustainable approach.

Third, data and workflows are more stable moats. The historical data and customized processes customers accumulate in the system have far higher switching costs than code itself. Building products around these is more meaningful than simply competing on feature lists.

Fourth, the opportunity window for small teams still exists. Lower development costs are also good news for small teams, enabling faster validation of ideas. The question is not whether you can build it, but whether you can find a scenario people are willing to pay for.

Conclusion

This HN post does not provide an answer, and the discussion is far from sufficient. But the question it raises is real enough: LLMs will not directly kill software startups; what they change is the dimension of competition. The premium on coding ability is declining, and the parts that models have not flattened—understanding of scenarios, grasp of customers, depth of workflow embedding—are where survival will be decided next.

For entrepreneurs, rather than worrying about "whether we can survive," it is better to first answer a more specific question: why must users use your product?

Background supplement

Commoditization of infrastructure refers to a technology evolving from a differentiated selling point into a generally available, on-demand, and continuously falling-price underlying capability, similar to electricity and cloud computing. To judge whether a technology has become infrastructure, three things can be examined: whether there are many suppliers with converging capabilities, whether prices are falling rapidly, and whether users no longer care about implementation details. LLMs are showing this trend—the capability gap among models from multiple vendors is narrowing, API prices continue to fall, and users' purchasing decisions are increasingly based on results rather than the underlying model. For enterprises, this means incorporating model capabilities into architecture as replaceable components, avoiding deep binding to them, and building differentiation on product experience, data assets, and business understanding above the model.

One-line Summary

LLMs lower the barrier to software development, but the real moat for software startups lies beyond code.

Paragraph Summary

The article revolves around a Hacker News discussion thread about "whether software startups can survive in the LLM era," sorting out the core anxiety in the discussion: large models have compressed the engineering cost from idea to product, causing the software supply side to expand rapidly while demand growth is limited, intensifying competition among homogeneous utility products. The comments show a clear split: one side believes the moat has always been in distribution channels, customer relationships, data accumulation, and brand trust, and that improved model capabilities will not depreciate these assets; the other side worries that small and mid-sized tool companies whose business models are close to "feature-as-product" will be replaced first. Based on this, the author distills four reminders: re-examine product replaceability, treat models as infrastructure rather than a selling point, build moats with data and workflows, and recognize that small teams still have an opportunity window to validate ideas. The article emphasizes that the discussion sample is extremely small and does not constitute industry consensus, and points out that the dimension of competition has shifted from coding ability to understanding of scenarios and customers.