Een mobiele app bouwen zonder code: waarom je met AI gebouwde app er misschien al een is

Vroeg of laat stelt iemand die je met AI gebouwde app gebruikt de vraag: “Is er een app die ik kan downloaden?” En als je bent zoals de meeste niet-technische oprichters, zakt je maag een beetje — want je hebt gehoord dat in de App Store komen ontwikkelaars betekent, maanden werk, en Apples beoordelingsproces. Het goede nieuws: een mobiele app bouwen zonder code is vooral een vraag die je al hebt beantwoord. Je webapp kan de mobiele app zijn. Hij heeft alleen een beetje hulp nodig.

De vraag die bijna een werkend bedrijf ontspoorde

Een boekhoudcoach die we kennen bouwde een klantenportaal met AI — haar klanten uploaden bonnetjes, zien hun maandelijkse samenvattingen, en sturen haar berichten, allemaal op één plek. Het werkte. Klanten waren er dol op. Toen vroegen er drie, in dezelfde maand, of er “een app voor mijn telefoon” was.

Ze deed wat de meeste mensen doen: googelde “hoe krijg ik een app in de App Store”, vond offertes van bureaus vanaf $15.000, las over ontwikkelaarsaccounts en beoordelingsrichtlijnen, en concludeerde dat haar product tegen een muur was gelopen die ze niet kon betalen om te beklimmen.

Hier is wat ze nog niet wist: haar klanten vroegen niet om een App Store-app. Ze vroegen om drie specifieke dingen — ik wil hem openen vanaf mijn beginscherm, ik wil dat hij er goed uitziet op mijn telefoon, en ik wil niet elke keer inloggen. Alle drie waren in een middag op te lossen, binnen de app die ze al had, zonder code te schrijven.

Dat is het patroon dat het waard is om je eigen te maken: wanneer gebruikers “app” zeggen, beschrijven ze meestal een ervaring, geen distributiekanaal.

Stap 1: gebruik je eigen app op je eigen telefoon — goed

Voordat je iets verandert, kom erachter waar je gebruikers echt mee leven. Open je app op je telefoon — niet de preview in je AI-bouwer, je echte telefoon — en doe een complete taak alsof je een klant was. Upload het bonnetje. Boek de sessie. Betaal de factuur.

De meeste mensen die dit eerlijk doen, vinden dezelfde drie problemen:

• Knoppen en links zijn te klein om aan te tikken. Je vinger is geen muiscursor. Als je moet inzoomen om een knop te raken, doet elke gebruiker dat ook.
• Tabellen en formulieren lopen buiten het scherm. Dat nette dashboard met zes kolommen wordt een zijwaarts-scrollende warboel op een telefoon.
• Typen is pijnlijk. Een formulier dat een minuut kost op een laptop, kost vijf op een telefoon, vooral als het verkeerde toetsenbord verschijnt (letters terwijl het veld cijfers wil) of de pagina rondspringt terwijl je typt.

Schrijf op wat je irriteerde. Wees specifiek. “De bon-uploadknop staat onder de vouw en is klein” is een te repareren instructie; “het voelt slecht op mobiel” niet.

Stap 2: vraag je AI-bouwer om hem telefoonvriendelijk te maken

Neem je lijst mee naar je AI-bouwer en werk hem item voor item door. Het toverwoord, als je het wilt, is “responsive” — het betekent dat de lay-out zichzelf herschikt om op het scherm te passen in plaats van te krimpen. Maar je hebt het jargon niet nodig. Gewone beschrijvingen werken:

“Op een telefoon vereist het klantdashboard zijwaarts scrollen. Herschik het zodat alles op een telefoonscherm past — stapel de secties verticaal indien nodig.”

“Maak alle knoppen groot genoeg om makkelijk aan te tikken op een telefoon.”

“Laat op het bon-uploadformulier het bedragveld het cijfertoetsenbord oproepen.”

Check dan elke fix op je echte telefoon voordat je naar de volgende gaat, op dezelfde manier als je elke wijziging aan je app zou testen. Eén wijziging, één check. Mobiele lay-outs zijn lastig, en een fix voor één schermgrootte duwt soms een andere uit positie — je wilt dat opmerken terwijl de wijziging vers is.

Nog een verzoek dat het waard is om te maken terwijl je toch bezig bent: vraag je bouwer om gebruikers ingelogd te houden op hun eigen apparaten in plaats van elk bezoek om een wachtwoord te vragen. Voor een app die mensen op hun telefoon in vrije momenten gebruiken, doet deze ene wijziging meer voor “voelt als een echte app” dan wat dan ook visueels.

Stap 3: zet een icoon op hun beginscherm

Hier is het deel dat verrassend weinig oprichters weten. Elke moderne telefoon kan een website vastpinnen aan het beginscherm zodat hij opent als een app — zijn eigen icoon, volledig scherm, geen browseradresbalk. Je AI-bouwer kan je app zo opzetten dat dit goed werkt: vraag erom bij naam —

“Maak mijn app installeerbaar als een progressive web app, met ons logo als icoon.”

Een progressive web app (PWA) is gewoon een website met de juiste instellingen om zich als een geïnstalleerde app te gedragen. Zodra hij is geconfigureerd, is de ervaring voor je gebruikers: bezoek de app, tik op “Toevoegen aan beginscherm” (je kunt een kleine hint tonen voor eerste-keer-bezoekers), en vanaf dan staat hij naast Instagram en hun bank-app. De meesten zullen nooit weten of erom geven dat hij niet uit een appstore komt. Dit is de versie van een mobiele app bouwen zonder code die niemand noemt in die bureau-offertes — want er valt niets te offreren.

Het “app-probleem” van de boekhoudcoach werd precies zo opgelost: een responsive-ronde op haar vijf meestgebruikte schermen, persistente login, en een beginscherm-icoon met haar logo. Totale kosten: één middag en nul dollar. Twee van de drie klanten die om een app hadden gevraagd, vertelden haar dat ze “de nieuwe app” leuk vonden. Het was dezelfde app.

Wanneer je echt de App Store nodig hebt

Nu het eerlijke deel: een beginscherm-webapp dekt de meeste producten, maar niet alle. De App Store-route begint ergens op te slaan wanneer:

• Je app helemaal zonder internet moet werken — veldwerk in afgelegen gebieden, bijvoorbeeld. Webapps kunnen korte offline-momenten aan, maar zwaar offline-gebruik bevoordeelt native apps.
• Je afhangt van diepe telefoonfuncties — dingen als achtergrondlocatie voor een bezorgtracker, of geavanceerde camerabesturing. Basale camera, foto’s en GPS werken allemaal prima vanuit webapps; het is het altijd-draaiende, diep geïntegreerde spul dat native nodig heeft.
• Gevonden worden door App Store-zoekopdrachten ertoe doet voor je groei. Als je klanten oprecht de store doorzoeken voor oplossingen zoals die van jou, is aanwezigheid daar marketing. (Voor de meeste nichetools doen ze dat niet — je klanten vinden je via de kanalen die je al hebt opgebouwd.)

Zelfs pushmeldingen — jarenlang de grote reden om native te gaan — werken nu vanuit webapps op zowel iPhone als Android, met wat configuratie. Vraag je AI-bouwer wat mogelijk is voordat je aanneemt dat je de store nodig hebt.

En als je uiteindelijk wel native gaat, weet waar je je voor inschrijft: ontwikkelaarsaccounts met jaarlijkse kosten, een beoordelingsproces gemeten in dagen, en — de echte kosten — twee extra versies van je product om voor altijd bij te werken. Dat is geen reden om het nooit te doen. Het is een reden om het te doen wanneer de businesscase onmiskenbaar is, niet wanneer de eerste gebruiker erom vraagt.

Begin met de telefoon die je al hebt

Doe deze week de tien-minuten-versie: open je app op je telefoon en voltooi één echte taak. Als het slecht gaat, heb je geen App Store-probleem — je hebt een middag aan fixes voor de boeg, en je weet nu precies wat ze zijn. Een mobiele app bouwen zonder code blijkt er veel uit te zien als de rest van met AI gebouwde software: minder over de technologiehorde die je je voorstelde, meer over opmerken wat je gebruikers echt bedoelden toen ze het vroegen.