What I Look for Before Building an AI Product

Most of my ideas die before a single line of code. That's the point.

I keep a list of product ideas. Right now it has 40+ entries. I've built seven of them. The other 33 failed a filter I run before opening my editor. That filter has saved me months of wasted work, and it's the main reason I can ship fast: I only build things that survive the gauntlet.

Here's how I decide what AI product to build and, more importantly, what to kill.

Filter 1: Real Problem or Cool Demo?

This kills 60% of ideas on the spot. A cool demo makes people say "wow" on Twitter. A real product makes someone's Tuesday afternoon less painful. I'm looking for the Tuesday afternoon.

I had an idea for an AI meeting summarizer. The demo was impressive: feed it a transcript, get beautiful notes. But the market is flooded. Otter, Fireflies, Granola, and a dozen others already do this. The demo is cool. The business is a bloodbath.

If you're wondering how to decide what AI product to build, start here. If the problem only exists inside a demo video, it's not a product.

Filter 2: Can AI Do the Hard Part?

Too many AI products are wrappers. They take an API, add a UI, and call it innovation. That's a feature, not a product. I look for cases where AI does the genuinely difficult thing that would be impossible or impractical without it.

My SEO Engine passes this filter. The hard part is coordinating seven agents to produce content that doesn't read like AI slop. The AI isn't a skin on top of a form. It's the engine that makes the whole thing possible.

An AI code reviewer I considered? Failed this filter. The hard part of code review is understanding business context, team conventions, and architectural intent. AI can lint. It can't review. Not yet.

Filter 3: Can One Person Build and Run It?

I'm a solo founder. No employees, no plans to hire. If a product requires a support team, an ops team, or constant manual intervention, it's not for me. This filter is personal, but it's ruthless.

Claudette passes. It's a desktop app. Users install it, it works, they file issues on GitHub if something breaks. I fix bugs on my schedule. No SLAs, no on-call rotation.

A managed AI platform? Fails immediately. Infrastructure, uptime guarantees, customer support. That's a company, not a solo product.

Filter 4: Two-Week MVP or Too Big

If I can't get a working MVP in two weeks, the idea is too big for my current situation. This is a constraint I chose, not a universal rule. But it forces clarity. Two weeks means I have to cut scope aggressively, which means I have to know exactly what the core value is.

The SEO Engine MVP took 10 days. Rough, minimal, but it posted real content to a real site. That's enough to validate demand. If I'd scoped it as "a complete content marketing platform," I'd still be planning.

Filter 5: Who Pays, and Are They Developers?

Developers are the hardest customers. They'll build their own version before paying you. I love building for developers, but I'm honest about the economics. If the only people who want your product are other developers, you need a very strong reason to proceed.

My consulting work targets small businesses: legal firms, medical practices, agencies. They have budget and they don't want to build it themselves. That's the profile I look for. Clear ROI, willingness to pay, zero interest in doing it in-house.

What Survived

Claudette survived all five filters. Own itch, AI does the hard part, one person can run it, two-week MVP, and a user base that wants a GUI but won't build one.

The SEO Engine survived. Clear ROI, AI does genuinely complex orchestration, I run it alone, and businesses pay for content that ranks.

33 ideas didn't make it. That's the whole point. The best product decision is knowing what not to build. If you want to see what made it through the filter, check out how I build AI products from Latin America.