Kan du bygge et POS med Lovable eller Replit? Det mangler der efter brugerfladen

Næsten. Du kan godt bygge et POS med Lovable eller Replit, så længe din definition af et POS stopper ved skærmen. Begge vil frembringe en betalingsgrænseflade, et produktgitter og en kurv på en eftermiddag, og det vil se bedre ud end masser af software, som forhandlere betaler rigtige penge for. Gabet opstår efter brugerfladen (UI), i de dele af et point of sale, du ikke kan se: Lagerstyring, rapportering, skat og betalinger, der skal være korrekte hver eneste gang.

One caveat up front: Lovable and Replit ship changes constantly, so treat the specifics below as accurate at publication and worth re-checking.

Hvad giver Lovable og Replit dig egentlig?

Mere end skeptikerne antager. Lovable genererer en full-stack web-app: En React-frontend forbundet til en hosted backend med en database, godkendelse (authentication) og filopbevaring samt betalingsintegrationer til online betaling. Replit går længere på serversiden: Dets agent bygger og hoster apps med en indbygget database, hosting og godkendelse, så backend-logikken kører uden at skulle stykke tredjepartstjenester sammen.

For en stor klasse af software (interne værktøjer, bookingsider, dashboards) er det reelt hele opgaven, hvilket er grunden til, at disse platforme vokser så hurtigt. Haken er, at et point of sale ikke tilhører den klasse, af samme grund som at en førende AI-model, der bygger en web-app i første forsøg, stadig går i stå ved et fungerende POS: Den svære del var aldrig grænsefladen.

Hvad mangler der efter brugerfladen?

Handelslaget (commerce layer). Et point of sale er et primært registreringssystem (den eneste sandhedskilde for dine penge og dit lager), som tilfældigvis har en app ovenpå. Ingen af platformene leverer grundlæggende handelskomponenter (commerce primitives), så den genererede kode skal opfinde dem fra bunden:

• Lagerstyring, der overlever samtidighed (concurrency) (to kasser, der sælger i samme øjeblik). At trække én fra en lagerkolonne fungerer i en demo, men slår fejl den første lørdag, hvor to kasser sælger den sidste enhed samtidigt.

• En ordres livscyklus. Delvise refusioner, byttehandler, annulleringer og rabatter er hver især tilstandsændringer, der skal opdatere lager, rapportering og betalingsregistreringen på én gang; overser du én, skrider dine tal.

• Rapportering, der stemmer (totaler, der matcher dine betalingsindbetalinger på øren). En rapport, der blot er "tæt på", er et bogføringsproblem, du opdager, når der skal laves regnskab.

• Skatte- og momslogik, der følger reelle regler for jurisdiktioner og lander korrekt på hver kvittering, refusion og rapport.

En AI-agent vil generere plausible versioner af alle fire. Plausibel er fælden: En ødelagt knap er synlig i det øjeblik, du trykker på den, mens en afstemningsfejl ligger usynlig hen, indtil din revisor finder den flere måneder senere.

Kan en genereret app tage imod rigtige betalinger?

Online, ja: Begge platforme forbinder fint nok til betalingsintegrationer til web-betaling. Fysisk betaling er en helt anden disciplin. Fysiske kortbetalinger kræver certificeret terminalhardware og PCI DSS-overholdelse (kortbranchens sikkerhedsregler for alt, der berører kortdata). Ingen genereret kodebase opfylder dette i sig selv; certificeringen ligger i betalingsudbyderens hardware og platform, ikke i din app. Tvister, delvise refusioner til det oprindelige kort og justeringer af drikkepenge kører alle gennem det samme certificerede lag.

Dette er muren, som enhver gør-det-selv-løsning til sidst rammer, uanset værktøjet. Vi fandt ud af det samme, da vi testede, hvad en AI-model kan og ikke kan bygge via MCP.

Hvad går først i stykker i produktion?

Den oplagte indvending: "Fint, jeg forbinder selv den genererede app til en hosted database og en betalingsintegration." Det kan du, og mange burde prøve det; det er den hurtigste måde at lære, hvor bunden er. Men forstå, hvad du har sagt ja til: Du er nu den eneste administrator af et lille finansielt system. Når netværket ryger midt i et salg, når kvitteringsprinteren mangler en driver, som browseren ikke har, eller når en refusion går igennem betalingsintegrationen, men aldrig registreres i dine rapporter, er der ingen leverandør at ringe til. Selve udviklingen var den billige del. Ejerskabet er den dyre del, og det starter den dag, du tager imod din første rigtige betaling.

Så kan du bygge et POS med Lovable eller Replit?

Du kan bygge frontenden af et: En rigtig grænseflade, reel logik, leveret hurtigt. Du kan ikke generere backenden af det, fordi lagerstyring under belastning, afstemning, skat og certificerede fysiske kortbetalinger ikke er kode, en agent kan opfinde; det er infrastruktur, der allerede skal eksistere. Det efterlader to ærlige veje: Genbyg den infrastruktur selv og ej den for evigt, eller generer din betaling oven på en handelsinfrastruktur, der allerede kører, hvilket er tilgangen bag Final, hvor en prompt eller dit eget AI-værktøj bygger dit POS på en live handels-backend.

Uanset hvad er der én tommelfingerregel, før du lader en AI bygge det: Hvis en fejl koster penge i stedet for pixels, bygger du infrastruktur, ikke en brugerflade (UI). Hvis du vil se, hvad der ligger under en betaling, når handelslaget følger med, kan du se, hvordan det ser ud i praksis her.