02 Services
Food-photo recognition, coaching that reads a user's own history, and vision models that run against real camera input rather than a demo dataset. The hard part is not the model call, it is the retries, the failure states and the cost per user, and that is the part we have already solved once.
The model call is the easy part. What decides whether an AI feature ships is everything around it: what the screen does when the photo is dark, when the response comes back malformed, when the request times out on a train, and what the whole thing costs per user once real people are using it every day.
We have built that loop for our own apps and we run it in production. Bite AI takes a photograph of a meal and returns calories and a macro breakdown, which means the pipeline meets real camera input — bad light, a half-eaten plate, a photograph of a menu instead of a meal — and still has to put a usable number on screen or say plainly that it cannot. The number then lands in a daily total and in Apple Health, so a wrong answer is not a cosmetic problem.
So we design the failure states first and the happy path second. A feature that degrades into something a person can still use beats one that is perfect right up until it is blank.
Photograph a meal, get calories and macros, with no ingredient list to type in. That is the whole product, so the pipeline cannot be a demo: it has to survive whatever the camera hands it, write a result into the user's day, and be honest when it has nothing useful to say. Live since November 2024 at 4.6 stars from 1,595 ratings worldwide.
Bite AIGlowup AI answers one question — what should I actually be doing for my skin — from a person's own inputs and history rather than a generic product list. The design problem is that the output has to be a decision the user can act on today, not a paragraph of text that reads well and changes nothing. Free on the App Store, live since July 2025.
Glowup AIPrompt shape, model choice, caching and how often the app is even allowed to ask are tuned against live traffic with cost per user watched next to quality. A feature that works and loses money on every subscriber is not a shipped feature, and that arithmetic belongs in the build rather than in a review three months later.
When a call fails, times out or returns something we cannot parse, the app does something specific instead of spinning: a retry, a plain explanation, and a manual path so the user can finish what they came to do. Those routes are designed with the feature, not bolted on after the first one-star review names them.
One decision the model makes better than a form does. We would rather ship one AI feature people use every day than four they try once and never open again.
Timeouts, malformed responses, bad input, no signal. The screen has to stay usable in all of them before the happy path is worth tuning.
Prompts, model choice and request frequency adjusted on real usage, with quality and cost per user read together instead of one at a time.
The feature reports whether it is used and what it costs, so the next decision about it is made on data rather than on taste.
A paragraph about the app, the feature or the thing that is stuck is enough, plus roughly when you need it and the budget range you are working with. One piece of this on its own is fine, and so is the whole thing. Our team reads every message and answers, usually within one business day.