Van prompt tot checkout: een POS beschrijven in gewone taal

Een POS beschrijven in gewone taal werkt, maar alleen als je je bedrijf beschrijft in plaats van de software. De beste beschrijvingen lezen alsof je een nieuwe medewerker inwerkt tijdens hun eerste werkdag: dit is wat we verkopen, dit is hoe mensen betalen, dit is wat er op de kassabon moet staan. Een op prompts gebaseerde builder kan zo'n beschrijving omzetten in een checkout waarmee je een echte verkoop kunt verwerken. Of je een werkende kassa krijgt of een mooi ogende demo komt neer op vijf details, en geen daarvan is technisch van aard.

Hoe klinkt een POS-beschrijving in gewone taal?

Het klinkt zoals jij op een dinsdag iemand de balie laat zien:

"Ik run een bakkerij met één kassa. We verkopen brood, gebak en filterkoffie. Gebakjes gaan per stuk of per half dozijn de deur uit. Koffie is verkrijgbaar in twee maten met verschillende melkopties. Bijna iedereen betaalt contactloos met een kaart, maar we accepteren ook nog contant geld. Hele broden zijn hier vrijgesteld van belasting; op al het andere zit btw. Klanten willen hun kassabon meestal per e-mail ontvangen."

Geen functienamen, geen schermen beschreven. Zeven zinnen die de gehele voorkant van de winkel dragen: de catalogus, de opties, de betaalmethoden, de belastingregels en de kassabon. Een builder kan daar wat mee. Waar het niets mee kan, is "maak een moderne POS voor een bakkerij", wat een sfeer beschrijft, geen bedrijf.

Welke vijf details bepalen of de checkout werkt?

De details waarnaar een nieuwe medewerker rond de lunchpauze zou vragen. Behandel elk punt in je eigen woorden:

• Wat je verkoopt en hoe het is gegroepeerd. Niet elk afzonderlijk artikel, maar de structuur van de catalogus: je categorieën, en of artikelen opties hebben zoals maat of extra's. Een POS noemt deze opties modificatoren (modifiers), en het weglaten ervan is de meest voorkomende reden waarom een eerste versie niet goed aanvoelt bij de kassa.

• Hoe mensen betalen. Kaart, contant of allebei, en of fooi geven een onderdeel is van je balie.

• Je belastingregels zoals je ze daadwerkelijk toepast. Niet de wetgeving, maar de realiteit in jouw winkel: waar belasting over wordt geheven, wat is vrijgesteld en of de belasting in de schapprijs is inbegrepen of bij de kassa wordt toegevoegd.

• Wat er op de kassabon moet staan. E-mail, afdruk of allebei, plus alles wat er verplicht op moet staan, zoals je KVK-nummer of retourbeleid.

• De uitzonderingen. Statiegeld, gewogen producten, personeelskorting, de vaste klant die aan het einde van de maand betaalt. Eén zin per uitzondering is genoeg. Een checkout die wel de normale verkoop afhandelt maar niet je uitzonderlijke gevallen, wordt binnen een week afgedankt. Dat maakt de uitzonderingen de meest waardevolle zinnen van de hele beschrijving.

Wat kan gewone taal niet?

Een beschrijving bepaalt het gedrag; het kan de onderliggende machinerie niet uit zichzelf correct maken. Voorraad die nauwkeurig blijft wanneer twee verkopen tegelijkertijd hetzelfde artikel raken, dagrapportages die aansluiten (overeenkomen met het geld dat daadwerkelijk is verplaatst), belasting die bij de duizendste verkoop op dezelfde manier wordt toegepast als bij de eerste, en kaartbetalingen die voldoen aan de PCI-regels (de beveiligingsstandaard van de betaalkaartindustrie) zijn geen dingen die een zin kan garanderen. Het platform waarop je beschrijving terechtkomt, biedt deze wel of niet.

Dit is waar doe-het-zelfpogingen vastlopen. Een AI-codegenerator genereert overtuigende checkout-schermen op basis van dezelfde zeven zinnen, en het resultaat ziet er goed uit totdat er echt geld en echte voorraad aan te pas komen. We hebben in kaart gebracht waar die grens ligt in vibe-coding van een point of sale en in waarom een toonaangevend coderingsmodel nog steeds geen werkende POS kan opleveren op zichzelf. Gewone taal is een volledige specificatie voor de onderdelen van een POS die je kunt zien. Iemand moet nog steeds de onderdelen hebben gebouwd die je niet kunt zien.

Hoe verfijn je de eerste versie?

Op dezelfde manier waarop je die nieuwe medewerker zou corrigeren: specifiek en één ding tegelijk. Voer een testverkoop uit zodra je een voorbeeld hebt: eerst je meest voorkomende bestelling, daarna je vreemdste. Als er iets niet klopt, pas het dan aan met een eenvoudige zin ("bij halve dozijnen moet worden gevraagd welke zes gebakjes") in plaats van de hele winkel opnieuw te beschrijven. Als het scherm zelf aanpassing nodig heeft, gebruik dan promptpatronen die geweldige POS-layouts opleveren; het beschrijven van de transactie in plaats van het scherm doet het meeste werk.

Op Final is die cyclus een chat: beschrijven, bekijken, corrigeren, uitrollen, waarbij elke wijziging wordt opgeslagen als een controlepunt dat je kunt terugdraaien. Het stappenplan vind je in hoe je je eerste flow bouwt, en als je liever in een AI-tool blijft die je al gebruikt, kun je je eigen AI verbinden via MCP (een standaardmanier om AI-tools te koppelen aan andere software) en bouwen op basis van hetzelfde live voorbeeld. Er is een uitgebreider verhaal over waarom prompts visuele builders hebben vervangen als je benieuwd bent hoe we hier zijn gekomen.

Kan gewone taal je dus echt van prompt tot checkout brengen?

Ja. Een beschrijving die de catalogus, de betaalmethoden, de belastingregels, de kassabon en de uitzonderingen omvat, is een volledige specificatie voor de voorkant van een winkel, en een op prompts gebaseerde builder kan deze dezelfde dag nog omzetten in een checkout. Wat geen enkele beschrijving kan bieden, is de onderliggende commerce-infrastructuur, dus richt je zinnen op een platform waar dat gedeelte al aanwezig is. De vuistregel: beschrijf je balie zoals je een nieuwe medewerker zou inwerken, en laat het platform alles afhandelen wat een nieuwe medewerker nooit ziet.

Als je wilt zien hoe een beschrijving verandert in een werkende kassa, is Aan de slag met Build de versie van vijf minuten.