Lze postavit POS pomocí Lovable nebo Replit? Co chybí po vytvoření uživatelského rozhraní

Svým způsobem ano. POS pomocí Lovable nebo Replit postavit můžete, pokud vaše definice POS končí u obrazovky. Oba nástroje vytvoří pokladní rozhraní, mřížku produktů a košík za jedno odpoledne a bude to vypadat lépe než spousta softwaru, za který obchodníci platí skutečné peníze. Mezera se však otevírá hned za uživatelským rozhraním, v částech pokladního místa, které nevidíte: zásoby, reportování, daně a platby, které musí být správné za každých okolností.

Jedno upozornění na úvod: Lovable a Replit vydávají změny neustále, takže níže uvedené podrobnosti berte jako přesné v době publikace a hodné opětovného ověření.

Co vám Lovable a Replit vlastně poskytnou?

Více, než skeptici předpokládají. Lovable vygeneruje full-stack webovou aplikaci: React frontend propojený s hostovaným backendem s databází, ověřováním a úložištěm souborů, plus platební integrace pro online odbavení. Replit jde na straně serveru ještě dál: jeho agent vytváří a hostuje aplikace s vestavěnou databází, hostingem a ověřováním, takže logika backendu běží bez nutnosti sešívání služeb třetích stran dohromady.

Pro velkou třídu softwaru (interní nástroje, rezervační stránky, panely) to skutečně představuje celou práci, což je důvod, proč tyto platformy rostou tak rychle. Háček je v tom, že pokladní systém do této třídy nepatří, a to ze stejného důvodu, jako pokročilý model, který na jeden pokus vytvoří webovou aplikaci, stále selhává na funkčním POS: tou těžkou částí nikdy nebylo rozhraní.

Co chybí po vytvoření uživatelského rozhraní?

Obchodní vrstva. Pokladní systém je systém záznamu (jediný zdroj pravdy pro vaše peníze a zásoby), který má shodou okolností navrchu aplikaci. Ani jedna platforma nedodává obchodní základy, takže vygenerovaný kód je musí vymýšlet od nuly:

• Správa zásob při souběžném přístupu (dvě pokladny prodávající ve stejný okamžik). Odečítání sloupce zásob funguje v demoverzi a selže první sobotu, kdy dvě pokladní místa prodají poslední kus současně.

• Životní cyklus objednávky. Částečné refundace, výměny, stornování a slevy jsou změny stavu, které musí společně aktualizovat zásoby, reportování a záznam o platbě; vynechejte jednu a vaše čísla se rozejdou.

• Reportování, které se shoduje (celkové částky odpovídají vašim platebním vkladům do posledního haléře). Report, který je pouze „přibližný“, je účetní problém, který objevíte při podávání daňového přiznání.

• Daňová logika, která se řídí skutečnými pravidly jurisdikce a správně se promítá do každé účtenky, refundace a reportu.

AI agent vygeneruje věrohodné verze všech čtyř. Věrohodnost je však past: nefunkční tlačítko je viditelné v okamžiku, kdy na něj klepnete, zatímco chyba v odsouhlasení plateb zůstává neviditelná, dokud ji váš účetní o několik měsíců později nenajde.

Může vygenerovaná aplikace přijímat skutečné platby?

Online ano: obě platformy se dokážou připojit k platebním integracím dostatečně dobře pro webové odbavení. Osobní prodej je však jiná disciplína. Platby za přítomnosti karty vyžadují certifikovaný terminálový hardware a soulad s PCI DSS (bezpečnostní pravidla karetního průmyslu pro cokoli, co přichází do styku s údaji o kartách). Žádný vygenerovaný kód to sám o sobě nesplňuje; certifikace žije v hardwaru a platformě poskytovatele plateb, nikoli ve vaší aplikaci. Spory, částečné refundace na původní kartu a úpravy spropitného běží přes stejnou certifikovanou vrstvu.

Toto je zeď, na kterou nakonec narazí každá cesta svépomocí, bez ohledu na nástroj. K témuž jsme dospěli při testování toho, co model AI dokáže a nedokáže postavit přes MCP.

Co se v produkci rozbije jako první?

Zřejmá námitka: „Dobře, vygenerovanou aplikaci si k hostované databázi a platební integraci připojím sám.“ Můžete a mnozí by to měli zkusit; je to nejrychlejší způsob, jak zjistit, kde je dno. Uvědomte si však, k čemu jste se upsali: nyní jste jediným správcem malého finančního systému. Když uprostřed prodeje vypadne síť, když tiskárna účtenek potřebuje ovladač, který prohlížeč nemá, když refundace projde platební integrací, ale nikdy se nedotkne vašich reportů, nemáte žádného dodavatele, kterému byste mohli zavolat. Vývoj byl tou levnou částí. Vlastnictví je tou drahou částí a začíná dnem, kdy přijmete první skutečnou platbu.

Lze tedy postavit POS pomocí Lovable nebo Replit?

Můžete postavit jeho přední část: skutečné rozhraní, skutečnou logiku, dodané rychle. Nemůžete však vygenerovat jeho zadní část, protože zásoby pod zatížením, odsouhlasení plateb, daně a certifikované platby za přítomnosti karty nejsou kódem, který by agent mohl vymyslet; jsou to infrastruktury, které již musí existovat. To vám dává dvě poctivé cesty: vybudovat tuto infrastrukturu sami a vlastnit ji navždy, nebo vygenerovat pokladnu na obchodní infrastruktuře, která již běží, což je přístup stojící za systémem Final, kde prompt nebo váš vlastní AI nástroj staví POS na živém obchodním backendu.

Ať tak či onak, jedno praktické pravidlo, než necháte jakoukoli AI stavět: pokud chyba stojí peníze namísto pixelů, stavíte infrastrukturu, nikoli uživatelské rozhraní. Pokud chcete vidět, co se nachází pod pokladnou, když je obchodní vrstva již zahrnuta, zde je ukázka, jak to vypadá v praxi.