What has to be true before we add AI to an app

Your iPhone is full of things you put there. Recipes screenshotted from a webpage. Half-finished lists in Notes. A PDF someone emailed you. A photo of a workout written on a whiteboard. A voice memo of yourself talking through how you bill a client. It’s already there. You put it there because that’s where it goes.

So when a new app comes along that could in theory use any of it, the question isn’t whether the app is good. The question is whether it can meet you where your stuff already lives, or whether it expects you to type it all in again from scratch. An app that makes you retype a recipe you already screenshotted, or re-list the steps you already wrote in Notes, is asking you to do work that has nothing to do with what you’re actually trying to do. The data’s there. The barrier is the app.

That’s what AI features are actually for, when they’re for anything at all. Not for impressing anyone. Not for the marketing copy. For closing the gap between the thing the user already has and the thing the new app needs it to be.

There’s no shortage of AI features going into apps right now. A lot of them are good. A lot of them are there because investors want to see them, or because the team had a quota, or because everyone else is doing it and not having one started to feel like a problem. We’re a small studio. We don’t have those pressures, and we don’t have the bandwidth to build features for any reason other than that they help. So we wrote down what an AI feature has to be, for it to make it into a Gums & Bones app at all.

There are three things, and they’re all hard nos when they fail.

The first is that it has to help the user do the thing the app is actually for. Patter exists to help people build routines and let those routines turn into habits. An AI feature inside Patter has to push toward that — making it easier to start a routine, or refine one, or get unstuck on the blank screen. Letting someone hand Patter a webpage or a Note or a photo of a list, and get back a draft routine they can edit, fits. A generator that makes a cute icon for each routine wouldn’t. Not because it’s bad. It’s fine. It just has nothing to do with why anyone opens Patter. Every app we make has a purpose, narrow enough to write on a postcard, and an AI feature either serves that purpose or it doesn’t go in.

The second is that it has to fit how we already build. Our apps are a one-time purchase, no subscription, no ads, no account, no analytics, no cloud. Bolting on an AI feature that quietly broke any of those would have undone the rest of the studio. So the feature has to work inside those constraints: on the user’s device, paid for by us not by them, with no telemetry coming back.

The third is that the user has to be in complete control. AI never runs in the background. It never reads anything the user hasn’t explicitly handed it. It never silently processes the user’s content to be “helpful.” It runs when the user asks it to run, on the content the user gives it, and the result is shown to the user before anything is saved. There’s no halfway version of this. Either the user is in the driver’s seat every time, or we don’t build the feature. A summariser that quietly read your notes in the background to surface “insights” wouldn’t pass, no matter how useful the insights turned out to be. You’ll never wonder if our apps ran a model on your data without telling you. The answer is no.

And whatever the AI produces is a draft for the user to look at, not a change to anything they already had. We don’t rewrite the user’s content. The photo, the note, the screenshot, the PDF — what you handed the app stays exactly as it was. The AI’s output is a separate thing, sitting next to the original, for you to keep or throw away.

Those are the three. Purpose, fit, control. Most AI feature ideas — most of ours included — don’t get past all three, and that’s the whole point of writing them down. The list exists to say no with.

There’s a fourth thing that isn’t a criterion but matters as much as the criteria. The AI a feature uses is itself a design decision. Right now, Apple’s on-device model is the only option we know of that lets us meet all three of the rules above without a long list of compromises. It runs on the user’s device, it costs us nothing to use, it doesn’t see what it processes, and Apple isn’t trying to upsell anyone on a subscription tier on top of it. It also has direct access — with the user’s permission — to the things already on the phone, which is the whole reason any of this is worth doing. If that ever changes, or if a better option becomes available that meets the same bar, we’ll reconsider. We’re not loyal to a model. We’re loyal to the rules.

A reasonable question at this point is: why bother writing this down at all? Most studios our size don’t publish a stance on AI. The honest answer is that we’re going to be making these decisions on our own, often, and quickly, for a long time. Putting the rules on paper is mostly for us. It means the next time we’re tempted to build something because it would demo well or because everyone else has shipped it, there’s a piece of writing we have to look at first. The criteria say no for us, so we don’t have to do it from scratch every time.

You’re welcome to hold us to them.