A four-part test for whether an AI feature belongs in your app

There is a version of AI product work that consists of finding a place in the app to put a sparkle icon. It usually ships, it usually gets used twice, and it usually gets quietly removed a year later. The features that survive have almost nothing in common visually, but they pass the same four tests.

Does it remove a step, or add a screen?

The only durable reason to put a model in a product is that it deletes work. Reading a prescription label off the bottle instead of making someone type the drug name, strength, and schedule is a deletion. Reading a service code off a statement instead of making someone squint at a folded page is a deletion.

A chat box bolted onto a settings screen is not a deletion. It is a new place to go and a new thing to learn, and the user has to do the old work anyway when the answer is wrong. If you cannot name the step the feature removes, you do not have a feature yet.

Is it fast enough to be boring?

Latency is the feature. A model that takes six seconds gets used once; the same model at 200 milliseconds becomes invisible infrastructure. This is why so much of the interesting work is on-device: not as a privacy slogan, but because a local model with no round trip is the only way to hit the speed that makes a feature feel like part of the app instead of a request to a distant service.

Boring is the goal. Nobody thinks about autocorrect. That is the highest compliment a machine learning feature can receive.

If people notice your AI feature every time they use it, it is probably too slow, and if they only notice it when it is wrong, you have built the right thing.

Does it fail in front of you?

Every model is wrong sometimes, so the design question is not whether it fails but where. Good failures are visible and cheap: the app shows you the field it extracted, you fix the one wrong digit, you move on. Bad failures are silent and expensive: a number is quietly filed, and you find out six months later when it matters.

Show the work. A confirmation step feels like friction in a demo and feels like trust on the hundredth use.

Does the user stay in charge?

The last test is whether the person can override, edit, and delete anything the model produced, and whether the feature ever acts without being asked. Automatic detection should surface a question, not a fact. Anything that writes to a permanent record should require a tap.

Held together, the four tests describe something narrower and more useful than "AI in an app": a fast, local, correctable step-remover that never surprises you. That is the shape most consumer AI features will eventually settle into, once the novelty budget runs out.

Our apps are built against exactly that test, and everything we ship is free, with no subscriptions, ever. You can see the whole catalog on the apps index, and more on how we think about building them in the blog archive.