Kan du bygge en POS med Lovable eller Replit? Hva som mangler bak grensesnittet

Tja. Du kan bygge en POS med Lovable eller Replit, så lenge definisjonen din av en POS stopper ved skjermen. Begge vil produsere et betalingsgrensesnitt, et produkt-rutenett og en handlekurv på en ettermiddag, og det vil se bedre ut enn mye av programvaren forhandlere betaler i dyre dommer for. Gapet oppstår bak brukergrensesnittet, i de delene av en POS du ikke kan se: lagerbeholdning, rapportering, skatter og betalinger som må være korrekte hver eneste gang.

Én forutsetning innledningsvis: Lovable og Replit ruller ut endringer hele tiden, så se på detaljene nedenfor som et øyeblikksbilde som er nøyaktig ved publisering og verdt å sjekke på nytt.

Hva gir Lovable og Replit deg egentlig?

Mer enn skeptikerne tror. Lovable genererer en full-stack webapp: en React-frontend koblet til en hostet backend med database, autentisering og fillagring, pluss betalingsintegrasjoner for nettbetaling. Replit går lenger på serversiden: agenten deres bygger og hoster apper med innebygd database, hosting og autentisering, slik at backend-logikken kjører uten at du må sy sammen tredjepartstjenester.

For en stor klasse programvare (interne verktøy, bookingsider, dashbord) er dette faktisk hele jobben, og det er derfor disse plattformene vokser så raskt. Haken er at en POS ikke tilhører den klassen, av samme grunn som at en ledende AI-modell som spytter ut en webapp på første forsøk, fortsatt sliter med en fungerende POS: den vanskelige delen var aldri grensesnittet.

Hva mangler bak brukergrensesnittet?

Handelslaget. En POS er et registersystem (den eneste kilden til sannhet for pengene og varene dine) som tilfeldigvis har en app på toppen. Ingen av plattformene leverer ferdige handelskomponenter, så den genererte koden må finne dem opp fra bunnen av:

• Lagerbeholdning som overlever samtidig belastning (to kasser som selger i samme sekund). Å trekke fra en lagerkolonne fungerer i en demo, men feiler den første lørdagen to stasjoner selger den siste enheten samtidig.

• En livssyklus for bestillinger. Delvise refusjoner, bytter, annulleringer og rabatter er alle tilstandsendringer som må oppdatere lagerbeholdning, rapportering og betalingshistorikk samtidig; bommer du på én, vil tallene dine sprike.

• Rapportering som stemmer (totalsummer som samsvarer med bankinnskuddene dine på øret). En rapport som bare er "nesten" riktig, er et bokføringsproblem du oppdager først ved skatteoppgjøret.

• Skattelogikk som følger reelle regler for ulike jurisdiksjoner og lander riktig på hver kvittering, refusjon og rapport.

En AI-agent vil generere troverdige versjoner av alle fire. Det troverdige er fellen: en ødelagt knapp er synlig i det sekundet du trykker på den, mens en avstemmingsfeil ligger usynlig til regnskapsføreren din oppdager den flere måneder senere.

Kan en generert app ta imot ekte betalinger?

På nett, ja: begge plattformene kobler seg til betalingsintegrasjoner godt nok for nettbetaling. Fysisk betaling er en helt annen idrett. Fysiske kortbetalinger krever sertifisert terminalmaskinvare og PCI DSS-samsvar (kortbransjens sikkerhetsregler for alt som berører kortdata). Ingen generert kodebase tilfredsstiller dette på egen hånd; sertifiseringen ligger i betalingsleverandørens maskinvare og plattform, ikke i appen din. Tvister, delvise refusjoner til det opprinnelige kortet og tipsjusteringer kjører alle gjennom det samme sertifiserte laget.

Dette er veggen alle gjør-det-selv-løsninger treffer til slutt, uansett verktøy. Vi oppdaget det samme da vi testet hva en AI-modell kan og ikke kan bygge over MCP.

Hva ryker først i produksjon?

Den åpenbare innvendingen: "Greit, jeg skal koble den genererte appen til en hostet database og en betalingsintegrasjon selv." Det kan du, og mange bør prøve det; det er den raskeste måten å lære hvor grensen går på. Men forstå hva du har sagt ja til: du er nå den eneste som vedlikeholder et lite finansielt system. Når nettverket faller ut midt i et salg, når kvitteringsskriveren trenger en driver nettleseren ikke har, eller når en refusjon går gjennom betalingsintegrasjonen, men aldri registreres i rapportene dine, finnes det ingen leverandør du kan ringe. Å bygge det var den billige delen. Eierskapet er den dyre delen, og det starter den dagen du tar imot din første ekte betaling.

Så, kan du bygge en POS med Lovable eller Replit?

You kan bygge forsiden av en: et ekte grensesnitt, ekte logikk, levert raskt. Du kan ikke generere baksiden av en, fordi lagerbeholdning under belastning, avstemming, skatt og sertifiserte fysiske betalinger ikke er kode en agent kan finne opp; det er infrastruktur som allerede må være på plass. Det etterlater to ærlige veier: bygg den infrastrukturen selv og vedlikehold den til evig tid, eller generer betalingsgrensesnittet ditt på toppen av en handelsinfrastruktur som allerede kjører, som er tilnærmingen bak Final, der en prompt eller ditt eget AI-verktøy bygger din POS på en live handels-backend.

Uansett, husk én tommelfingerregel før du lar en AI bygge det: hvis en feil koster penger i stedet for piksler, bygger du infrastruktur, ikke et brukergrensesnitt. Hvis du vil se hva som ligger under kassen når handelslaget følger med, kan du se hvordan det ser ut i praksis her.