AI Bubble or Real Market? A Founder’s Test for Useful Software

Talk about an AI bubble has become hard to avoid. Investors debate valuations and enormous infrastructure budgets; product builders see models improve and new use cases arrive almost weekly. Both can be true. A technology can create lasting value while some of the businesses financed around it disappoint.

That distinction is particularly important for independent founders. We cannot decide where a chipmaker's shares will trade, or what return an infrastructure investor will earn. We can decide whether a customer has a costly problem, whether our software solves it reliably, and whether the operating economics support a sustainable business. That is a better starting point than treating the stock market as our product roadmap.

Context, 31 October 2026: Reuters reported on 30 October that the U.S. Securities and Exchange Commission was examining AI-related corporate disclosures amid concerns about investment structures and spending. Scrutiny of disclosures is not a regulatory declaration that AI has no value or that a bubble must burst. It is a reminder to separate financial claims from evidence. Read the Reuters report.

What people mean by an AI bubble—and what we cannot infer

An asset bubble is often discussed when prices appear to depend heavily on expectations of future growth rather than cash flows that can currently justify those prices. With AI, people use the phrase more loosely. They may be referring to public-market valuations, private funding rounds, the economics of data centres, crowded AI application categories, or marketing claims that every workflow needs a model.

Those are related, but they are not interchangeable. If some AI investments eventually earn poor returns, it does not follow that language models are useless. If millions of people use an AI product, it does not follow that its developer captures enough revenue to cover operating and capital costs. Real adoption, customer value, business profitability and investment valuation are four different questions.

The history of commercial technology gives us a useful caution without providing a forecast. Useful networks and applications can survive the failure of companies that overpaid to build or market them. Equally, an impressive demonstration can fail to become a product anyone uses repeatedly. The founder's task is to test the second possibility before spending heavily.

My working position is deliberately falsifiable: AI is a real capability with many plausible applications, but a large number of proposed AI businesses will still fail ordinary tests of demand, distribution and economics. That is an operating thesis, not a prediction of asset prices or a claim that all AI startups are overvalued.

AI infrastructure valuation is not independent SaaS economics

At the infrastructure layer, companies finance models, computing capacity, training, security, research and large-scale distribution. Their investment requirements, pricing power, cash flows and risks may be unlike those of a small application vendor. Comparing a private foundation-model valuation with the monthly revenue of a two-person software business tells us very little about either one's intrinsic value.

An independent SaaS company operates closer to the customer. It might purchase model inference through an API, add a workflow, integrate existing systems, handle support and charge a subscription or usage fee. Its economics depend on what the customer pays minus recurring delivery costs, then whether remaining contribution covers acquisition, engineering, administration and support.

For instance, an AI-enabled field-reporting application may use a model to help organize notes, but the user buys an accurate, recoverable report. The product still needs reliable forms, permissions, data handling and a workflow that finishes on a phone. If the model improves but the report becomes unreliable, the customer has not received more value.

The difference also changes risk. A large AI company might worry about financing compute and defending a model advantage. The application founder must also worry about customer concentration, platform terms, inference-price changes and the ability of established software vendors to add a similar feature. These are business-specific exposures, not interchangeable headlines.

The six tests I would apply to an AI business

1. Does it solve a real, expensive problem?

Describe the customer, the last time the problem occurred and its measurable consequence. A vivid demo is not sufficient evidence. A business owner who spends several hours checking job reports has a more concrete pain than someone who says a chatbot looks interesting. Ask for the current workaround, actual costs, and what happens if nothing changes.

2. Will customers need it repeatedly?

A paid experiment is not the same as durable demand. A workflow repeated weekly or monthly may support a subscription; a rare, one-off problem may need a different pricing model. Measure activation, completed jobs and return usage, not only sign-ups. Repeat use should mean the same customer continues receiving value rather than simply retrying a failed feature.

3. Can the business afford distribution?

Good software can be a poor business if qualified buyers are expensive to reach. Identify who makes the buying decision, where the first ten serious prospects will come from and how long sales will take. Search traffic for the phrase “AI software” is not equivalent to purchase intent. A narrower service keyword, referral partner or existing trade community may be more valuable than a large audience with no budget.

4. Does gross margin remain attractive after AI costs?

Model calls, storage, third-party services, monitoring and support may grow with usage. A flat subscription can be dangerous if a few heavy users consume unlimited inference. Price a realistic high-usage customer and decide where limits or higher tiers are necessary. Do not conflate gross margin with net profit: customer acquisition, engineering and general costs still need to be paid.

5. Is there any reason customers will stay?

A model wrapper with no workflow integration may be easy to replace. Useful retention can come from trusted history, saved templates, permissions, specialist data, reliable exports and a product fitting an actual team process. Do not make data difficult to export merely to manufacture switching costs. Ethical retention comes from the cost of losing value, not the cost of escaping a trap.

6. Can the business survive a provider change?

Using an external model is reasonable; pretending it creates no dependency is not. Document the provider, data retention terms, model versions, rate limits and fallback behavior. For a critical function, know how the workflow degrades if the model is unavailable. Keep business rules separate from model-generated suggestions wherever accuracy, auditability or compliance requires it.

The NIST AI Risk Management Framework offers a broader, voluntary approach to mapping and managing AI risks. It is not a commercial viability test, but it is a useful companion to one: a product that sells yet cannot be operated responsibly is not sustainable.

A founder scorecard: example assumptions, not claimed results

My approach is to score the quality of the evidence on each test from zero to five, where zero means untested and five means repeated, specific, verifiable evidence. Totals are useful for comparison, but low scores in safety or ability to deliver are potential vetoes. The example below is a hypothetical AI assistant for creating routine service reports—not performance data from a product I operate.

Illustrative total: 16 / 30. I would not read that as a probability of success. The calculation points to the next experiments: discovery of a distribution channel, a paid pilot, cost testing and a recovery plan. A founder who changes the scoring rubric to make an idea pass defeats its purpose.

Consider the unit economics separately. If a hypothetical service charges $40 monthly and spends $9 on recurring inference, hosting and direct support, its illustrative gross contribution is $31 before acquisition, fixed engineering and overhead. A further $20 of acquisition cost per customer cannot simply be ignored; it needs a realistic payback assumption and retention evidence. These figures are deliberately invented teaching inputs, not observed prices, benchmark margins or results.

A more useful spreadsheet varies three variables at once: how many users consume the product heavily, how many customers return in the following months, and how much it costs to acquire a paying account. Optimistic averages obscure the customers who create most of the infrastructure bill.

What evidence would change my view?

A sensible founder should be able to describe the facts that would overturn an investment or product thesis. Evidence against my cautious approach would include a high-quality customer cohort showing repeated paid use, clear economic savings for buyers, sustainable margins through substantial usage growth and repeatable acquisition without escalating incentives. It would suggest a market is more durable than the hype narrative implies.

Evidence that would strengthen the bubble concern includes widespread reliance on promotional credits rather than paid demand, falling prices without offsetting delivery-cost reductions, rapid churn once trials end, and applications whose value disappears when a platform provider releases a similar native feature. In public markets, expensive valuations combined with disappointing financial performance would be a separate warning.

Neither outcome should be assumed in advance. Market prices can move for reasons unrelated to one company's product quality. Conversely, a customer may continue using a profitable niche app through an industry-wide valuation correction. This is why I would keep a product dashboard and a market-news feed separate.

What a software founder should do in the next 30 days

1. Week 1 — write the problem statement. Choose one customer role, one recurring job and one observable outcome. Speak with five prospective buyers about their most recent experience, without pitching the answer.
2. Week 2 — expose the price question. Show a specific proposed workflow and test a paid pilot or clear purchase commitment. Ask who controls the budget and how approval works. Record every refusal.
3. Week 3 — build a reliable narrow path. Create only what is needed to deliver the promised outcome. Include failure handling, permissions, data protection and a human fallback; do not confuse a demo with a production system.
4. Week 4 — review the economics. Model ordinary and heavy usage, potential support time, acquisition cost and cancellations. Decide explicitly whether to continue, narrow the scope, change pricing or stop.

For more detail on prioritizing the first experiment, see my earlier article, How I Evaluate Micro SaaS Ideas Before Writing Any Code. I also discuss a narrower build philosophy in A SaaS MVP Needs One Workflow, Not Fifty Features.

Useful AI software does not need a market prediction

My preferred way to respond to the AI bubble debate is not to ignore markets. It is to separate the market question from the customer question. Investors need to price uncertain future earnings. Founders need to prove a present customer problem, a credible delivery model and enough economic room to stay in business.

A focused AI product can be worthwhile even during a speculative boom, and a famous AI company can still be a poor investment at the wrong price. I would choose the small, verified customer problem over the large, untested promise. If you are interested in the kinds of focused products and businesses I build, explore NIR.Systems or the work collected on my portfolio.

Common questions