An agent walks a property with a phone, not a DSLR and a laptop. They want the listing photo finished before they are back in the car. That expectation quietly decides the architecture of any tool that serves them, because it forces a split: some of the work genuinely runs on the device, and some of it cannot, and pretending otherwise is where most mobile photo tools get slow or lie about latency.
We build CasaNova Labs, an AI studio for real estate photo and video editing that people use from a phone browser, so this split is something we reason about constantly. Here is the honest map of what sits where.
What the phone actually does well
The capture side is entirely local, and modern phones are good at it. Exposure metering, multi-frame HDR merge, lens correction, and the preview you frame the shot with all run on the device silicon before a single byte leaves it. This is why the practical advice for shooting a listing on a phone is mostly about technique rather than gear: hold the phone level at chest height, use the main or ultra-wide lens rather than digital zoom, lock exposure so a bright window does not crush the room, and shoot in daylight. We wrote the full field version of that up in how to take real estate photos with an iPhone, and none of it needs a server, because none of it is generative. It is optics and metering.
The phone is also fine for the light edits: crop, straighten, a global exposure or white-balance nudge. Those are per-pixel operations with no model behind them, so they run in the browser on a canvas without a round trip.
Where it has to leave the device
The moment the operation is generative, the phone stops being enough. Replacing a grey sky, removing clutter from a room, or staging an empty space with furniture are all diffusion-model inferences. A single such pass is billions of floating-point operations against multi-gigabyte weights. That does not fit in a phone browser tab, and it should not: you do not want the model weights shipped to every device, and you do not want the battery and thermal cost of running them there.
So the architecture that actually works is boring and correct: the phone captures and does the cheap edits locally, then hands the heavy generative step to a GPU on a server, and streams the result back. The user experience target is that the round trip feels like a filter, not like a render job. In practice a staging or replacement pass finishes in about 30 seconds on average, which is the number that decides whether an agent waits for it on-site or gives up and posts the raw photo.
The install question the App Store hides
There is a second consequence of "from a phone" that is not about compute at all. A native app means an install, an update cycle, and a review queue, per platform. For a tool whose heavy work is server-side anyway, a large part of that install buys the user nothing, because the model was never going to run locally. A web app in the phone browser skips the install and keeps the same session open on a laptop later, which matches how agents actually work: shoot on the phone, tidy the batch on a desktop that evening.
The tradeoff is real and worth stating plainly. Native still wins on camera-native capture flows and on true offline use. If you never have signal at the property, a web tool cannot do the generative step there, and a native app that caches a small on-device model could. We laid out that comparison in full, including what native does better, in the virtual staging app breakdown, and the same install-versus-browser logic applies to the broader category of free AI interior design apps.
The takeaway for anyone building this
If you are architecting a mobile media tool, draw the line by asking one question per operation: is there a model in it? No model, keep it on the device and make it instant. Model in it, move it to a server and spend your engineering budget on making the round trip feel local. The mistake is trying to push generative work onto the phone to claim it is "on-device," which trades a 30-second server call for a slower, hotter, worse local one. The phone is the camera and the darkroom for everything that is optics. It is a thin client for everything that is inference. Building as if that line does not exist is how these tools end up slow.
You can try the generative side of this on ten photos without a card at CasaNova Labs.
