Lovable gebruiken: stap voor stap je eerste app bouwenLeestijd: maximaal 11 minuten

Lovable gebruiken begint met beschrijven wat je wilt maken. Maar een bruikbare app ontstaat pas wanneer je ook controleert wat de knoppen, formulieren en opgeslagen gegevens doen. In deze handleiding bouw je daarom één concreet voorbeeld: een eenvoudige aanvraagtracker voor een buurtwerkplaats.

Je begint met fictieve aanvragen. Daarna verbeter je de bediening, controleer je de opslag en test je de app op je telefoon. Geen compleet bedrijfsplatform, maar een eerste versie waarvan je begrijpt wat werkt en wat nog niet.

Wat heb je nodig voordat je begint?

Voor deze oefening gebruik je een laptop of computer met een browser, een Lovable-account en een telefoon voor de eindtest. Je kunt rechtstreeks in de browser beginnen en je opdrachten in het Nederlands schrijven.

Je bouwt hier een webapp: een toepassing die je via een webadres opent. Je hoeft dus geen app in een appwinkel te plaatsen om iemand te laten meekijken.

Voor het voorbeeld spreken we drie grenzen af:

• We gebruiken uitsluitend fictieve aanvraagcodes.
• We bouwen nog geen gedeeld systeem voor meerdere medewerkers.
• We voegen geen betalingen, e-mails of klantaccounts toe.

Dat is geen gebrek aan ambitie. Minder onderdelen maken het gemakkelijker om te zien waar een fout ontstaat.

Wil je eerst de basis begrijpen? Lees dan wat Lovable is en hoe de AI-appbouwer werkt.

Stap 1: bepaal wat je app moet oplossen

Stel je een buurtwerkplaats voor waar vrijwilligers reparatieverzoeken bijhouden. De ene aanvraag staat op papier, een andere in een bericht. Bij de overdracht is niet duidelijk welke reparaties nog wachten.

Dit is een fictieve gebruikssituatie. We gebruiken haar omdat het probleem herkenbaar is én klein genoeg om gericht te oefenen.

Onze app moet één vraag beantwoorden: welke aanvragen zijn nieuw, in behandeling of klaar?

Vul vóór het bouwen deze mini-briefing in:

Een scherm tekenen is vaak gemakkelijker dan een afspraak maken. Wat betekent bijvoorbeeld “klaar”: gerepareerd of opgehaald? Wij kiezen hier voor gerepareerd. Zo voorkom je dat dezelfde status twee betekenissen krijgt.

Stap 2: schrijf een goede eerste prompt

Een goede opdracht beschrijft niet alleen het uiterlijk. Ze vertelt wie de app gebruikt, wat moet gebeuren en wat buiten de opdracht valt.

Kopieer deze prompt van Maarten:

Bouw een Nederlandstalige oefenapp met de naam WerkplaatsOverzicht.

Gebruiker en doel
Eén coördinator van een buurtwerkplaats wil fictieve reparatieaanvragen bijhouden.

Scherm
Maak één overzichtspagina met een knop ‘Aanvraag toevoegen’. Open daarmee een formulier.

Gegevens
Iedere aanvraag heeft een unieke aanvraagcode, een voorwerp, een korte omschrijving en een status. Gebruik de statussen Nieuw, In behandeling en Klaar. Klaar betekent gerepareerd, niet opgehaald.

Functies
Laat aanvragen toevoegen, op status filteren en van status veranderen. Maak aanvraagcode en voorwerp verplicht. Weiger een aanvraagcode die al bestaat. Voeg vijf duidelijk fictieve voorbeelden toe.

Opslag en grenzen
Bewaar de oefengegevens lokaal in deze browser, ook na verversen. Gebruik nog geen database, accounts of externe koppelingen. Toon duidelijk: ‘Oefenversie: gegevens blijven alleen in deze browser.’

Ontwerp
Gebruik rustige kleuren, duidelijke Nederlandse knoppen en goed leesbare tekst. Maak het overzicht bruikbaar op computer en telefoon. Voeg geen extra functies toe.

Waarom zoveel aandacht voor grenzen? “Maak een aanvraagtracker” laat belangrijke beslissingen open. Deze opdracht maakt de gewenste werking controleerbaar.

Een langere prompt is niet automatisch beter. Een duidelijke afspraak over dubbele aanvraagcodes is nuttiger dan tien zinnen over een moderne uitstraling.

Stap 3: genereer je eerste versie

Open Lovable, meld je aan en plak de opdracht in het startveld. Kies Build om de app te laten bouwen. Bij een uitgebreider idee kun je eerst Plan mode gebruiken om de aanpak te bespreken voordat er code wordt gewijzigd.

Na het bouwen zie je de projectchat en de voorbeeldweergave van je app. Gebruik die weergave om zelf door de eerste versie te klikken.

Controleer eerst de route:

1. Vind je de knop om een aanvraag toe te voegen?
2. Begrijp je de veldnamen?
3. Verschijnt een nieuwe aanvraag in het overzicht?
4. Kun je de status wijzigen?
5. Toont het filter de juiste aanvragen?

Ga nog niet meteen kleuren aanpassen. Als het formulier onlogisch werkt, maakt een mooiere knop dat probleem alleen aantrekkelijker.

Prompt-autopsie: wat ging er mis?

Neem de vage opdracht: “Maak een handige reparatieapp.”

Die zegt niet of bezoekers zelf aanvragen indienen, of medewerkers ze beheren. Ook ontbreken afspraken over opslag en statussen.

Onderstaande mismatches zijn mogelijke uitkomsten, geen gemeten testbevindingen:

Zo onderzoek je een tegenvallend resultaat zonder meteen de hele app opnieuw te laten bouwen.

Stap 4: verbeter de app met gerichte prompts

Stel dat de statusknop onduidelijk is. Vraag dan niet: “Maak de app gebruiksvriendelijker.”

Gebruik liever:

Vervang in het aanvraagoverzicht de onduidelijke statusknop door een keuzelijst met Nieuw, In behandeling en Klaar. Bewaar de gekozen status. Verander het formulier, de filters en de overige vormgeving niet.

Je noemt de plek, de gewenste wijziging en wat behouden moet blijven. Controleer daarna ook het toevoegen en filteren opnieuw. Dat past bij Lovables aanbevolen werkwijze: kleine wijzigingen, gevolgd door controle in de preview.

Markeer een goed werkende versie via History met een bookmark. Je kunt eerdere versies bekijken en herstellen. Let op: terugzetten herstelt de code, niet automatisch de gegevens in een gekoppelde database.

Blijft een fout terugkomen? Laat eerst de oorzaak onderzoeken. Nogmaals “repareer dit” sturen helpt weinig wanneer het probleem verkeerd wordt begrepen.

Even tussendoor. Wil je vooraf weten welke ruimte je zonder abonnement hebt? Bekijk dan Lovable gratis gebruiken.

Stap 5: controleer of de functies echt werken

Een melding “Opgeslagen” is een mededeling van de app, geen bewijs.

Voer daarom zelf een fictieve aanvraag in:

• Code: TEST-006
• Voorwerp: Bureaulamp
• Omschrijving: Schakelaar reageert niet
• Status: Nieuw

Verander de status naar In behandeling. Ververs daarna de pagina en zoek TEST-006 opnieuw.

Staat de aanvraag er nog met de juiste status? Sluit vervolgens het tabblad en open dezelfde app opnieuw in dezelfde browser.

Voor onze oefenapp vragen we lokale opslag. Dat is geen gedeelde opslag en geen back-up. Een andere browser of telefoon heeft niet vanzelf dezelfde aanvragen.

Wil je later met meerdere medewerkers werken? Dan verandert de opdracht. Lovable Cloud biedt onder meer een database en gebruikersaccounts, zonder dat je daarvoor verplicht een afzonderlijk Supabase-project hoeft op te zetten. Dat vraagt wel nieuwe controles op toegang en gegevensverwerking.

De bestaande Lovable-review met onze portaalproef laat zien waarom een overtuigende eerste versie nog geen volledig geteste toepassing is.

Stap 6: test fouten, mobiel gebruik en privacy

De normale route vertelt maar een deel van het verhaal. Probeer ook invoer die je liever niet krijgt.

Dit zijn gewenste uitkomsten. Vink ze pas af nadat je ze werkelijk hebt gecontroleerd.

Schakel daarna naar Mobile view in de voorbeeldweergave en test later ook op een echte telefoon. De officiële startgids noemt die mobiele controle expliciet vóór publicatie.

Loopt het overzicht buiten beeld? Gebruik:

Op een smal telefoonscherm valt de statuskeuze buiten beeld. Toon aanvragen op mobiel als kaarten onder elkaar. Houd alle velden en acties bereikbaar. Laat de desktopweergave en werking ongewijzigd.

Controleer vervolgens beide schermformaten.

Gebruik nog steeds geen echte namen, telefoonnummers of reparatiegegevens. Een geslaagde oefening bewijst niet dat de app geschikt is voor persoonsgegevens.

Voeg je later accounts toe? Controleer dan met twee testgebruikers wie welke gegevens kan bekijken en wijzigen. Een inlogscherm en toegangsrechten zijn verschillende onderdelen.

Stap 7: laat iemand anders je app testen

Nu komt een verrassend nuttige stap: even niets uitleggen.

Geef een proefgebruiker deze opdracht:

Voeg aanvraag TEST-007 voor een kapotte waterkoker toe. Zet de aanvraag daarna op In behandeling en toon alleen aanvragen met die status.

Noteer waar iemand zoekt, twijfelt of verkeerd klikt. Een foutloze uitvoering met jouw aanwijzingen zegt minder dan een zelfstandige uitvoering zonder hulp.

Om de app te delen, klik je rechtsboven op Publish. Controleer het voorgestelde webadres, de toegang en eventuele beveiligingsmeldingen. Publiceer vervolgens de oefenversie.

Belangrijk: wijzigingen in de preview verschijnen niet automatisch op de gepubliceerde app. Gebruik na een aanpassing Publish → Publish changes.

De proefgebruiker werkt bij onze lokale oefenapp met eigen browsergegevens. Dat is verwacht gedrag, geen bewijs dat gedeeld samenwerken al werkt.

Veelgemaakte fouten bij het bouwen met Lovable

De grootste beginnersfout is niet een verkeerde knop aanklikken. Het is doorgaan zonder vast te stellen of de vorige stap klopt.

Let vooral op deze valkuilen:

• Alles tegelijk bouwen: je weet niet welke wijziging een probleem veroorzaakt.
• Alleen uiterlijk beoordelen: een verzorgd scherm kan verkeerde regels volgen.
• Een bevestiging geloven: controleer de gegevens na verversen.
• Alleen de ideale route testen: probeer ook lege en dubbele invoer.
• Preview en live verwarren: publiceer verbeteringen opnieuw.
• Lokale opslag als samenwerking zien: iedere browser heeft zijn eigen oefengegevens.

Onze visie bij WegwijsAI: Lovable gebruiken is ook leren beoordelen wat je hebt laten maken. Je hoeft niet iedere regel code te begrijpen om een heldere verwachting te formuleren en die te controleren.

Twijfel je of je voor jouw idee überhaupt een appbouwer nodig hebt? Onze keuzehulp voor AI-tools helpt je eerst het juiste soort hulpmiddel te kiezen.

Eindcheck: is je eerste versie klaar om te demonstreren?

Je eerste app hoeft niet alles te kunnen. Wel moet duidelijk zijn wat iemand ermee kan doen.

• Ik kan een fictieve aanvraag toevoegen.
• Verplichte velden en dubbele codes worden gecontroleerd.
• Status wijzigen en filteren werken.
• De wijziging blijft in dezelfde browser bewaard.
• De app is op mijn telefoon bruikbaar.
• Een proefgebruiker kan de hoofdtaak zonder uitleg uitvoeren.
• De beperking van lokale opslag staat zichtbaar vermeld.
• De gepubliceerde versie bevat mijn laatste verbeteringen.

Zijn deze punten gecontroleerd? Dan heb je een afgebakende oefenapp om te demonstreren. Nog geen gedeeld bedrijfssysteem, maar wel een basis die je kunt uitleggen.

Wil je Lovable gebruiken voor een volgend project? Voeg eerst één nieuwe functie toe en herhaal dezelfde controles.

Dit artikel is geschreven en gecontroleerd door Maarten en Sanne van WegwijsAI.

FAQ

Kan ik Lovable gebruiken zonder te kunnen programmeren?

Je kunt een eerste app laten bouwen door in gewone taal te beschrijven wat die moet doen. Voor deze oefening hoef je zelf geen code te schrijven. Je moet wel controleren of de gegenereerde werking klopt. Bij gedeelde apps, gevoelige gegevens of ingewikkelde processen kan aanvullende technische beoordeling nodig zijn.

Waarom verdwijnen mijn gegevens na het verversen?

Dat hangt af van de manier waarop de app gegevens bewaart. Alleen iets op het scherm tonen is niet hetzelfde als het opslaan. In deze tutorial vraag je expliciet om lokale browseropslag en controleer je die na verversen. Voor gedeelde gegevens tussen gebruikers is een andere inrichting nodig, bijvoorbeeld met Lovable Cloud.

Waarom zie ik mijn verbeteringen niet op de gepubliceerde app?

De gepubliceerde app is een afzonderlijke momentopname. Aanpassingen kunnen al zichtbaar zijn in de preview terwijl bezoekers nog de eerdere versie zien. Open Publish en kies Publish changes om de bijgewerkte versie live te zetten