Kan du byggje ein POS med Lovable eller Replit? Kva som manglar etter brukargrensesnittet

Noko i den duren. Du kan byggje ein POS med Lovable eller Replit, så lenge definisjonen din av ein POS stoppar ved skjermen. Begge vil produsere eit betalingsgrensesnitt, eit produktgitter og ei handlekorg i løpet av ein ettermiddag, og det vil sjå betre ut enn mykje av programvara som forhandlarar betalar ekte pengar for. Gapet opnar seg etter brukargrensesnittet, i dei delane av ein POS du ikkje kan sjå: lagerhald, rapportering, skattar og betalingar som må vere heilt korrekte kvar einaste gong.

Eit atterhald med det same: Lovable og Replit rullar ut endringar heile tida, så du bør sjå på detaljane nedanfor som nøyaktige ved publisering, men verdt å sjekke på nytt.

Kva gir Lovable og Replit deg eigentleg?

Meir enn skeptikarar trur. Lovable genererer ein full-stack webapp: ein React-frontend kopla til ein hosta backend med ein database, autentisering og fillagring, i tillegg til betalingsintegrasjonar for nettbetaling. Replit går lenger på serversida: agenten deira byggjer og hostar appar med innebygd database, hosting og autentisering, slik at backend-logikken køyrer utan at ein må sy saman tredjepartstenester.

For ein stor klasse programvare (interne verktøy, bookingsider, dashbord) er dette faktisk heile jobben, noko som er grunnen til at desse plattformene veks så fort. Haken er at ein POS ikkje høyrer til denne klassen, av same grunn som at ein banebrytande modell som lagar ein webapp på første forsøk, framleis stoppar opp på ein fungerande POS: den vanskelege delen var aldri grensesnittet.

Kva manglar etter brukargrensesnittet?

Handelslaget. Ein POS er eit registersystem (den einaste kjelda til sanning for pengane og lageret ditt) som tilfeldigvis har ein app på toppen. Ingen av plattformene leverer grunnleggjande handelsfunksjonar, så den genererte koden må finne dei opp frå botnen av:

• Lagerhald som toler samtidigheit (to kasser som sel i same sekund). Å redusere ein lagerkolonne fungerer i ein demo, men feilar den første laurdagen to kasser sel den siste eininga samtidig.

• Ein livssyklus for ordrar. Delvise refusjonar, byte, annulleringar og rabattar er alle tilstandsendringar som må oppdatere lagerhald, rapportering og betalingshistorikk samtidig; viss du misser éin av dei, vil tala dine avvike.

• Rapportering som stemmer (totalsummar som samsvarar med betalingsinnskota dine på øret). Ein rapport som berre er «nesten» rett, er eit bokføringsproblem du vil oppdage ved skattetid.

• Skattelogikk som følgjer reelle jurisdiksjonsreglar og landar rett på kvar kvittering, refusjon og rapport.

Ein AI-agent vil generere truverdige versjonar av alle fire. Truverdig er fella: Ein øydelagd knapp er synleg med det same du trykkjer på han, medan ein avstemmingsfeil ligg usynleg til revisoren din finn han fleire månader seinare.

Kan ein generert app ta imot ekte betalingar?

På nett, ja: Begge plattformene koplar seg godt nok til betalingsintegrasjonar for nettbetaling. Fysisk betaling er ein heilt annan sport. Betaling med fysiske kort krev sertifisert terminalmaskinvare og PCI DSS-samsvar (kortbransjen sine tryggleiksreglar for alt som rører ved kortdata). Ingen generert kodebase tilfredsstiller dette på eiga hand; sertifiseringa ligg i betalingsleverandøren si maskinvare og plattform, ikkje i appen din. Tvistar, delvise refusjonar til det opphavlege kortet og tipsjusteringar går alle gjennom det same sertifiserte laget.

Dette er veggen alle gjer-det-sjølv-løysingar treff til slutt, uansett verktøy. Vi fann det same då vi testa kva ein AI-modell kan og ikkje kan byggje over MCP.

Kva går først i stykke i produksjon?

Den openberre innvendinga: «Greitt, eg skal kople den genererte appen til ein hosta database og ein betalingsintegrasjon sjølv.» Det kan du, og mange bør prøve det; det er den raskaste måten å lære kvar botnen ligg på. Men ver klar over kva du har sagt ja til: Du er no den einaste vedlikehaldaren av eit lite finansielt system. Når nettverket fell ut midt i eit sal, når kvitteringsskrivaren treng ein drivar nettlesaren ikkje har, eller når ein refusjon går gjennom betalingsintegrasjonen men aldri dukkar opp i rapportane dine, finst det ingen leverandør å ringje. Sjølve bygginga var den billige delen. Eigarskap er den dyre delen, og det startar den dagen du tek imot di første ekte betaling.

Så, kan du byggje ein POS med Lovable eller Replit?

Du kan byggje framsida av ein: eit ekte grensesnitt, ekte logikk, levert raskt. Du kan ikkje generere baksida av ein, fordi lagerhald under belastning, avstemming, skatt og sertifiserte fysiske kortbetalingar ikkje er kode ein agent kan finne opp; det er infrastruktur som allereie må vere på plass. Det lèt etter seg to ærlige vegar: Gjenoppbygg den infrastrukturen sjølv og eig han til evig tid, eller generer betalingsløysinga din på toppen av ein handelsinfrastruktur som allereie køyrer, noko som er tilnærminga bak Final, der ein ledetekst eller ditt eige AI-verktøy byggjer ein POS på ein levande handels-backend.

Uansett kva du vel, er det éi tommelfingerregel før du lèt ein AI byggje det: viss ein feil kostar pengar i staden for pikslar, byggjer du infrastruktur, ikkje brukargrensesnitt. Viss du vil sjå kva som ligg under ei betalingsløysing når handelslaget er inkludert, kan du sjå korleis det ser ut i praksis her.