Letting People Upload Photos to Your AI-Built App (Without It Falling Over)

The moment your app stops being just text and starts letting people upload a photo, something changes. Adding image and file uploads means letting a user send a photo, receipt, or document from their device into your app, which stores it and shows it back later — a profile picture, a receipt, a damaged-package snapshot, a PDF contract. It’s one of those features that looks like a single checkbox and turns out to have a few sharp edges underneath. None of them are hard. But the ones nobody warns you about are the ones that show up three weeks after launch, usually from your most enthusiastic user.

This is a tour of what’s actually happening when someone hits “upload,” the three mistakes that bite later, and the exact things to ask your builder for so you don’t hit them.

What actually happens when you upload a photo to an app?

Uploading a photo triggers four steps in order: your phone hands the file to the app, the app sends it to separate file storage (not the database), the app saves a link to that file next to the record, and later it fetches the file using that link whenever someone views the record.

Here’s what that looks like step by step:

The phone hands your app the file. A modern phone photo is often 4 to 12 megabytes. That’s not nothing.
Your app sends that file somewhere to be stored — not in your app’s database, but in a separate storage bucket built for files.
Your app saves a link to that file in the database, next to the rest of the record (this receipt belongs to this expense).
Later, when someone views the record, the app fetches the file from storage using that link and shows it.

The part people get wrong is step 2 and 3. They imagine the photo gets “saved in the app.” It doesn’t, and it shouldn’t. Files live in storage; your database just remembers where. Get that split right and everything downstream is easier.

Should you store uploaded photos directly in the database?

No — and this is the most common upload mistake, one AI builders will sometimes make by default if you’re not specific. Stuffing a 10 MB photo directly into your database is like keeping your furniture in your wallet. The database is built for small, structured things — names, dates, prices. Pour photos into it and it gets slow, backups balloon, and one day a page that used to load instantly takes six seconds because it’s dragging a hundred full-resolution images along with it.

What you want instead: the file goes to file storage (your builder may call it a “storage bucket” or “blob storage”), and the database holds only the link. Ask for it directly:

“Store uploaded images in file storage, not in the database. Keep only the file URL in the record.”

How do you stop users from uploading the wrong file type or a huge file?

You decide ahead of time what’s allowed — file type, size limit, and a clear error message — and tell your builder explicitly, because without those rules your app will accept anything, including files that hang the upload entirely. Two real scenarios show why, both from apps that worked fine in testing:

A woman runs a small catering business and built an app for clients to upload photos of cakes they liked. It worked great until a client uploaded a 47 MB photo straight from a professional camera. The upload hung, the client gave up, and she heard about it as “your app is broken.” It wasn’t broken — it just never set a size limit, so it sat there forever trying to swallow a huge file.

A second one: a freelancer built a client portal where people upload “their logo.” One client uploaded a .zip file. Another uploaded a 90-page PDF. The app accepted all of it because nobody told it what a logo was supposed to be.

Decide these three things ahead of time:

What file types? Photos only? Then accept JPG and PNG and reject the rest, with a friendly message.
How big? A sensible photo limit is around 5 to 10 MB. Big enough for a real phone photo, small enough to stop a camera dump.
What if it’s wrong? The app should say so kindly — “Please upload a JPG or PNG under 10 MB” — not just freeze.

Tell your builder:

“Only allow JPG and PNG images up to 10 MB. If someone uploads something else or too big, show a clear message instead of failing silently.”

Why does your app feel slow when it has a lot of photos?

Because every viewer downloads the full-size original every time, not a scaled-down copy — on their phone, on their data plan, every single time someone opens the record. Say someone uploads a crisp 8 MB photo and it works fine on its own. Multiply that by a gallery of twenty photos and your fast little app feels like wading through mud.

The fix has a name worth knowing because your builder will recognize it: a thumbnail, or a resized version. The idea is that you keep the original but also make a small, web-friendly copy, and you show the small copy in lists and previews. The full one only loads when someone actually wants to see it large.

“When an image is uploaded, also create a smaller resized version for previews and lists. Show the small version by default and only load the full image when someone clicks to view it.”

You don’t need to understand how it’s done. You need to know it exists, so you can ask for it before your app feels slow instead of after.

A few quieter things worth deciding

These three decisions won’t break your app if you skip them, but they’re cheaper to make now than to retrofit later: who can see the file, what happens to it when the record is deleted, and whether upload works on a phone.

Who can see the file? A profile picture is fine for anyone to view. A scanned ID or a signed contract is not. If the file is private, tell your builder the link should require login, not be a public URL anyone can open. This is the one I’d push hardest on for anything sensitive.
What happens when the record is deleted? If someone deletes an expense, should the receipt photo get cleaned up too? Otherwise you slowly accumulate orphaned files you’re paying to store and forgot you had.
Does it work on a phone? Most uploads happen on phones, and phones offer “take a photo right now” as well as “pick from library.” Test both on a real phone, not just on your laptop where you only ever drag a file in.

Test it like a stranger would

Test it by deliberately trying to break it the way a real user accidentally will — a normal photo, an oversized file, the wrong file type, a live phone-camera upload, and a deletion — before you call it done:

Upload a normal phone photo. Does it appear, and is the preview fast?
Upload something huge. Does the app stop you with a clear message, or does it just hang?
Upload the wrong type — a PDF where a photo’s expected. Does it explain the rule?
Open the app on your phone and upload directly from the camera.
Delete a record and check whether its file is handled the way you decided.

If all five behave, you’ve cleared the edges that catch most people.

Uploads are one of those features where the gap between “works in the demo” and “works for a stranger on a train with a 12 MB cat photo” is exactly the set of decisions above. None of them are hard. They’re just easy to skip — and much easier to ask for now than to repair later.

If you’ve been putting off adding uploads because it felt like a big technical leap, it isn’t. Open your builder, ask for image storage with a size limit and a thumbnail, and watch what it gives you. Then go try to break it on your phone — that’s the real test, and it takes five minutes.