A phone camera makes a promise before any model runs: point it at something and the truth comes back. Consumer computer vision inherits that promise, and the builder's first job is deciding how much of it to keep. I build a consumer app that reads photos of household surfaces, and the most useful design question I know is what the answer should refuse to claim.
A photo is evidence about a surface, not a verdict on a home
An image model sees pixels: color, texture, edges, pattern, lighting. It can learn that certain patterns resemble certain things. It cannot see what is behind the drywall, what the humidity was last week, or whether a dark patch is growth, soot, dirt or a shadow from a bulb the user did not notice. Photos are also compressed by the phone, framed by someone hoping for a particular answer, and taken at whatever distance felt natural. Lookalikes are the hard part, and no amount of confident interface design makes them go away.
The Minnesota Department of Health puts the limit well for human visual inspection: it "cannot detect mold hidden within wall cavities, inside HVAC ductwork, or beneath flooring." That sentence is about people, but a camera inherits it exactly, and a model adds blind spots of its own. Builders have long known the same thing from the other direction. Check moisture before you close the wall makes the case that hidden surfaces have to be checked before they are hidden, because nothing pointed at them later will see through them.
Design the answer so it can be wrong safely
That is the constraint I hold Mold Scanner AI to as a product. I cannot defend a claim about model performance here, so I defend the design instead. Four rules do most of the work.
Say what was seen, not what is true. "This area looks like it could be X" is an honest sentence. "You have X" is a verdict the pixels cannot support.
Use plain words for uncertainty, not a decimal. A percentage on screen reads as precision. A model's raw confidence is not a calibrated probability a person can act on, so showing it as one borrows credibility the system has not earned.
Ask for a better photo before giving a worse answer. Closer, brighter, a second angle. A request for more input tells the user the system knows its limits, and that builds more trust than a fast guess.
Attach a next step that works whether the model is right or wrong. If the answer is "unsure," the person still needs somewhere to go. For a household surface, that means sensible cleaning with protective gear and good ventilation, plus finding the moisture source, none of which depends on the model being correct.
On-device or cloud is a trust decision, not only a speed decision
The engineering tradeoff is familiar. On-device inference keeps the photo on the phone, responds instantly and works in a basement with no signal. It also forces a smaller model, makes updates ride the release cycle, and means behavior varies across phone generations. Cloud inference allows a larger model, lets you fix behavior without a store review, and gives every device the same answer. It costs you an upload, a network dependency and a per-scan compute bill that scales with usage.
The consumer angle is that a photo of the inside of someone's home is personal. Whichever side you pick, tell people plainly where the image goes and what happens to it, in the flow and not buried in a policy page. Unclear data handling erodes trust faster than a wrong answer does. Readers comparing apps in this category can start with the best mold detection app page, which is a reasonable place to see what to weigh.
Shipping small: the store listing is the first screen
On a small team you cannot polish everything, so spend on the answer screen and keep the rest boring. A few judgments I would defend on a call:
Write store copy that describes what the app does, not what it diagnoses. Health-adjacent promises invite scrutiny from reviewers and disappointment from users, and both are avoidable.
Price a pre-launch consumer app from the value of one clear decision, not from competitors' tables, and expect to revise it once real behavior exists. Any number you publish before then is a hypothesis.
Keep one flow. Every extra screen is a place for a small team to ship a bug and for a first-time user to leave.
The rule: design the answer around the photo's blind spots first. Say what the image shows, name what it cannot, and always give the person a next step that still works if the model is wrong.