The premise, and this audience will either agree instantly or argue, which is fine: for most of the last two decades can you build it was a real filter on a technical idea. It sorted people and being on the right side of it was worth something. For the ideas most people are now considering, it has stopped doing that work.
The check that replaces it is deliberately blunt: is there a product left if an AI vendor ships this feature? Asked honestly it sorts more in thirty seconds than a week of competitive analysis — not because vendors will definitely ship it, which nobody can tell you, but because the answer reveals whether the idea IS the capability or merely USES it. An idea that is the capability has no answer. An idea that uses it has several, and they are the same answers that have always made products defensible.
What survives, first: proprietary or accumulated data. Something nobody can regenerate by calling an API — a corpus you built, a history your customers created, judgements accumulated over time. Strongest answer and the slowest to acquire, which is exactly why it is the strongest.
Workflow depth. The capability is one step in a job with fifteen steps and you own the other fourteen. When that step becomes free you are still the thing that has to exist for the work to happen. Most durable software is this and it is rarely described as a moat because it does not sound like one.
Integration surface. Wired into systems of record that are painful to connect and worse to disconnect. Unglamorous, and it is why unglamorous software outlives clever software.
Distribution you own. You can reach the buyer repeatedly without permission. This one is independent of technology entirely, which is precisely why it keeps working when technology moves.
Trust and accountability. Somebody has to be answerable when the output is wrong. In regulated or high-consequence work a capability that cannot be held responsible is not a substitute for a supplier that can.
Notice that not one of those is technical difficulty. That is the point of the question, and it is the part that stings if you were counting on the build.
What does not survive: a thin layer over a general capability whose entire value is convenience of access. It can be a genuinely good business for a while and some earn real money in that while — but its survival is somebody else's decision, and pricing it as though it were durable is how founders end up surprised by a product update.
The honest way to hold that: it is a trade you can make deliberately. Build the thin thing, know the clock is running, and use the time to acquire one of the answers above. What is dangerous is making the trade without noticing you made it.
And it is not the check that fails most often, which is worth saying because it is currently the fashionable one. Of the 12 deal-breaker checks we run on a candidate, distribution and support load bite technical founders hardest — for a structural reason: they are the questions a technical founder is worst equipped to estimate, so they get the least honest scrutiny and the most optimistic answers. The check that feels most urgent is rarely the one that kills you.
Where to look instead: ideas that survive this tend to be found rather than invented, in the specific boring frictions of a market that already spends money. Our corpus is organised as 13 clusters of recurring problems for exactly that reason. Look for friction recurring across unrelated sources over months, a buyer already paying for something adjacent, a job with many steps where the interesting one is not the whole job, and somebody who has to be accountable for the outcome.
The full version: https://whittleos.com/guides/tech-startup-ideas
Top comments (0)