Tech startup ideas and the question that now decides them

All guides

For most of the last two decades, "can you build it" was a real filter on a tech startup idea. It sorted people, and being on the right side of it was worth something.

It has stopped doing that work. Not entirely, and not everywhere — but for the ideas most people are considering, the build is no longer the scarce part. Which means the question that decides a tech idea now is a different one.

The question

One of the checks a candidate is run through here is deliberately blunt:

Is there a product left if an AI vendor ships this feature?

Ask it about the idea in your head, honestly, and it does more sorting in thirty seconds than a week of competitive analysis. Not because vendors will definitely ship it — nobody can tell you that — but because the answer reveals whether the idea is the capability or merely uses it.

An idea that is the capability has no answer to the question. An idea that uses it has several, and they are the same answers that have always made products defensible.

What survives a feature landing

Proprietary or accumulated data. Something you have that nobody can regenerate by calling an API — a corpus you built, a history your customers created, a set of judgements accumulated over time. This is the strongest answer and the slowest to acquire, which is 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 the step becomes free, you are the thing that still has to exist for the work to happen. Most durable software is this.

Integration surface. You are 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 exactly why it keeps working when technology moves.

Trust and accountability. Somebody has to be answerable when it 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 none of these is technical difficulty. That is the point of the question.

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 of them 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 this: that 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 have made it.

The rest of the questions still apply

The AI-dependency check is one of several, and it is not the one that fails most often:

• Is there a real, documented problem behind it?
• Is there a path to money that repeats?
• Is there a repeatable way to reach the buyer?
• Can it charge enough to be worth one person's time?
• Can it run without hand-holding every customer?
• Does it survive if one platform changes its rules?
• Is there a product left if an AI vendor ships this feature?
• Can you, specifically, sell and operate it?
• Can it launch without licences or compliance audits?
• Can it sell without legal review and a sales team?

For technical founders, the ones that bite hardest are usually distribution and support load, not this one. A tech idea that survives the feature-landing question and still has no repeatable way to reach its buyer is exactly as dead as one that does not.

There is a reason those two dominate: 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 for ideas that pass it

Ideas that survive tend to be found rather than invented, and they are found in the same place as every other durable idea: in the specific, boring frictions of a market that already spends money. The corpus behind this site is organised as 13 clusters of recurring problems for that reason.

Concretely, look for work where:

• the same friction recurs across unrelated sources, over months;
• the buyer already pays for something adjacent, so budget exists;
• the job has many steps and the interesting one is not the whole job;
• somebody has to be accountable for the outcome.

That last one is doing more work than it appears. A market where being wrong has consequences is a market where a general capability is not enough on its own — and it is usually a market technical founders skip, because the interesting engineering is elsewhere.

The short version

• "Can you build it" is no longer the filter it was. Assume the build is not your advantage.
• Ask what remains of the idea when the capability underneath becomes ordinary.
• Data you accumulated, workflow you own, integrations, distribution and accountability survive. Convenience of access does not.
• Building the thin version can be a deliberate trade. Not noticing you made it cannot.
• Distribution and support still kill more technical ideas than this question does.