How I Decide Which AI Tools Are Worth Building

I only build an AI tool when I can name the exact job it does in one sentence. If I can’t say it plainly, I don’t start — a capable model is not a reason to build.

TL;DR

• Start from the job, not the model. “The model can do X” is not a product. “People are stuck doing Y” is.
• One tool, one job. Every CLOOMS tool does a single thing you can state in a sentence.
• Test on ordinary inputs. A tool that only works on a demo photo is not ready.
• Value before signup. If someone can’t try it in ten seconds, capability won’t save it.
• I kill more than I ship. A portfolio stays trustworthy only if every tool earns its slot.

Why I start from the job, not the model

A build decision starts with a stuck user, not a model release. Model capability is now abundant and cheap to reach; specific, unmet jobs are the scarce input. When a new model can generate faces, the lazy move is to ship a face generator. The useful move is to ask which face-related job someone is actually stuck on.

Concretely: nobody wants “AI image generation.” A man deciding whether to grow a goatee wants to see it on his own face first — that exact job is what Goatee.io does. The model is the engine; the job is the product.

The one-sentence test

My filter is a single fill-in-the-blank: “This tool helps [who] do [what] without [today’s friction].” If the friction blank is vague, the tool will be vague, and I stop there.

• Passes: helps someone jump to the exact moment in a long video without scrubbing the timeline — that became Search By Video.
• Fails: helps people “be more creative with AI.” No named user, no named friction, no moment of use.

Definition: a job here means one concrete task with a clear before-and-after, not a capability or a category. Categories describe markets; jobs describe products.

Friction decides adoption, not features

The tools that get used are the ones you can try in ten seconds, not the ones with the longest feature list. So I hold two hard rules:

1. Value before account. You get a real result before any signup. An account is something you earn from the user, not extract before you’ve helped.
2. The first result has to hold on a normal input. I test with an ordinary phone photo or a real, messy file — not a hand-picked demo. If quality drops on the normal case, the tool isn’t done, no matter how good the demo looked.

Knowing when not to build

The hardest calls are the tools that are possible and mildly useful but fail the one-sentence test — and I kill those on purpose. I’ve shelved more ideas than I’ve shipped under CLOOMS. Every tool in a portfolio either builds trust or spends it; a vague one spends it. Keeping the set narrow is the same discipline I use to run two AI companies at once without either turning into a mess.

FAQ

Do you build tools around whichever model is trending? No. I start from a job I can name in one sentence, then pick whatever model does that job well. The model is an implementation detail I’m willing to swap.

How do you decide a tool is good enough to ship? I run it on ordinary, real inputs — a normal selfie, a real video — not curated demos. If the first result is weak on a normal input, it isn’t ready.

Why keep each tool so narrow instead of adding features? Because a tool that does one nameable thing is easy to reach for and easy to trust. Every extra feature is another way to blur what the tool is for.

Where can I see what you’ve shipped? The full set is on the projects page, and the operator lessons behind building them are in shipping a portfolio of AI web tools.