Kan man bygga ett POS med Lovable eller Replit? Vad som saknas efter gränssnittet

Nja, typ. Du kan bygga ett POS med Lovable eller Replit, så länge din definition av ett POS stannar vid skärmen. Båda kommer att producera ett kassagränssnitt, ett produktraster och en varukorg på en eftermiddag, och det kommer att se bättre ut än mycket av den programvara som handlare betalar riktiga pengar för. Klyftan öppnar sig efter gränssnittet, i de delar av ett kassasystem som du inte kan se: lager, rapportering, skatter och betalningar som måste vara korrekta varje enskild gång.

Ett förbehåll på förhand: Lovable och Replit lanserar ständigt ändringar, så se detaljerna nedan som korrekta vid publiceringstillfället och värda att dubbelkolla.

Vad ger Lovable och Replit dig egentligen?

Mer än vad skeptiker tror. Lovable genererar en fullstack-webbapp: en React-frontend kopplad till en värdbaserad backend med en databas, autentisering och fillagring, plus betalningsintegrationer för onlineutcheckning. Replit går längre på serversidan: dess agent bygger och är värd för appar med en inbyggd databas, hosting och autentisering, så backend-logik körs utan att behöva sy ihop tredjepartstjänster.

För en stor klass av programvara (interna verktyg, bokningssidor, instrumentpaneler) är detta genuint hela jobbet, vilket är anledningen till att dessa plattformar växer så snabbt. Haken är att ett kassasystem inte tillhör den klassen, av samma anledning som en spetsmodell som skapar en webbapp på ett enda försök fortfarande kör fast på ett fungerande POS: den svåra delen var aldrig gränssnittet.

Vad saknas efter gränssnittet?

Handelslagret. Ett kassasystem är ett registersystem (den enda källan till sanning för dina pengar och ditt lager) som råkar ha en app ovanpå. Ingen av plattformarna levererar handelsprimitiver, så den genererade koden måste uppfinna dem från grunden:

• Lager som överlever samtidig belastning (två kassor som säljer i samma ögonblick). Att minska en lagersaldokolumn fungerar i en demo och kraschar första lördagen då två kassor säljer den sista enheten samtidigt.

• En livscykel för order. Delvis återbetalning, byten, makuleringar och rabatter är alla tillståndsändringar som måste uppdatera lager, rapportering och betalningsposten tillsammans; missa en och dina siffror glider isär.

• Rapportering som stämmer av (totalsummor som matchar dina insättningar på öret). En rapport som bara är "nästan" rätt är ett bokföringsproblem du kommer att upptäcka vid deklarationen.

• Skattelogik som följer verkliga jurisdiktionsregler och landar korrekt på varje kvitto, återbetalning och rapport.

En AI-agent kommer att generera trovärdiga versioner av alla fyra. Trovärdig är fällan: en trasig knapp syns i samma sekund som du trycker på den, medan en avstämningsbugg ligger osynlig tills din revisor hittar den månader senare.

Kan en genererad app ta emot riktiga betalningar?

Online, ja: båda plattformarna ansluter till betalningsintegrationer tillräckligt bra för webbutcheckning. Personligen är det en helt annan sport. Kortbetalningar på plats kräver certifierad terminalhårdvara och PCI DSS-efterlevnad (kortbranschens säkerhetsregler för allt som rör kortdata). Ingen genererad kodbas uppfyller det på egen hand; certifieringen bor i betalningsleverantörens hårdvara och plattform, inte i din app. Tvister, delåterbetalningar till det ursprungliga kortet och dricksjusteringar körs alla genom samma certifierade lager.

Detta är väggen som alla gör-det-själv-vägar till slut träffar, oavsett verktyg. Vi upptäckte samma sak när vi testade vad en AI-modell kan och inte kan bygga över MCP.

Vad går sönder först i produktion?

Den uppenbara invändningen: "Okej, jag kopplar den genererade appen till en värdbaserad databas och en betalningsintegration själv." Det kan du göra, och många borde prova det; det är det snabbaste sättet att lära sig var ribban ligger. Men förstå vad du har gett dig in på: du är nu ensam underhållare av ett litet finansiellt system. När nätverket går ner mitt i ett köp, när kvittoskrivaren behöver en drivrutin som webbläsaren saknar, när en återbetalning går igenom betalningsintegrationen men aldrig syns i dina rapporter, finns det ingen leverantör att ringa. Att bygga var den billiga delen. Ägandet är den dyra delen, och det börjar den dag du tar emot din första riktiga betalning.

Så, kan du bygga ett POS med Lovable eller Replit?

Du kan bygga framsidan av ett: ett riktigt gränssnitt, verklig logik, levererat snabbt. Du kan inte generera baksidan av det, eftersom lager under belastning, avstämning, skatt och certifierade kortbetalningar på plats inte är kod som en agent kan uppfinna; de är infrastruktur som redan måste finnas. Det lämnar två ärliga vägar: bygg om den infrastrukturen själv och äg den för alltid, eller generera din kassa ovanpå en handelsinfrastruktur som redan körs, vilket är metoden bakom Final, där en prompt eller ditt eget AI-verktyg bygger kassasystemet på en live-handelsbackend.

Oavsett vilket, en tumregel innan du låter någon AI bygga det: om en bugg kostar pengar istället för pixlar, bygger du infrastruktur, inte gränssnitt. Om du vill se vad som sitter under en kassa när handelslagret ingår, här är hur det ser ut i praktiken.