Prompten in Lovable

De kwaliteit van wat Lovable bouwt, hangt sterk af van de kwaliteit van je prompt. Een vage instructie levert een vage eerste versie op; een scherpe, specifieke prompt levert vaak in één keer bruikbaar resultaat op. Deze gids laat zien hoe je prompts opbouwt, itereert en debugt.

Nog geen Lovable-account? Start gratis met Lovable en oefen de voorbeelden hieronder direct in je eigen project.

De anatomie van een goede prompt

Een prompt die goed werkt, bevat meestal deze onderdelen:

Onderdeel	Waarom het helpt
Doel	Wat moet het onderdeel doen?
Doelgroep	Voor wie is dit, en wat weten zij al?
Data	Welke gegevens komen erin, statisch of uit de database?
States	Hoe ziet leeg/laden/fout/succes eruit?
Edge cases	Wat gebeurt er bij extreem lange tekst, geen resultaten, geen internet?
Designrichting	Stijl, kleuren, referenties naar bestaande onderdelen

Hoe meer van deze onderdelen je invult, hoe minder correctierondes je nodig hebt.

Voorbeeldprompts: kort vs. lang

Een korte prompt werkt prima voor kleine, duidelijke wijzigingen:

Voeg een "terug naar boven"-knop toe die verschijnt zodra iemand
verder dan 400px naar beneden scrolt.

Voor iets groters loont een uitgebreidere prompt. Vergelijk:

Voor (te vaag):

Maak een contactpagina.

Na (concreet):

Maak een contactpagina met:
- Een formulier met naam, e-mail, telefoon (optioneel) en bericht
- Validatie: naam en e-mail verplicht, e-mail moet geldig formaat hebben
- Een succesmelding na versturen, en een duidelijke foutmelding als
  het versturen mislukt
- Rechts op desktop een blok met adresgegevens en een kaart
- Stijl: zelfde look als de bestaande "Over ons"-pagina, gebruik
  dezelfde knoppen en kleuren

De tweede prompt levert vrijwel altijd een bruikbaarder resultaat op, omdat states (succes/fout) en designrichting al zijn ingevuld.

Itereren in kleine stappen

Vraag niet alles in één keer. Bouw op:

Stap 1: Maak het basisformulier met de velden naam, e-mail en bericht.

Controleer de preview, en ga dan verder:

Stap 2: Voeg validatie toe: naam en e-mail verplicht, e-mail moet
een geldig formaat hebben. Toon foutmeldingen onder het veld zelf.

En pas daarna:

Stap 3: Voeg een succes- en foutmelding toe na versturen, en maak
het formulier read-only tijdens het versturen zelf.

Zo blijft elke fout klein en makkelijk terug te herleiden, en kun je bij twijfel gericht terug naar een eerdere versie.

Refereren aan bestaande componenten

Lovable bouwt consistenter als je verwijst naar wat er al bestaat, in plaats van steeds opnieuw te beschrijven hoe iets eruit moet zien:

Gebruik dezelfde kaartcomponent als op de homepage voor de
teamledenpagina, maar toon hier naam, functie en foto in plaats
van titel en beschrijving.

Dit voorkomt wildgroei aan net-iets-andere knoppen, kaarten en formulieren door je hele project.

Debuggen via foutmelding en console

Loopt iets vast, geef dan niet alleen "het werkt niet" door. Kopieer de exacte foutmelding uit de console of het netwerktabblad:

De pagina crasht met deze foutmelding in de console:
"TypeError: Cannot read properties of undefined (reading 'map')"
op de productoverzichtspagina. Los dit op en zorg dat de pagina
een nette lege-staat toont als er geen producten zijn.

Een exacte foutmelding plus de context (welke pagina, welke actie) levert vrijwel altijd sneller een correcte fix op dan een algemene klacht.

Prompts voor SEO, performance en toegankelijkheid

Deze onderwerpen worden vaak vergeten, maar zijn prima te prompten als je specifiek bent:

Controleer of elke pagina een unieke title en meta description
heeft. Voeg ontbrekende alt-teksten toe aan afbeeldingen op basis
van de context van de pagina.

Deze pagina laadt traag door een grote hero-afbeelding. Optimaliseer
het laden (bijvoorbeeld lazy loading voor content onder de vouw) 
zonder de layout te veranderen.

Controleer de contactpagina op toegankelijkheid: labels bij
formuliervelden, focus-states op interactieve elementen, en
voldoende kleurcontrast tussen tekst en achtergrond.

Wat je juist niet via een prompt moet oplossen

Niet alles hoort in een prompt thuis. Wees terughoudend met:

• Security-kritieke autorisatielogica — laat een menselijke reviewer meekijken naar RLS-regels en wie bij welke data mag, zeker bij gevoelige gegevens.
• Complexe architecturale keuzes — gebruik plan-modus en denk zelf mee, in plaats van te vertrouwen dat één prompt de juiste structuur kiest.
• Juridische of compliance-teksten — een prompt kan een concept schrijven, maar laat privacyverklaringen en voorwaarden altijd door een deskundige checken.
• Prijsberekeningen met complexe bedrijfsregels — beschrijf de regels heel precies, en test de uitkomst zelf; vertrouw niet blind op wat er gegenereerd wordt.
• Alles in één megaprompt — grote, vage verzoeken leiden tot resultaten die je daarna alsnog stuk voor stuk moet corrigeren.

Herbruikbaar prompt-template

Gebruik dit sjabloon als startpunt voor nieuwe features:

Doel: [wat moet dit onderdeel doen]
Doelgroep: [voor wie is dit bedoeld]
Locatie: [op welke pagina/waar in de app]

Data:
- [welke gegevens, statisch of uit de database]

States:
- Leeg: [wat zie je als er geen data is]
- Laden: [hoe ziet het laden eruit]
- Fout: [wat zie je bij een fout]
- Succes: [wat zie je bij succes]

Edge cases:
- [bijvoorbeeld: heel lange tekst, geen internet, extreem veel resultaten]

Designrichting:
- [verwijs naar bestaande pagina's/componenten, of beschrijf stijl]

Vul dit sjabloon in en plak het als prompt: je bespaart jezelf meerdere correctierondes.

Wat we adviseren

Begin klein, controleer elke stap in de preview, en gebruik plan-modus zodra een wijziging meerdere pagina's of het datamodel raakt. Combineer dat met specifieke, foutmelding-gedreven debug-prompts, en laat gevoelige logica (autorisatie, betalingen) altijd door een mens reviewen. Wil je hulp bij het opzetten van een prompt-workflow voor je team, kijk dan bij webdesign of neem contact op.

Veelgestelde vragen

Hoe lang moet een prompt zijn?

Zo lang als nodig om doel, data, states en edge cases duidelijk te maken — vaak een paar zinnen tot een korte lijst, niet per se een lang essay.

Kan ik een eerdere prompt aanpassen in plaats van een nieuwe te schrijven?

Nee, je stuurt bij met een nieuwe instructie in de chat. Gebruik rollback naar een eerdere versie als een stap de verkeerde kant op ging.

Werkt prompten in het Engels beter dan in het Nederlands?

Beide werken, kies de taal waarin je zelf het preciest kunt formuleren. Consistentie binnen één project helpt wel.

Wat als Lovable iets blijft fout doen na meerdere pogingen?

Geef de exacte foutmelding, beschrijf wat je al geprobeerd hebt, en overweeg het probleem op te knippen in een kleinere stap. Blijft het lastig, dan is dat een goed moment om een developer te laten meekijken via webdesign.