Je AI-app werkt in de demo. Nu is het tijd voor echte gebruikers.
Je beschrijft een idee aan een AI-ontwikkeltool. Die maakt schermen, formulieren, navigatie en een database. Je past wat aan, koppelt een dienst en ineens werkt het concept.
Je kunt de app openen, een account aanmaken, de hoofdactie afronden en het resultaat aan iemand anders laten zien.
Dat is een betekenisvolle mijlpaal.
Een werkende demo bewijst dat het idee tastbaar kan worden.
Hij helpt je het concept uit te leggen, vroege interesse te wekken, de vraag te testen of intern draagvlak te krijgen.
De volgende fase begint zodra de app niet meer alleen wordt gebruikt door degene die hem heeft gemaakt.
Echte gebruikers volgen het demoscript niet.
Ze vergeten wachtwoorden. Vullen onverwachte informatie in. Klikken twee keer. Verliezen hun verbinding. Gebruiken een oude telefoon. Weigeren permissies. Haken halverwege af. Komen later terug. Vragen hun geld terug. Delen een account. Proberen iets te openen wat ze niet mogen zien.
Dat maakt je AI-app geen mislukking.
Het betekent dat het project van demonstratie naar product gaat.
Test meer dan het happy path
Het happy path is de ideale route door een app.
Bijvoorbeeld:
- De gebruiker maakt een account aan.
- De bevestigingsmail komt aan.
- De gebruiker logt in.
- Hij vult geldige informatie in.
- De betaling slaagt.
- Het bedoelde resultaat verschijnt.
Een demo volgt meestal dit pad.
Een echt product moet ook overweg met alternatieven.
Wat gebeurt er als:
- Het e-mailadres al bestaat?
- De bevestigingsmail niet aankomt?
- De gebruiker het wachtwoord vergeet?
- De resetlink voor het wachtwoord is verlopen?
- De gebruiker een ongeldig telefoonnummer invult?
- Een verplicht veld leeg is?
- Een geüpload bestand te groot is?
- De betaling wordt geweigerd?
- De gebruiker halverwege de pagina ververst?
- Dezelfde actie twee keer wordt verstuurd?
- Een externe dienst niet beschikbaar is?
- De gebruiker zijn verbinding verliest?
- Het account wordt verwijderd?
- De gebruiker zijn gegevens opvraagt?
Dit zijn geen zeldzame randgevallen. Het zijn normale onderdelen van een product draaiend houden.
Loop rollen en permissies na
Veel applicaties hebben meer dan één type gebruiker.
Denk aan:
- Klanten
- Medewerkers
- Managers
- Beheerders
- Leveranciers
- Partners
- Gasten
Elke rol mag alleen zien en wijzigen wat passend is.
Check of:
- Gebruikers bij de gegevens van een andere gebruiker kunnen
- Gewone gebruikers beheerschermen kunnen bereiken
- Links records blootleggen die privé moeten blijven
- Verwijderde accounts toegankelijk blijven
- Medewerkers ruimere rechten hebben dan nodig
- Rollen worden afgedwongen in het onderliggende systeem in plaats van alleen verborgen in de interface
Een knop die onzichtbaar is, is niet hetzelfde als een actie die veilig is afgeschermd.
Dit is een van de onderdelen die je niet goed kunt beoordelen met een gewone scan van de openbare website.
Daarvoor is toegang tot het project zelf nodig.
Weet waar de data heen gaat
Een app die met AI is gebouwd, kan snel meerdere diensten koppelen.
Bijvoorbeeld:
- Authenticatie
- Database
- E-mailverzending
- Bestandsopslag
- Betalingen
- Webanalyse
- Klantenservice
- Automatisering
- AI-modellen
- Externe API's
Maak een helder overzicht van:
- Welke diensten worden gebruikt
- Welke data elke dienst ontvangt
- Waar de data wordt opgeslagen
- Wie eigenaar is van elk account
- Met welke betaalmethode het wordt betaald
- Wat er gebeurt als een gratis tegoed opraakt
- Of productie- en testdata gescheiden zijn
- Of er back-ups bestaan
- Hoe data geëxporteerd kan worden
- Hoe toegang ingetrokken kan worden
Projecten worden vaak lastig te onderhouden wanneer belangrijke diensten blijven hangen aan persoonlijke accounts, tijdelijke proefperiodes of inloggegevens uit de experimenteerfase.
Afmaken betekent die experimentele koppelingen omzetten in een begrijpelijke operationele opzet.
Bescherm inloggegevens en privé-informatie
API-keys, wachtwoorden, databasegegevens en privétokens horen niet in openbare code of in de browser te staan.
Check hoe het project omgaat met:
- Betaalgegevens
- Database-keys
- Keys van e-maildiensten
- Keys van AI-diensten
- Beheerdersaccounts
- Geheime sleutels van externe koppelingen
Check ook of logs, foutmeldingen of browsertools gevoelige informatie prijsgeven.
Ga er niet vanuit dat een project onveilig is omdat het met AI is gemaakt.
Ga er ook niet vanuit dat het veilig is omdat het hoofdscherm werkt.
De juiste aanpak is: controleren.
Bereid je voor op storingen
Elke externe dienst reageert vroeg of laat traag, geeft een fout of is tijdelijk niet beschikbaar.
Een betrouwbare app mag dan niet instorten tot een leeg scherm.
Denk na over:
- Wat de gebruiker ziet als een actie mislukt
- Of hij het veilig opnieuw kan proberen
- Of dubbele betalingen of records worden voorkomen
- Of het systeem de fout vastlegt
- Of iemand een melding krijgt
- Of onafgemaakte acties hersteld kunnen worden
- Of supportmedewerkers kunnen begrijpen wat er is gebeurd
Nuttige foutmeldingen helpen de gebruiker verder zonder technische of gevoelige informatie prijs te geven.
Het projectteam moet ook genoeg informatie hebben om het probleem te achterhalen.
Scheid test- en productieomgevingen
Tijdens de ontwikkeling is experimenteren normaal.
Je maakt testgebruikers, testtransacties, tijdelijke records en onafgemaakte functies.
Bepaal voordat je echte gebruikers uitnodigt of het project aparte omgevingen nodig heeft voor:
- Ontwikkeling
- Testen
- Staging
- Productie
Minimaal geldt: echte klantdata en echte betalingen horen niet zomaar gemengd te worden met lopende experimenten.
Uitrollen moet ook herhaalbaar zijn.
Een kleine wijziging mag niet afhangen van het onthouden van een fragiele reeks handmatige stappen.
Bepaal wie het gaat onderhouden
De lancering van de app is niet het einde van de ontwikkeling.
Na de lancering moet iemand zich buigen over:
- Software-updates
- Wijzigingen bij diensten
- Mislukte koppelingen
- Beveiligingsmeldingen
- Gebruikersondersteuning
- Datacorrecties
- Prestaties
- Back-ups
- Problemen met nieuwe apparaten of browsers
- Kostenstijgingen
- Verzoeken om nieuwe functies
Het project mag niet volledig afhangen van een gespreksgeschiedenis in één AI-tool.
Zorg dat het bedrijf toegang heeft tot:
- De code
- Het account van de bouwtool
- Hosting
- Domeininstellingen
- Database
- Externe diensten
- Documentatie
- Inloggegevens
- Facturatie-accounts
Eigenaarschap en onderhoudbaarheid horen bij afmaken.
Begin met een gestructureerde beoordeling
Een openbare SiteScan kan nog steeds nuttig zijn wanneer de app een betekenisvolle openbare kant heeft.
Die helpt beoordelen:
- Mobiele bruikbaarheid
- Toegankelijkheid
- Prestaties
- Openbare content
- Formulieren
- Vertrouwen
- Calls-to-action
Hij kan niet vaststellen of authenticatie, permissies, databases, koppelingen, privédata of livegang goed zijn ingericht.
Daarom vraagt een app of platform meestal om een AI-projectbeoordeling.
Het doel is niet om redenen te zoeken om alles opnieuw te bouwen.
De beoordeling moet vaststellen:
- Wat kan blijven
- Wat verbetering nodig heeft
- Wat gecorrigeerd moet worden voordat echte gebruikers komen
- Wat veilig kan wachten
- Wat de volgende ontwikkelfase moet bevatten
Het resultaat is een praktische routekaart om het project af te maken.
Je hebt al bewezen dat het idee kan werken.
Nu moet het project bewijzen dat het blijft werken als echte gebruikers komen.