Kann man ein POS mit Lovable oder Replit bauen? Was nach der UI fehlt

Jein. Sie können ein POS mit Lovable oder Replit bauen, sofern Ihre Definition eines POS am Bildschirm aufhört. Beide Plattformen erstellen Ihnen an einem Nachmittag eine Checkout-Oberfläche, ein Produktgitter und einen Warenkorb – und das sieht oft besser aus als so manche Software, für die Händler viel Geld bezahlen. Die Lücke öffnet sich erst nach der Benutzeroberfläche, bei den unsichtbaren Teilen eines POS: Bestandsführung, Berichte, Steuern und Zahlungen, die jedes einzelne Mal absolut fehlerfrei sein müssen.

Ein Hinweis vorab: Lovable und Replit veröffentlichen ständig Updates. Betrachten Sie die folgenden Details daher als Momentaufnahme zum Zeitpunkt der Veröffentlichung, die Sie selbst noch einmal überprüfen sollten.

Was bieten Ihnen Lovable und Replit tatsächlich?

Mehr, als Skeptiker vermuten. Lovable generiert eine Full-Stack-Web-App: ein React-Frontend, das mit einem gehosteten Backend inklusive Datenbank, Authentifizierung und Dateispeicher verbunden ist, sowie Zahlungsintegrationen für den Online-Checkout. Replit geht serverseitig noch weiter: Der Agent baut und hostet Apps mit integrierter Datenbank, Hosting und Authentifizierung, sodass die Backend-Logik läuft, ohne dass Dienste von Drittanbietern zusammengeschustert werden müssen.

Für eine große Klasse von Software (interne Tools, Buchungsseiten, Dashboards) ist das tatsächlich schon die ganze Arbeit, weshalb diese Plattformen so schnell wachsen. Der Haken ist, dass ein POS nicht zu dieser Klasse gehört. Und zwar aus demselben Grund, aus dem ein hochmodernes KI-Modell, das eine Web-App im Handumdrehen erstellt, an einem funktionierenden POS scheitert: Der schwierige Teil war noch nie die Benutzeroberfläche.

Was fehlt nach der UI?

Die Commerce-Ebene. Ein POS ist ein führendes System (die einzige verlässliche Quelle für Ihr Geld und Ihren Bestand), das zufällig eine App als Oberfläche hat. Da keine der beiden Plattformen fertige Commerce-Bausteine mitliefert, muss der generierte Code diese von Grund auf neu erfinden:

• Bestandsführung bei Gleichzeitigkeit (zwei Kassen verkaufen im selben Moment): Das Verringern einer Bestandsspalte in der Datenbank funktioniert in einer Demo, scheitert aber am ersten Samstag, an dem zwei Kassenplätze gleichzeitig die letzte Einheit verkaufen.

• Ein Bestell-Lebenszyklus: Teilrückerstattungen, Umtausche, Stornierungen und Rabatte sind jeweils Statusänderungen, die den Bestand, das Berichtswesen und den Zahlungsbeleg gemeinsam aktualisieren müssen. Wird ein Schritt ausgelassen, weichen Ihre Zahlen voneinander ab.

• Berichte, die aufgehen (Summen, die bis auf den Cent mit Ihren Bankeinzahlungen übereinstimmen): Ein Bericht, der nur „ungefähr“ stimmt, ist ein Buchhaltungsfehler, den Sie spätestens bei der Steuererklärung bemerken.

• Eine Steuerlogik, die den echten regionalen Vorschriften folgt und auf jedem Beleg, jeder Rückerstattung und jedem Bericht korrekt ausgewiesen wird.

Ein KI-Agent wird plausible Versionen für alle vier Bereiche generieren. Plausibilität ist hier die Falle: Eine fehlerhafte Schaltfläche ist sofort sichtbar, wenn man darauf tippt, während ein Fehler bei der Finanzabstimmung unsichtbar bleibt, bis Ihr Steuerberater ihn Monate später findet.

Kann eine generierte App echte Zahlungen annehmen?

Online ja: Beide Plattformen binden Zahlungsschnittstellen gut genug für den Web-Checkout an. Im Laden vor Ort ist das jedoch eine ganz andere Liga. Zahlungen im Präsenzverkauf erfordern zertifizierte Terminal-Hardware und die Einhaltung von PCI DSS (den Sicherheitsregeln der Kreditkartenindustrie für alle Systeme, die mit Kartendaten in Berührung kommen). Kein generierter Code erfüllt dies von sich aus; die Zertifizierung liegt in der Hardware und der Plattform des Zahlungsanbieters, nicht in Ihrer App. Auch Reklamationen, Teilrückerstattungen auf die ursprüngliche Karte und Trinkgeldanpassungen laufen über diese zertifizierte Ebene.

Das ist die Grenze, an die jeder DIY-Ansatz irgendwann stößt, ganz gleich mit welchem Tool. Das haben wir auch beim Testen der Frage festgestellt, was ein KI-Modell über MCP bauen kann und was nicht.

Was geht im Live-Betrieb zuerst kaputt?

Der naheliegende Einwand: „Gut, dann verbinde ich die generierte App eben selbst mit einer gehosteten Datenbank und einer Zahlungsintegration.“ Das können Sie tun, und viele sollten es auch versuchen; es ist der schnellste Weg zu lernen, wo die Grenzen liegen. Aber machen Sie sich klar, worauf Sie sich einlassen: Sie sind ab sofort der einzige Betreuer eines kleinen Finanzsystems. Wenn das Netzwerk mitten im Verkauf ausfällt, wenn der Belegdrucker einen Treiber benötigt, den der Browser nicht unterstützt, oder wenn eine Rückerstattung zwar über die Zahlungsintegration läuft, aber nie in Ihren Berichten ankommt, gibt es keinen Support, den Sie anrufen können. Die Entwicklung war der günstige Teil. Der Betrieb ist der teure Teil, und er beginnt an dem Tag, an dem Sie die erste echte Zahlung annehmen.

Kann man also ein POS mit Lovable oder Replit bauen?

Sie können das Frontend bauen: eine echte Benutzeroberfläche mit echter Logik, schnell einsatzbereit. Das Backend können Sie nicht generieren, denn Bestandsführung unter Last, Finanzabstimmung, Steuern und zertifizierte Zahlungen im Präsenzverkauf sind kein Code, den ein Agent neu erfinden kann; sie sind Infrastruktur, die bereits vorhanden sein muss. Das lässt zwei ehrliche Wege offen: Sie bauen diese Infrastruktur selbst auf und betreuen sie für immer, oder Sie generieren Ihren Checkout auf einer bereits funktionierenden Commerce-Infrastruktur. Das ist der Ansatz von Final, bei dem ein Prompt oder Ihr eigenes KI-Tool das POS auf einem Live-Commerce-Backend aufbaut.

In jedem Fall gilt eine Faustregel, bevor Sie eine KI mit dem Bau beauftragen: Wenn ein Fehler Geld statt nur Pixel kostet, bauen Sie Infrastruktur, keine Benutzeroberfläche. Wenn Sie sehen möchten, was unter einem Checkout liegt, wenn die Commerce-Ebene bereits enthalten ist, sehen Sie hier, wie das in der Praxis aussieht.