Si può costruire un POS con Lovable o Replit? Cosa manca oltre l'interfaccia utente

In un certo senso sì. Puoi costruire un POS con Lovable o Replit, a patto che la tua definizione di POS si fermi allo schermo. Entrambi produrranno un'interfaccia di checkout, una griglia di prodotti e un carrello in un pomeriggio, e avrà un aspetto migliore di molti software per cui i commercianti pagano denaro reale. Il divario si apre dopo l'interfaccia utente, nelle parti di un punto vendita che non si vedono: inventario, reportistica, tasse e pagamenti che devono essere corretti ogni singola volta.

Una precisazione iniziale: Lovable e Replit rilasciano modifiche costantemente, quindi considera i dettagli riportati di seguito come accurati al momento della pubblicazione e meritevoli di una nuova verifica.

Cosa ti danno effettivamente Lovable e Replit?

Più di quanto gli scettici suppongano. Lovable genera un'app web full-stack: un frontend React collegato a un backend ospitato con un database, autenticazione e archiviazione di file, oltre a integrazioni di pagamento per il checkout online. Replit va oltre sul lato server: il suo agente crea e ospita app con un database integrato, hosting e autenticazione, in modo che la logica di backend venga eseguita senza dover unire servizi di terze parti.

Forse per un'ampia classe di software (strumenti interni, pagine di prenotazione, dashboard) questo rappresenta davvero l'intero lavoro, ed è per questo che queste piattaforme stanno crescendo così rapidamente. L'inghippo è che un punto vendita non appartiene a quella classe, per lo stesso motivo per cui un modello di frontiera che crea un'app web in un colpo solo si blocca comunque su un POS funzionante: la parte difficile non è mai stata l'interfaccia.

Cosa manca dopo l'interfaccia utente?

Il livello commerciale. Un punto vendita è un sistema di record (l'unica fonte di verità per il tuo denaro e le tue scorte) che ha un'app al di sopra. Nessuna delle due piattaforme offre primitive commerciali, quindi il codice generato deve inventarle da zero:

• Inventario che sopravvive alla concorrenza (due casse che vendono nello stesso momento). Decrementare una colonna delle scorte funziona in una demo e fallisce il primo sabato in cui due postazioni vendono l'ultima unità contemporaneamente.

• Un ciclo di vita dell'ordine. Rimborsi parziali, cambi, storni e sconti sono tutti cambiamenti di stato che devono aggiornare contemporaneamente l'inventario, la reportistica e il record di pagamento; se ne salti uno, i tuoi numeri divergeranno.

• Reportistica che si riconcilia (totali che corrispondono al centesimo ai tuoi depositi di pagamento). Un report che è solo "vicino" è un problema contabile che scoprirai al momento delle tasse.

• Logica fiscale che segue le regole reali della giurisdizione e si applica correttamente a ogni ricevuta, rimborso e report.

Un agente IA genererà versioni plausibili di tutti e quattro gli elementi. Plausibile è la trappola: un pulsante rotto è visibile nel momento in cui lo tocchi, mentre un bug di riconciliazione rimane invisibile finché il tuo commercialista non lo trova mesi dopo.

Un'app generata può accettare pagamenti reali?

Online sì: entrambe le piattaforme si collegano alle integrazioni di pagamento abbastanza bene per il checkout web. Di persona è uno sport diverso. I pagamenti con carta presente richiedono un hardware terminale certificato e la conformità PCI DSS (le regole di sicurezza del settore delle carte per qualsiasi cosa tocchi i dati delle carte). Nessuna base di codice generata soddisfa questo requisito da sola; la certificazione risiede nell'hardware e nella piattaforma del fornitore di servizi di pagamento, non nella tua app. Controversie, rimborsi parziali sulla carta originale e modifiche delle mance passano tutti attraverso lo stesso livello certificato.

Questo è il muro contro cui si scontra alla fine ogni percorso fai-da-te, qualunque sia lo strumento. Abbiamo riscontrato la stessa cosa testando cosa un modello di IA può e non può costruire tramite MCP.

Cosa si rompe per primo in produzione?

L'obiezione ovvia: "Va bene, collegherò io stesso l'app generata a un database ospitato e a un'integrazione di pagamenti". Puoi farlo, e molti dovrebbero provarci; è il modo più rapido per imparare dove si trova il limite. Ma comprendi cosa hai accettato di fare: ora sei l'unico manutentore di un piccolo sistema finanziario. Quando la rete cade a metà vendita, quando la stampante di ricevute ha bisogno di un driver che il browser non ha, quando un rimborso va a buon fine nell'integrazione dei pagamenti ma non tocca mai i tuoi report, non c'è nessun fornitore da chiamare. La costruzione è stata la parte economica. La proprietà è la parte costosa, e inizia il giorno in cui accetti il tuo primo pagamento reale.

Quindi, si può costruire un POS con Lovable o Replit?

Puoi costruire la parte frontale: un'interfaccia reale, una logica reale, rilasciata rapidamente. Non puoi generare la parte posteriore, perché l'inventario sotto carico, la riconciliazione, le tasse e i pagamenti con carta presente certificati non sono codice che un agente può inventare; sono infrastrutture che devono già esistere. Questo lascia due strade oneste: ricostruire quell'infrastruttura da soli e possederla per sempre, oppure generare il proprio checkout sopra un'infrastruttura commerciale già funzionante, che è l'approccio alla base di Final, dove un prompt o il tuo strumento di IA costruisce il POS su un backend commerciale attivo.

In ogni caso, una regola pratica prima di lasciare che sia l'IA a costruirlo: if a bug costs money instead of pixels, you're building infrastructure, not UI. Se vuoi vedere cosa c'è sotto un checkout quando il livello commerciale è incluso, ecco come si presenta in pratica.