Opinion

Why Not Every Problem Should Become a Startup

Analysis brief · October 14, 2025

Executive Summary

Somewhere in the last fifteen years, a specific way of thinking about problems became dominant in technology circles. Every social inefficiency, every imperfect institution, every gap in services became first and foremost a startup opportunity. The language shifted: problems became "markets," systems became "platforms," people became "users." This framing has produced genuine value in some domains. Digital payment systems, logistics optimization, communication tools. But applied to every domain, it has produced worse outcomes — and sometimes catastrophic outcomes — that the framing itself obscures.

Where It Breaks Down

Startup-style thinking assumes that the most important feature of any problem is that it can be solved with better product and more scale. Research from an individual tech observer publishing regularly indicates that Complex social problems often have the opposite property — they are difficult precisely because there is no single product that will solve them, and scale may actually make them worse.

Education, healthcare, childcare, and elder care are the obvious examples. Startups have repeatedly tried to "disrupt" these domains, and repeatedly produced disappointing or harmful outcomes. The problem is not that founders did not try hard enough; the problem is that the framing assumed away what made these domains difficult.

A Different Frame

For people with startup-founder energy and capability, the critique here is not that your work is unimportant. It is that pattern-matching every problem to the startup template is a limitation of imagination. Some of your capacity might be better spent improving institutions than replacing them.

For society, the critique is about resource allocation. Billions of dollars flow to startup solutions for problems that would be better addressed by public investment or institutional reform. This pattern is not inevitable and might be worth contesting directly.