Klanten foto's laten uploaden naar je AI-gebouwde app (zonder dat hij vastloopt)

Op het moment dat je app niet langer alleen tekst is en mensen ineens een foto kunnen uploaden, verandert er iets. Het toevoegen van foto- en bestandsuploads betekent dat een gebruiker een foto, bonnetje of document vanaf zijn apparaat naar je app kan sturen, die het vervolgens opslaat en later weer laat zien — een profielfoto, een bonnetje, een foto van een beschadigd pakketje, een pdf-contract. Het is een van die functies die op één simpel vinkje lijkt, maar onder de motorkap een paar scherpe randjes blijkt te hebben. Geen daarvan is moeilijk. Maar het zijn precies de randjes waar niemand je voor waarschuwt die drie weken na lancering opduiken — meestal via je meest enthousiaste gebruiker.

Dit is een rondleiding langs wat er echt gebeurt zodra iemand op “uploaden” klikt, de drie fouten die later terugkomen om je te bijten, en de precieze dingen om aan je builder te vragen zodat jij ze niet tegenkomt.

Wat gebeurt er eigenlijk als je een foto naar een app uploadt?

Een foto uploaden zet vier stappen in gang, in deze volgorde: je telefoon geeft het bestand aan de app, de app stuurt het naar aparte bestandsopslag (niet naar de database), de app slaat een link naar dat bestand op bij het record, en later haalt hij het bestand op via die link zodra iemand het record bekijkt.

Zo ziet dat er stap voor stap uit:

De telefoon geeft je app het bestand. Een moderne telefoonfoto is vaak 4 tot 12 megabyte. Dat is niet niks.
Je app stuurt dat bestand ergens naartoe om te worden opgeslagen — niet in de database van je app, maar in een aparte opslagbucket die speciaal voor bestanden is gebouwd.
Je app slaat een link naar dat bestand op in de database, naast de rest van het record (dit bonnetje hoort bij deze uitgave).
Zodra iemand later het record bekijkt, haalt de app het bestand op uit de opslag via die link en toont het.

Het deel dat mensen fout doen, is stap 2 en 3. Ze stellen zich voor dat de foto “in de app wordt opgeslagen.” Dat gebeurt niet, en dat hoort ook niet. Bestanden leven in opslag; je database onthoudt alleen waar. Krijg die scheiding goed voor elkaar en alles daarna wordt makkelijker.

Moet je geüploade foto’s rechtstreeks in de database opslaan?

Nee — en dit is de meest voorkomende uploadfout, een die AI-builders soms standaard maken als je niet specifiek bent. Een foto van 10 MB rechtstreeks in je database proppen is als je meubels in je portemonnee bewaren. De database is gebouwd voor kleine, gestructureerde dingen — namen, datums, prijzen. Giet er foto’s in en hij wordt traag, back-ups zwellen op, en op een dag duurt een pagina die vroeger direct laadde ineens zes seconden, omdat hij honderd foto’s op volledige resolutie meesleept.

Wat je in plaats daarvan wilt: het bestand gaat naar bestandsopslag (je builder noemt dit misschien een “opslagbucket” of “blob storage”), en de database bevat alleen de link. Vraag er rechtstreeks om:

“Sla geüploade afbeeldingen op in bestandsopslag, niet in de database. Bewaar alleen de bestands-URL in het record.”

Hoe voorkom je dat gebruikers het verkeerde bestandstype of een enorm bestand uploaden?

Je bepaalt van tevoren wat toegestaan is — bestandstype, groottelimiet en een duidelijke foutmelding — en vertelt dat expliciet aan je builder, want zonder die regels accepteert je app alles, inclusief bestanden die de upload volledig laten vastlopen. Twee echte scenario’s laten zien waarom, allebei van apps die tijdens het testen prima werkten:

Een vrouw runt een klein cateringbedrijf en bouwde een app waarmee klanten foto’s konden uploaden van taarten die ze mooi vonden. Het werkte prima, totdat een klant een foto van 47 MB uploadde, rechtstreeks van een professionele camera. De upload bleef hangen, de klant gaf het op, en zij hoorde ervan als “je app is stuk.” Dat was hij niet — er was gewoon nooit een groottelimiet ingesteld, dus hij bleef eeuwig proberen een enorm bestand te verwerken.

Een tweede voorbeeld: een freelancer bouwde een klantportaal waar mensen “hun logo” konden uploaden. Eén klant uploadde een .zip-bestand. Een ander uploadde een pdf van 90 pagina’s. De app accepteerde het allemaal, omdat niemand hem had verteld hoe een logo eruit hoort te zien.

Bepaal deze drie dingen van tevoren:

Welke bestandstypes? Alleen foto’s? Accepteer dan JPG en PNG en weiger de rest, met een vriendelijk bericht.
Hoe groot? Een redelijke limiet voor foto’s ligt rond de 5 tot 10 MB. Groot genoeg voor een echte telefoonfoto, klein genoeg om een camera-dump tegen te houden.
Wat als het niet klopt? De app moet dat vriendelijk aangeven — “Upload een JPG of PNG onder de 10 MB” — en niet zomaar bevriezen.

Vertel je builder:

“Sta alleen JPG- en PNG-afbeeldingen tot 10 MB toe. Als iemand iets anders of iets te groots uploadt, toon dan een duidelijk bericht in plaats van stil te falen.”

Waarom voelt je app traag als hij veel foto’s bevat?

Omdat elke kijker steeds het volledige originele bestand downloadt, niet een verkleinde versie — op zijn telefoon, op zijn databundel, elke keer dat iemand het record opent. Stel dat iemand een scherpe foto van 8 MB uploadt en die op zichzelf prima werkt. Vermenigvuldig dat met een galerij van twintig foto’s, en je snelle kleine app voelt ineens als waden door de modder.

De oplossing heeft een naam die het waard is om te kennen, want je builder herkent hem: een thumbnail, oftewel een verkleinde versie. Het idee is dat je het origineel behoudt, maar ook een kleine, webvriendelijke kopie maakt, en die kleine kopie toont in lijsten en voorbeelden. Het volledige bestand laadt pas zodra iemand het echt groot wil bekijken.

“Maak bij het uploaden van een afbeelding ook een kleinere, verkleinde versie voor voorbeelden en lijsten. Toon standaard de kleine versie en laad de volledige afbeelding alleen wanneer iemand erop klikt om hem groot te bekijken.”

Je hoeft niet te begrijpen hoe dat technisch werkt. Je hoeft alleen te weten dat het bestaat, zodat je erom kunt vragen vóórdat je app traag aanvoelt, in plaats van erna.

Een paar stillere zaken die het waard zijn om te beslissen

Deze drie beslissingen breken je app niet als je ze overslaat, maar ze zijn nu goedkoper om te maken dan later achteraf in te bouwen: wie het bestand mag zien, wat ermee gebeurt als het record wordt verwijderd, en of uploaden op een telefoon werkt.

Wie mag het bestand zien? Een profielfoto mag iedereen bekijken. Een gescand ID-bewijs of een ondertekend contract niet. Als het bestand privé is, vertel je builder dan dat de link inloggen moet vereisen, en geen publieke URL mag zijn die iedereen zomaar kan openen. Dit is het punt waar ik het hardst op zou aandringen bij alles wat gevoelig is.
Wat gebeurt er als het record wordt verwijderd? Als iemand een uitgave verwijdert, moet de bijbehorende bonfoto dan ook worden opgeruimd? Anders hoop je langzaam wees-bestanden op waar je voor betaalt en waarvan je vergeten bent dat ze er nog waren.
Werkt het op een telefoon? De meeste uploads gebeuren op telefoons, en telefoons bieden zowel “maak nu een foto” als “kies uit bibliotheek.” Test beide op een echte telefoon, niet alleen op je laptop waar je alleen ooit een bestand naar binnen sleept.

Test het zoals een vreemde het zou doen

Test het door bewust te proberen het kapot te maken op de manier waarop een echte gebruiker dat per ongeluk zal doen — een normale foto, een te groot bestand, het verkeerde bestandstype, een live upload vanaf de telefooncamera, en een verwijdering — voordat je het klaar verklaart:

Upload een normale telefoonfoto. Verschijnt hij, en is het voorbeeld snel?
Upload iets enorms. Stopt de app je met een duidelijk bericht, of blijft hij gewoon hangen?
Upload het verkeerde type — een pdf waar een foto wordt verwacht. Legt hij de regel uit?
Open de app op je telefoon en upload rechtstreeks vanaf de camera.
Verwijder een record en controleer of het bijbehorende bestand wordt afgehandeld zoals je had besloten.

Als deze vijf dingen goed gaan, heb je de scherpe randjes eruit gehaald waar de meeste mensen over struikelen.

Uploads zijn een van die functies waarbij de kloof tussen “werkt in de demo” en “werkt voor een vreemde in de trein met een kattenfoto van 12 MB” precies bestaat uit de beslissingen hierboven. Geen daarvan is moeilijk. Ze zijn alleen makkelijk om over te slaan — en nu ernaar vragen is veel makkelijker dan het later herstellen.

Als je het toevoegen van uploads hebt uitgesteld omdat het aanvoelde als een grote technische sprong: dat is het niet. Open je builder, vraag om afbeeldingsopslag met een groottelimiet en een thumbnail, en kijk wat hij je geeft. Probeer het daarna kapot te maken op je telefoon — dat is de echte test, en het kost je vijf minuten.