WooCommerce o e-commerce su misura: quando conviene Laravel

A decidere la piattaforma non è l’elenco di funzioni del primo giorno — magazzino, listini B2B e multilingua li costruiamo su entrambe. Decide chi stabilisce la Sua prossima modifica, e quanto costa.

Una domanda sulla tecnologia a cui non risponde un elenco di funzioni

La conversazione comincia quasi sempre allo stesso modo: il cliente ha circa settecento prodotti, tre livelli di prezzo per i rivenditori, ognuno dei quali nel proprio profilo vede soltanto il proprio prezzo, e una contabilità Visma Horizon in cui la giacenza è la verità mentre il negozio si limita a rispecchiarla. La domanda che pone suona così: WooCommerce o e-commerce su misura in Laravel? La risposta che si aspetta è un elenco a due colonne in cui da una parte qualcosa c’è e dall’altra manca — un elenco che noi non abbiamo e che non ha nessuno di quelli che costruiscono davvero entrambe le piattaforme.

Modulo magazzino con sincronizzazione delle giacenze in tempo reale, listini B2B, sistema di sconti, supporto multilingua e migrazione dei contenuti li costruiamo su entrambe le piattaforme, e nel nostro listino il prezzo non dipende dalla piattaforma: la versione Basic di un e-commerce costa 4.500 € e la versione Pro 9.500 €, sia su WooCommerce sia su Laravel. Sono esattamente queste cinque righe a separare Basic da Pro, non quello che sta sotto; il pannello di amministrazione nel listino è indicato già nella versione Basic, mentre il funzionamento multivaluta non è in nessuna delle due versioni e si concorda a parte, di nuovo su una qualsiasi delle due piattaforme.

Da qui discende una cosa pratica: la piattaforma che Le vendono con un elenco di funzioni del primo giorno Le viene venduta per qualcosa che si ottiene in entrambi i modi, e un confronto che parte da un elenco simile è finito prima di cominciare. La domanda interessante comincia un passo più in là: chi decide che cosa il Suo negozio potrà fare l’anno prossimo, e quanto a lungo quella decisione resta in coda dietro a qualcun altro.

Nel primo anno entrambe le piattaforme fanno quello per cui ha pagato, perché in entrambi i casi qualcuno l’ha appena costruito; nel secondo anno il processo cambia — arrivano la vendita all’ingrosso, un secondo magazzino, l’obbligo di emettere fatture leggibili da una macchina o semplicemente un altro ordine di sconti —, e da quel momento le due strade costano in modo diverso. Su un’estensione di un altro produttore ogni modifica successiva è come una ristrutturazione in un locale in affitto: le regole del Suo processo abitano nella finestra delle impostazioni di qualcun altro e si spostano secondo il calendario di rilascio di qualcun altro. Sul codice proprio la stessa cosa è lavoro, che nel listino ha una tariffa, e l’unica cosa da concordare è la sua priorità rispetto al resto dell’elenco.

Che cosa fa bene WooCommerce

WooCommerce lo installiamo noi stessi nei negozi dei clienti ogni volta che il processo ci sta dentro, ed è il sistema di e-commerce più diffuso nelle rilevazioni di W3Techs: il 6 agosto 2026 girava sull’8,2% di tutti i siti web e rappresentava il 48,5% di tutti i sistemi di e-commerce in quelle rilevazioni. Più importante del numero è la base su cui è calcolato — una quota dei sistemi rilevati, non dei negozi del mondo e men che meno del fatturato dell’e-commerce —, e dietro c’è WordPress con il 41,2% di tutti i siti.

Lo stesso giorno la directory dei plugin di WordPress.org mostrava WooCommerce alla versione 11.0.0, aggiornata il 4 agosto, con la stima «7+ million active installations», e a leggerla con prudenza invita il produttore stesso: nel core scaricato da WordPress.org la rilevazione d’uso è disattivata per impostazione predefinita, quindi nessuno — Automattic compresa — sa quanti negozi vendano davvero, e quel numero è il limite superiore delle installazioni, non il numero dei commercianti.

La pagina dei prezzi del produttore descrive WooCommerce come una piattaforma open source senza canone di piattaforma e con lo 0% di quota sui ricavi: non paga per il fatto di vendere e non paga per il fatto che il fatturato cresce. Catalogo, elenco degli ordini e impostazioni degli sconti hanno per di più lo stesso aspetto del resto dell’amministrazione di WordPress, che il Suo team probabilmente sa già usare senza corsi.

L’argomento più forte a favore di WooCommerce nei confronti tra concorrenti sparisce quasi sempre, ed è la patch automatica: il 2 marzo 2026 è stata resa pubblica una vulnerabilità della Store API che riguardava le versioni dalla 5.4 alla 10.5.2 e permetteva, con una richiesta falsificata, di creare un account amministratore; a trovare l’errore è stato qualcun altro, non i proprietari dei negozi; la correzione è stata riportata su 52 versioni interessate; e lo stesso giorno, dalle ore 14:00 UTC, ha cominciato a diffondersi da sola nei negozi che hanno gli aggiornamenti automatici attivi, senza fattura. Quell’impostazione non è però scontata, ed è esattamente ciò che in un contratto di manutenzione qualcuno configura e sorveglia; come vengono violati i siti WordPress e che cosa fare se è già successo lo abbiamo descritto nel nostro articolo su un sito WordPress hackerato.

La raccomandazione quindi non è cambiata ed è scritta anche sulla pagina del nostro servizio: per un e-commerce molto piccolo con processi standard, WooCommerce. A cento prodotti con un prezzo solo, un magazzino solo e un solo metodo di pagamento una piattaforma su misura non darà nulla per cui valga la pena pagare la differenza, e vendere l’opzione più cara quando quella più economica fa la stessa cosa significa un cliente scontento in più e nessun passaparola.

WooCommerce va bene per i pagamenti e le spedizioni in Lettonia?

Va bene. Spedizioni e pagamenti in Lettonia non sono il punto in cui un e-commerce pronto si ferma, e gli avvertimenti contrari sono di solito senza fondamento: Omniva pubblica moduli pronti per sei piattaforme — WooCommerce, Shopify, PrestaShop, OpenCart, Magento e Mozello — e accanto a essi l’interfaccia documentata OMX, per cui passano i dati delle spedizioni, le etichette, gli eventi di tracciamento e gli elenchi dei punti di ritiro automatici in tutti e tre i paesi baltici, ma il presupposto è un contratto aziendale, non un programmatore. DPD Baltics mantiene da sé il proprio plugin per WooCommerce nella directory di WordPress.org — versione 1.2.91, più di 2.000 installazioni attive — e copre punti di ritiro, corriere, etichette, manifesti e contrassegno; lì si vedono anche la sua valutazione pubblica, 2,7 su 5, e le recensioni che lamentano conflitti con altri plugin di spedizione.

MakeCommerce, dietro cui c’è Maksekeskus AS, con un solo contratto dà i link bancari di Swedbank, SEB, Citadele e Luminor, le carte, Apple Pay e Google Pay, e lì accanto le spedizioni Omniva, DPD, Venipak e Unisend; il suo plugin per WooCommerce ha più di 3.000 installazioni attive e l’ultimo aggiornamento risale a giugno 2026. Klix by Citadele, mantenuto dalla banca stessa, pubblica plugin ufficiali per sei piattaforme, WooCommerce dalla versione 3.5 compresa, per cui sostenere che in Lettonia un negozio pronto non sia in grado di incassare sarebbe semplicemente falso.

L’altra faccia della stessa cosa è che questi fornitori non sono proprietà dei plugin: MakeCommerce, Omniva e DPD pubblicano interfacce, non soltanto moduli, e nel nostro listino il collegamento dei pagamenti — MakeCommerce e Stripe — rientra già nella versione Basic da 4.500 €, indipendentemente da quale piattaforma stia sotto. Le integrazioni con Horizon, Jumis, Latvijas Pasts, Omniva e DPD sono una riga del servizio e-commerce, non un supplemento per Laravel, e con le API di spedizione di Omniva, Latvijas Pasts, DPD e Venipak lavoriamo regolarmente, per cui lo strato lettone di spedizioni e pagamenti non è un argomento né a favore né contro nessuna delle tre strade.

Dove in Lettonia il lavoro c’è davvero

A complicare il retrobottega è che Visma Horizon, Jumis e Directo pubblicano ciascuno la propria interfaccia REST — la documentazione di Directo descrive l’autorizzazione con l’intestazione X-Directo-Key e l’accesso ad articoli, ordini, clienti, fatture, giacenze e formule di prezzo —, ma un’interfaccia pubblicata non è ancora un’integrazione: qualcuno deve far combaciare quello che il negozio chiama prodotto con quello che la contabilità chiama voce di nomenclatura, e decidere quale dei due sistemi custodisca la verità sulla giacenza nel secondo in cui l’acquirente preme il pulsante. Due posti in cui vive la giacenza sono come due orologi su una nave: finché non li si sincronizza nessuno sa che ora è, e questo lavoro è individuale su qualsiasi piattaforma — con Horizon e Jumis lo facciamo regolarmente.

Sopra tutto questo c’è un fatto normativo datato con dentro una trappola: la fattura elettronica strutturata è obbligatoria verso gli enti pubblici dal 1° gennaio 2025, mentre nelle transazioni tra imprese lo diventerà il 1° gennaio 2028 — secondo le regole della legge lettone sulla contabilità e nel formato LVS EN 16931-1:2017. La trappola è la data: inizialmente era previsto il 2026, per cui gli articoli di stampa del 2024 citano ancora il termine sbagliato, e va verificata sulla pagina del Ministero delle Finanze dedicata alla fattura elettronica strutturata, non nelle notizie, perché per un negozio che vende alle imprese la strada della fattura leggibile da una macchina qualcuno dovrà costruirla su qualsiasi piattaforma, indipendentemente da quale anno si rivelerà quello giusto.

WooCommerce o e-commerce su misura: quale delle tre strade è la Sua?

I confronti che presentano questa scelta come due pulsanti saltano la strada che vendiamo più spesso, perché le strade in realtà sono tre; si distinguono per quanta parte del Suo processo vive in codice che può cambiare da sé, e la scelta tra loro è una scelta su dove d’ora in poi si troveranno le regole dei Suoi prezzi e dei Suoi ordini — nella finestra delle impostazioni, nel Suo repository o a metà strada tra i due.

La prima strada è uno strumento pronto con estensioni pronte — WooCommerce o OpenCart, che ai negozi già esistenti proponiamo anche noi. Nel core di WooCommerce ci sono due campi di prezzo, quello normale e quello promozionale, un solo numero di giacenza per prodotto o variazione e tre metodi di pagamento, nessuno dei quali incassa online, per cui il prezzo per un determinato gruppo di clienti, gli sconti per quantità, la trasformazione di un preventivo in ordine, l’esenzione IVA e le giacenze in più magazzini sono un acquisto a parte da un produttore a parte con un abbonamento annuale a parte. È la strada più rapida e molto spesso quella giusta, e il suo prezzo non è denaro, ma il fatto che le regole del Suo processo d’ora in poi abitano nella finestra delle impostazioni di un altro produttore.

La seconda strada nei confronti non compare quasi mai, benché sia quella che vendiamo più spesso: uno strumento pronto con sopra il nostro codice. WooCommerce è codice PHP open source, per cui la tabella dei prezzi per i rivenditori, il controllo del fido o la prenotazione della giacenza si possono scrivere accanto al core invece di comprarle come plugin, e licenze non ce ne sono — ci sono ore —, al prezzo che quel codice resta legato al ritmo degli aggiornamenti di WooCommerce e al modo in cui questa piattaforma conserva gli ordini. Una parte considerevole di quella che nel nostro listino si chiama versione Pro da 9.500 € è esattamente questo lavoro, ed è qui che sta la maggioranza dei nostri negozi.

La terza strada è la nostra piattaforma, in cui catalogo, carrello, checkout e logica dei prezzi sono scritti da zero attorno al Suo processo; è la partenza più cara e l’unica in cui non c’è nessun presupposto di un altro produttore su che cosa sia un prodotto e su quando un ordine diventa ordine. Dentro la terza strada c’è una biforcazione: Bagisto e Lunar sono pacchetti di commercio per Laravel con licenza MIT — il 6 agosto 2026 su GitHub rispettivamente 27.943 e 3.588 stelle — che danno catalogo e carrello già scritti, in cambio di un’ulteriore dipendenza esterna il cui ritmo non è nelle Sue mani. Noi di lì non passiamo.

Quanto costano all’anno le licenze dei plugin WooCommerce?

Per un negozio con settecento prodotti e tre livelli di rivenditore, il 6 agosto 2026 la prima strada costava 270 € l’anno per due prezzi pubblici più un terzo sconosciuto. Dynamic Pricing a 113 € l’anno dà gli sconti per quantità e per ruolo; B2B for WooCommerce, sviluppato da Addify, a 157 € l’anno dà prezzi per ruolo, prezzi a scaglioni, la trasformazione di un preventivo in ordine, l’esenzione IVA e metodi di pagamento e spedizione limitati per ruolo; ma per le giacenze in più magazzini nel core non è previsto nulla, quindi si aggiunge un terzo plugin a pagamento, per esempio Addify Multi Inventory Management, di cui il produttore non dichiara un prezzo annuale pubblico.

Quei 270 € l’anno sono poco più di cinque ore di sviluppo, perché nel nostro listino un’ora di sviluppo costa 50 €, e per funzioni che hanno un produttore, una documentazione e degli aggiornamenti è poco. Un prezzo che non conosce prima della trattativa, però, in un preventivo non è una riga: il plugin per i magazzini alza quel numero, e di quanto dipende dall’offerta che Le arriverà dopo aver dichiarato il numero di magazzini e il volume degli ordini.

Per un altro negozio le righe sono altre: a quello che vende abbonamenti, prenotazioni e livelli di iscrizione, agli stessi prezzi di quel marketplace WooCommerce Subscriptions costa 245 € l’anno, Bookings 218 €, Memberships 175 €, AutomateWoo 140 € e Product Add-Ons 70 € — in tutto 848 € l’anno. In cinque anni, se i prezzi non salgono, fanno 4.240 €: quasi l’intero prezzo di un negozio in versione Basic, che nel nostro listino è 4.500 €, e quasi metà della versione Pro da 9.500 €. Questa riga non si ammortizza, perché vale per un sito web, per un anno, e si paga ogni anno da capo.

Lo stesso numero girato al contrario sono quasi 85 ore di sviluppo a 50 €, e sono ore che restano nel Suo codice e nella Sua proprietà invece di ripresentarsi nella fattura dell’anno dopo. La fattura concreta da 848 € è per di più quella di un negozio di abbonamenti, prenotazioni e iscrizioni, non una norma — norme qui non ce ne sono, e ogni negozio questa riga se la deve sommare dal proprio processo. La riga delle licenze, inoltre, si aggiunge alla realizzazione, non la sostituisce: in entrambi i casi qualcuno ha costruito il negozio prima, e solo in uno dei due, a gennaio dell’anno dopo, per quello che è già stato costruito arriva di nuovo una fattura.

Che cosa fa la fattura quando non la si paga

Se l’abbonamento non si rinnova, la documentazione di WooCommerce.com lo dice apertamente: «the extension or theme remains installed on your site but will no longer receive updates» — il plugin resta installato, il negozio continua a funzionare, e spariscono soltanto gli aggiornamenti. La conseguenza di una licenza non rinnovata non è quindi un fermo che si nota lo stesso giorno, ma un pezzo di codice non corretto che continua a trattare pagamenti; un abbonamento copre inoltre un sito di produzione e un sito di sviluppo, e i sottodomini contano a parte.

Una riga si comporta diversamente e si comporta uguale da entrambe le parti: il connettore della contabilità di solito non è una licenza, ma un abbonamento che sale insieme al numero di ordini — MyWorks Xero Sync sul marketplace di WooCommerce parte da un livello gratuito, e poi il prezzo lo decide il volume, per cui questa riga cresce esattamente quando cresce il negozio. Una piattaforma su misura non la toglie, ma cambia chi mantiene il connettore, e nel nostro caso sono ore; nemmeno le righe vanno gonfiate: il multilingua non è automaticamente 99 € l’anno per WPML Multilingual CMS, perché accanto a WPML c’è anche Polylang, mentre la licenza WPML più economica, Multilingual Blog da 39 €, l’e-commerce non lo supporta, per cui per un negozio la scelta tra 39 € e 99 € non esiste.

Perché la differenza si vede dal secondo anno

Che il costo delle modifiche sia una spesa reale e non teorica lo mostra la piattaforma stessa: dal 2023 WooCommerce ha rimosso due pezzi portanti, ritirato una funzione beta e cambiato un valore predefinito. La REST API legacy è sparita dal core l’11 giugno 2024 con la versione 9.0, dopo essere stata dichiarata obsoleta già dalla versione 2.6 del 2016; il gateway PayPal Standard integrato è stato rimosso nella versione 8.9 di maggio 2024; la versione beta dell’editor dei prodotti è stata rimossa nella 11.0, comparsa nella directory il 4 agosto; mentre la conservazione degli ordini HPOS è diventata il valore predefinito per le nuove installazioni nella versione 8.2 di ottobre 2023 e non tocca i negozi esistenti finché qualcuno non li migra.

Su questo sfondo, nella sezione Advisories del blog per sviluppatori di WooCommerce, nei dodici mesi fino al 5 agosto 2026 ci sono 37 pubblicazioni — circa tre al mese —, e ognuna va verificata contro ogni estensione installata nel negozio, cosa che un negozio con quattro plugin regge senza sforzo e uno con venti non più. La pila non si accumula per di più in un giorno solo: i plugin arrivano uno alla volta, ognuno preso singolarmente è una decisione del tutto ragionevole, e la moltiplicazione delle combinazioni da verificare avviene in silenzio.

Dieci plugin non sono dieci pezzi, ma dieci contratti che possono finire ciascuno per conto proprio, e il proprietario cambia anche quando al codice non manca nulla. Il 31 ottobre 2025 il servizio di recensioni Judge.me ha spento la propria integrazione con WooCommerce insieme a Square, Squarespace, BigCommerce, Duda e PrestaShop: ai dati si è potuto accedere ancora fino al 19 novembre, poi l’accesso è stato rimosso in modo definitivo, e nell’esportazione i video delle recensioni non erano compresi, così che un patrimonio di marketing accumulato in anni è rimasto in parte dall’altra parte della porta. I casi tranquilli sono più convincenti: nel 2019 Automattic ha comprato Prospress, autrice di WooCommerce Subscriptions e AutomateWoo, nel 2020 GoDaddy ha comprato SkyVerge, i cui oltre sessanta plugin erano usati da più di 100.000 commercianti, ed entrambe le operazioni, per quanto si può giudicare da ciò che è pubblico, per i commercianti sono finite bene. La questione non è il danno, ma il fatto che il proprietario di un componente del Suo negozio può cambiare senza che Lei partecipi.

Quanto è grande davvero questo rischio

La scala lo ridimensiona, e i numeri qui sono nostri: nella rilevazione del 6 agosto 2026 l’API dei plugin di WordPress.org ha restituito 7.764 plugin con il tag «woocommerce», dei quali il 23,1% non è aggiornato da due anni o più, ma nella stessa rilevazione 10.809.800 installazioni attive stanno su plugin aggiornati negli ultimi sei mesi e soltanto 208.790 su plugin non toccati da più di tre anni. Nella stessa rilevazione, i plugin con 10.000 installazioni o più rimasti due anni senza aggiornamenti sono esattamente sei.

Il plugin abbandonato non è quasi mai quello popolare che conoscono tutti: il rischio sta in quell’unico modulo stretto che richiede esattamente il Suo processo — nei listini B2B, nel connettore del magazzino, nel generatore di etichette di un corriere preciso —, e più il Suo processo si discosta dalla media, più è vicino a quella parte della directory in cui l’ultimo aggiornamento è dell’anno prima dello scorso. Questa riga si può ridurre senza ricostruire nulla: in un contratto di manutenzione lo facciamo noi — riduciamo il numero dei plugin, configuriamo gli aggiornamenti e teniamo il monitoraggio —, e la ricostruzione è la risposta soltanto quando il problema non è più la manutenzione, ma il fatto che il processo non è scritto da nessuna parte.

Dove la forma dei dati di WooCommerce comincia a stringere

L’altro punto in cui il secondo anno costa è la forma dei dati, e prima di tutto il lato in cui questo argomento non è più vero: gli ordini nelle nuove installazioni dalla versione 8.2 stanno in quattro tabelle proprie, e la misurazione dell’azienda stessa del marzo 2023 mostra che la nuova conservazione accelera le operazioni sugli ordini invece di frenarle. A stringere è il lato dei prodotti, e lo hanno scritto meglio di tutti gli sviluppatori di WooCommerce stessi, il 1° aprile 2019, spiegando i miglioramenti di prestazioni della versione 3.6: articoli e variazioni passano per il sistema dei post di WordPress, in cui il post meta è straordinariamente flessibile, ma «not that efficient when we need to sort or filter by many meta values at once» — non particolarmente efficiente quando occorre ordinare o filtrare per molti valori meta contemporaneamente. La risposta, nello stesso rilascio, è stata wc_product_meta_lookup, una tabella ausiliaria denormalizzata con SKU, prezzo e stato della giacenza accanto al post meta, non al posto suo, per cui la forma di base è rimasta quella che era.

Il lavoro equivalente sul lato dei prodotti, woocommerce-product-tables-feature-plugin, dal 16 ottobre 2017 vive soltanto su GitHub e non è abbandonato — l’ultima modifica è del 31 luglio 2026 —, solo che continua a non essere considerato abbastanza stabile per la directory di WordPress.org. Accanto sta wp_options, il cui campo autoload per impostazione predefinita non ha un indice, i cui dati autocaricati vengono letti a ogni caricamento di pagina, che WooCommerce stessa consiglia di tenere sotto le circa 500 righe e la cui crescita è provocata proprio da estensioni, plugin e temi — la stessa pila di cui si parlava prima, vista dal lato del database.

Che cosa dà Laravel a un negozio che uno strumento pronto non dà

Laravel non è un negozio e non finge di esserlo: dà pezzi nominati, documentati e con licenza MIT, con cui il negozio lo assembla qualcuno, per cui la domanda che qui fa la differenza sui costi non è «il framework è buono?», ma «quali parti del Suo processo diventano finalmente tabelle Sue e lavori Suoi». Nel negozio di un commerciante la risposta di solito sono quattro righe — la tabella dei prezzi per i rivenditori, il fido, la prenotazione della giacenza e la sincronizzazione con la contabilità —, ed è esattamente quello che in uno strumento pronto compra da quattro produttori diversi e poi mette d’accordo tra loro.

Prima di questo è onesto dire che cosa questa strada non dà, perché nessuna delle quattro righe la dà nemmeno Laravel: gli starter kit ufficiali del framework danno l’autenticazione e nient’altro — non c’è né catalogo, né carrello, né passaggio di checkout, né magazzino —, e l’unico pacchetto di commercio che arriva in dotazione è Cashier, che serve le fatture degli abbonamenti dal lato Stripe o Paddle e si aspetta che i prodotti con i loro prezzi siano già descritti nel pannello del servizio di pagamento. Quello che Laravel dà è la forma in cui quelle quattro righe sono economiche da scrivere e ancora più economiche da cambiare dopo.

Code, transazioni e la forma del Suo database

Il primo pezzo sono le code: una sola API sopra più motori — Redis, database, Amazon SQS, Beanstalkd — che permette all’elaborazione dell’ordine, alla sincronizzazione con l’ERP e all’e-mail di uscire dalla richiesta, così che l’acquirente non aspetta più la risposta del sistema contabile. Nella documentazione è nominato anche ciò che decide un’implementazione reale: catene e batch di lavori, lavori unici che la coda non esegue due volte, tentativi di ripetizione e un archivio dei lavori falliti da cui si possono rilanciare. Un ordine eseguito due volte è una fattura che qualcuno dovrà poi stornare, e un cliente che se ne accorge prima di Lei.

Horizon mostra la portata delle code, i tempi di esecuzione e gli errori, permette di descrivere in codice la configurazione dei worker e avvisa quando una coda aspetta troppo a lungo, ma richiede Redis e con Redis Cluster al momento non funziona, quindi è una voce a sé nella fattura dell’hosting, non un’aggiunta gratuita. Le transazioni sono invece ciò che nella pratica significa la frase «l’ordine e il movimento di magazzino avvengono entrambi o nessuno dei due»: DB::transaction in caso di errore annulla le modifiche da sé e permette di ripeterle se il database finisce in stallo.

La documentazione di Laravel chiama le migrazioni controllo di versione per il database, e nella pratica significa che tabelle, indici e chiavi esterne le progetta attorno alla Sua logica di prezzi e giacenze, non attorno a quello che qualcun altro una volta ha deciso sul concetto di prodotto. Ricerca e fatturazione degli abbonamenti restano per di più una scelta, non una riga mensile obbligatoria: Scout indicizza lì nel database con gli indici full-text di MySQL o PostgreSQL senza servizi esterni, mentre il lato Stripe lo serve Cashier, se di abbonamenti nel negozio ce ne sono.

Tabella dei prezzi, fido e prenotazione della merce nel codice

Come sia in concreto lo mostra meglio di tutto la prima delle quattro righe: la tabella dei prezzi per i rivenditori sul codice proprio è una migrazione con quattro colonne — gruppo di clienti, prodotto, soglia di quantità e prezzo — e un indice univoco sulle prime tre, per cui il prezzo per un determinato acquirente lo trova una query con un solo join, non una ricerca tra valori meta, e un nuovo livello di prezzo è una nuova riga in tabella, non una nuova impostazione nella finestra di un altro produttore. Quando dopo un anno arriva un quarto livello con un altro criterio di arrotondamento, cambiano un punto e un test, ed entrambi sono nel Suo repository.

Fido e prenotazione della giacenza sono lo stesso pensiero un passo più avanti, perché anche lì tutto regge su una tabella e una transazione: la somma delle fatture non pagate è una colonna sul cliente, e il controllo avviene nella stessa transazione in cui nasce l’ordine, per cui due ordini inviati nello stesso momento non possono passare entrambi sotto il limite, mentre in caso di stallo la transazione si ripete da sé. La prenotazione è invece una riga con una scadenza, che nasce insieme all’ordine e sparisce con un lavoro pianificato in background se l’ordine non viene pagato, per cui la giacenza di magazzino non è più un numero che due acquirenti possono svuotare contemporaneamente.

La sincronizzazione con la contabilità è un lavoro in coda marcato come unico, per cui un tentativo ripetuto non emette mai una fattura due volte, e quando al mattino Horizon mostra che di notte dal lato della contabilità c’è stata un’interruzione, l’archivio dei lavori falliti permette di rilanciarli in ordine invece di riscriverli a mano. Ognuna di queste quattro righe in uno strumento pronto c’è, solo come finestra di impostazioni di un produttore: le sue regole non le vede, dopo ogni aggiornamento va verificata da capo e su un’altra piattaforma non si sposta.

Due lavori che sono già in produzione

Come sia in un progetto e non nella documentazione si vede nei nostri lavori Laravel. Nella piattaforma di ordinazione di pasti LIDO il prezzo non lo decide il prodotto, ma l’indirizzo: la geolocalizzazione stabilisce la zona di consegna, la distanza e il costo, ognuno dei tredici ristoranti ha il proprio assortimento di piatti, e accanto al negozio lavora un sistema separato di automazione dei processi, in cui arrivano tutti gli ordini e da cui vengono distribuiti tra ristoranti e cuochi — con integrazioni verso più di dieci altri sistemi, tra cui Wolt, QWQER e RKeeper. Nell’e-commerce Riga Lashes su Laravel ci sono prezzi per variante, account clienti, lista dei desideri e listino dei servizi dello studio, e dietro di essi il magazzino della merce, le integrazioni con i corrieri e i pagamenti, dove il processo è automatizzato fino alla fase di imballaggio. In entrambi i casi la parte decisiva avremmo dovuto scriverla comunque, anche su uno strumento pronto, solo dentro il prezzo e la forma d’ordine di un altro produttore, ed è esattamente questa la differenza che resta: sul codice proprio questo lavoro è un repository solo senza un abbonamento a parte per ogni capacità, e dopo ogni aggiornamento della piattaforma non va verificato da capo. Laravel lo scriviamo dal 2013, e su di esso gira la maggior parte dei nostri sistemi su misura, dei portali del settore pubblico e delle piattaforme B2B.

Dove vadano i soldi che non stanno nelle licenze è una domanda concreta, e la risposta è altrettanto concreta: le quasi 85 ore che in cinque anni costa la riga di licenze da 848 € l’anno, sul codice proprio sono esattamente questa tabella dei prezzi, questo fido, questa prenotazione e questa sincronizzazione, scritti attorno al Suo processo. Restano nel Suo repository anche se un giorno smettessimo di essere i Suoi partner: in una realizzazione su commessa il codice è Suo dal primo giorno, ed è scritto anche sulla pagina del nostro servizio Laravel.

Filament: il pannello di amministrazione che nessuno scrive da zero

La parte del pannello di amministrazione dell’obiezione che in un sistema costruito da sé si debba scrivere tutto da zero la toglie Filament, framework di interfaccia open source per applicazioni Laravel. Le risorse generano schermate CRUD per i modelli Eloquent, il costruttore di tabelle dà filtri, ordinamento e paginazione, i componenti dei moduli arrivano con la validazione integrata, mentre i permessi di accesso Filament li legge direttamente dalle policy dei modelli Laravel, per cui i controlli sui ruoli non vanno scritti una seconda volta. Gestori delle relazioni, widget della dashboard e notifiche sono lì in dotazione; anche il supporto multi-tenant, con l’avvertenza di Filament stessa che si tratta di un insieme di strumenti e non di una garanzia e che della separazione dei dati tra tenant risponde chi implementa; tutto lo strato ha licenza MIT, come Laravel stesso, per cui lì non c’è nessun canone di licenza.

La cosa più importante però non è quello che il framework disegna, ma dove vanno i soldi liberati: schermate di modifica dei prodotti, tabelle degli ordini, filtri e controlli dei permessi sono quella parte dello sviluppo che l’acquirente non vede mai e che il committente paga comunque a tariffa piena, e quando le dà il framework il budget va alla logica di prezzi, ordini e magazzino per cui lo sviluppo su misura era stato scelto. L’esempio è lì dove sta leggendo: questo sito gira su Laravel 13 e Filament 5, e tutto il lavoro redazionale in dodici lingue avviene in un pannello che abbiamo configurato, non scritto da zero.

Dove finisce il framework e comincia il negozio

Filament non è un negozio, e questo confine vale la pena tracciarlo chiaramente: il framework dà il pannello di amministrazione — schermate, tabelle, moduli e controlli dei permessi —, ma non sa nulla di che cosa si trovi in quelle tabelle e secondo quali regole ci finisca. Catalogo dei prodotti con variazioni e attributi, carrello, passaggio di checkout, regole di prezzo con livelli cliente e sconti per quantità, ciclo di vita dell’ordine dalla creazione al reso e prenotazione delle giacenze in magazzino — di tutto questo nella dotazione di Laravel e Filament non c’è nulla. Filament è come un’officina attrezzata, con scaffali, banchi di lavoro e luce; che cosa produrci non arriva in dotazione.

Quanto letteralmente vada inteso lo mostra la documentazione stessa, in cui i modelli Order e Payment compaiono soltanto come esempi che lo sviluppatore scrive da sé, perché nel framework classi simili semplicemente non esistono. Non è un difetto del framework, ma una divisione del lavoro: Filament promette un’interfaccia di amministrazione e nient’altro, esattamente come Laravel promette un framework e non un’applicazione pronta. Nella pratica significa che Filament accorcia il lavoro di amministrazione, ma non accorcia nulla nella parte per cui lo sviluppo su misura era stato scelto.

Per questo nel nostro listino la versione Basic di un negozio da 4.500 € arriva senza modulo magazzino, supporto multilingua, listini B2B, sistema di sconti e migrazione dei contenuti, mentre la versione Pro da 9.500 € li comprende tutti. La differenza non è un ricarico per una tecnologia più moderna, ma il prezzo di quello che qualcuno deve scrivere, ed è esattamente per questo che è uguale su entrambe le piattaforme. Un sistema Laravel a perimetro fisso a partire da 8.000 € nel listino è già un’altra riga e un altro prodotto: non è un negozio, ma un sistema in cui l’intero processo nasce da zero.

Quello che non promettiamo: dove il su misura costa di più

Un negozio costruito da sé è libero dalle licenze annuali dei plugin, non dalla manutenzione, e sono due cose completamente diverse. Laravel dà a ogni rilascio 18 mesi di correzioni dei bug e due anni di correzioni di sicurezza, pubblica una nuova versione maggiore una volta all’anno e un livello di supporto a lungo termine lì non c’è, per cui le date sono precise: Laravel 13 è uscito il 17 marzo 2026 con correzioni di sicurezza fino al 17 marzo 2028, la finestra di sicurezza di Laravel 11 si è chiusa il 12 marzo 2026, mentre le correzioni dei bug di Laravel 12 finiscono il 13 agosto 2026. Una volta all’anno o ogni due, quindi, il sistema va portato su una nuova versione maggiore, e la documentazione di Laravel dice che si sforzano di far sì che lo si possa fare in un giorno o meno — uno sforzo, non una promessa su quanto durerà nel Suo sistema.

Il conto alla rovescia di PHP è per di più uguale per entrambe le parti: ogni versione ha due anni di supporto attivo e due anni di sole correzioni di sicurezza, per cui in una finestra di cinque anni rientrano almeno uno e, a seconda del punto del ciclo in cui parte, fino a due passaggi obbligati di PHP, indipendentemente da che cosa ci sia sotto. Né un negozio WooCommerce né uno Laravel sfuggono a questa riga, e in entrambi i casi la pianifica la stessa persona che pianifica il resto della manutenzione — la differenza è soltanto che sul codice proprio il passaggio si può fare quando fa comodo a Lei, e non quando un’estensione smette di supportare la versione vecchia.

Tre voci in cui vince lo strumento pronto

Più care della manutenzione sono altre tre voci, e la prima è l’ecosistema: qui lo strumento pronto vince senza discussione. Un’ulteriore automazione di marketing in un negozio WooCommerce è una voce di marketplace — AutomateWoo, per esempio, costa 140 € l’anno — e, nella nostra esperienza, il lavoro di una giornata, mentre in un sistema costruito da sé è una specifica, delle ore e un test, e a 50 € l’ora è la prima funzione di cui si chiederà se serva davvero; in questo elenco non rientrano un campo prodotto o un nuovo filtro in amministrazione, perché li dà il framework. L’assenza di ecosistema non è un costo una tantum, ma una soglia stabilmente più alta per tutto quello che dopo Le viene voglia di provare, e per un negozio che sperimenta molto può pesare più della fattura delle licenze — è esattamente per questo che la fattura delle licenze non la chiamiamo l’argomento principale.

La seconda è la dipendenza da un’unica squadra, e a questa risponde la struttura, non un’affermazione: in una realizzazione su commessa il codice è Suo dal primo giorno, lo scriviamo in una struttura Laravel standard senza esotismi, la logica critica ha i test, e in dotazione arrivano un README documentato e la CI, così che il sistema possa prenderlo in carico qualcun altro. Sviluppatori Laravel in Lettonia sono facili da trovare, ed è per questo che la nostra risposta alla domanda sul perché Laravel finisce con la frase che non resta dipendente da un’unica squadra, nemmeno da noi; il rischio così non si annulla, ma diventa trasferibile.

La terza è il PCI DSS, ed è contro di noi. La revisione del SAQ A pubblicata a gennaio 2025 ed entrata in vigore il 31 marzo 2025 ha eliminato, per i commercianti la cui pagina di pagamento è erogata interamente e direttamente da un fornitore conforme al PCI DSS e che hanno attestato da sé che il sito non è esposto ad attacchi basati su script, i requisiti 6.4.3 e 11.6.1 — l’inventario degli script, la loro giustificazione e il monitoraggio delle modifiche — e il requisito 12.3.1 sull’analisi mirata dei rischi, precisando allo stesso tempo che questo non elimina i requisiti PCI DSS in quanto tali. Questa agevolazione descrive un piccolo negozio WooCommerce con la pagina di pagamento della banca molto più precisamente del passaggio di checkout che disegniamo nel nostro codice, e accanto sta un secondo fatto altrettanto scomodo: la vulnerabilità di marzo l’hanno trovata e corretta altri, mentre in un sistema che abbiamo scritto noi lo fa la nostra squadra, per cui lì la manutenzione è una riga di contratto, non un presupposto.

Le nostre dipendenze non sono di un’altra specie

Filament è esattamente la stessa dipendenza di terze parti dei plugin di cui si è appena parlato, e la differenza tra loro è di grado e di posizione, non di principio. È una dipendenza con licenza MIT nello strato di sviluppo, il suo codice si trova nel nostro repository e se ne può fare un fork, e non sta sulla strada del pagamento dell’acquirente, perché disegna il pannello di amministrazione, non incassa.

Se il progetto si fermasse domani, il negozio continuerebbe ad accettare ordini, e a invecchiare sarebbe la parte che vedono i Suoi dipendenti, non quella che prende i soldi dall’acquirente. Filament pubblica inoltre una tabella di supporto delle versioni con date precise: la terza versione è uscita ad agosto 2023 e riceve correzioni di sicurezza fino al 1° gennaio 2028, una finestra più lunga di quella che Laravel dà alle proprie versioni.

Filament non è però un pacchetto first-party di Laravel, perché Laravel nel proprio elenco dei pacchetti non lo cita, e dietro al progetto non c’è un’azienda con un bilancio, ma una squadra attorno a un unico manutentore: a suo nome nel repository ci sono circa 17.000 modifiche, per il collaboratore successivo circa 2.400, e il finanziamento arriva dagli sponsor su GitHub e da consulenze a pagamento. Nemmeno il ritmo dei rilasci è tenero: la quarta versione è uscita ad agosto 2025, la quinta già a gennaio 2026, due giorni dopo Livewire 4, che è un’ulteriore dipendenza di terze parti sotto di essa. E la frase «se servirà, ne faremo un fork» è a buon mercato da scrivere e cara da eseguire.

Non offriamo un negozio senza dipendenze di terze parti, perché una cosa simile non ce l’abbiamo né noi né nessun altro; offriamo un numero minore di dipendenze, una licenza che permette di tenere il codice e di mantenerlo da soli, e un confine chiaro tra ciò che in caso di guasto ferma il flusso di cassa e ciò che rovina la giornata di lavoro di un dipendente. Se questa differenza non Le sembra abbastanza grande, è un’obiezione del tutto fondata — e allora Le costruiamo lo strumento pronto, perché è la stessa versione Basic o Pro allo stesso prezzo. Nessuna delle due risposte fa di noi il partner sbagliato.

Come facciamo questa scelta nella pratica

Insieme alla piattaforma compra la risposta a una sola domanda — chi può cambiare le regole dei Suoi prezzi e dei Suoi ordini, e secondo quale calendario —, e sul codice proprio quella risposta è «Lei, nel prossimo sprint», mentre su un’estensione di un altro produttore è «quando il produttore lo includerà in un suo rilascio, se lo includerà». Per questo nella conversazione di analisi non chiediamo il fatturato, ma chiediamo quanti livelli di prezzo ha davvero e se un cliente vede mai un prezzo diverso da un altro — è il confine tra i due campi di prezzo che WooCommerce dà da sé e una tabella dei prezzi che qualcuno deve mantenere.

Poi chiediamo se la giacenza vive in più di un posto, perché il magazzino più lo scaffale del negozio sono già due posti, e due posti significano che qualcuno deve decidere quale dei due valga come verità. Le due domande successive di solito decidono tutto: se un ordine diventa ordine subito, oppure se prima gli serve un’approvazione — dell’ufficio acquisti del cliente, del Suo responsabile commerciale o del fido —, e se il processo reggerebbe anche nel caso in cui il catalogo raddoppiasse.

Se la risposta sull’approvazione è «sì», si trova nel punto in cui il mercato dei plugin pronti è più debole: la sorveglianza dei fidi e il blocco degli ordini oltre il limite non sono né nel core né nei pacchetti B2B più diffusi, e li promettono soltanto poche voci specializzate, per esempio QuarkCode B2B Commerce Suite. Quanta parte del processo è disposto a rifare seguendo lo strumento — è la domanda che resta, e i requisiti poco chiari sono l’errore più caro dell’intera commessa, di cui abbiamo scritto a parte.

Se le risposte stanno dentro lo strumento pronto, prenda lo strumento pronto, perché costerà meno, e a costruirglielo saremo noi. Se una o due non ci stanno, con ogni probabilità si trova sulla strada di mezzo, e nel listino le corrisponde la stessa versione Pro da 9.500 € su WooCommerce — lo stesso prezzo che su Laravel, perché a costare è il lavoro, non la piattaforma. Se non ci stanno in tre o più, e soprattutto se tra queste ci sono il passaggio di approvazione o il fido, il discorso non è più sulla piattaforma, ma su quanta parte del processo vive in codice che possiamo cambiare senza concordarlo con un altro produttore.

Tre partenze e quanto costa ciascuna

Nella pratica vendiamo tre partenze, e ciascuna ha un prezzo calcolabile: la prima è partire con catalogo, pagamenti e spedizioni, andare online, e aggiungere prezzi B2B, logica degli sconti e integrazioni di magazzino quando si vedono i primi ordini reali — nelle nostre risposte la chiamiamo la scelta di solito giusta. La seconda è trasferire un negozio esistente, ed è un progetto, non un interruttore: la struttura degli URL la conserviamo, ma i modelli dei dati non coincidono uno a uno, e ogni plugin che ha conservato campi propri va valutato a parte. Nella versione Pro e nel noleggio la migrazione è compresa; nella versione Basic non c’è, e la preventiviamo a parte in base al volume, perché il prezzo lo decidono la quantità di dati e il numero dei campi.

La terza è il noleggio: un negozio Laravel insieme al nostro hosting a partire da 130 € al mese più 600 € una tantum di configurazione, e nel listino la sua composizione è la stessa della versione Pro — modulo magazzino, supporto multilingua, listini B2B, sistema di sconti e migrazione dei contenuti —, solo con hosting, aggiornamenti e manutenzione in più; disponibile è soltanto con Laravel, perché un negozio WooCommerce da noi non si può noleggiare. La scelta della piattaforma di per sé decide alcune cose precise che il lavoro non pareggia: questa riga di noleggio, le patch automatiche gratuite del core, la soglia dell’ecosistema e chi deve dare il consenso prima che la Sua prossima modifica arrivi in produzione. Tutto il resto è lavoro.

Il noleggio parte da 130 € al mese, che in cinque anni sono a partire da 7.800 €, più 600 € di configurazione — a partire da 8.400 € —, e comprende hosting, aggiornamenti e manutenzione. La versione Pro costa 9.500 € una volta sola, e l’hosting lì arriva a parte: il nostro hosting gestito parte da 45 € al mese, quindi a partire da 2.700 € in cinque anni, in tutto a partire da 12.200 €, e gli aggiornamenti dell’applicazione lì non sono ancora compresi. Entrambe le cifre sono soglie minime, non totali, e sono confrontabili perché nel listino la composizione delle funzioni delle due è la stessa. Nel noleggio paga per l’uso insieme all’hosting, in una realizzazione paga il sistema subito e, confrontando le due soglie, nella finestra di cinque anni il noleggio parte più in basso. Dove finisca ciascuna delle due lo decide il volume, per cui entrambe le preventiviamo sul progetto, invece di leggerle dal listino.

Da lì il lavoro procede in sprint di due settimane con una demo al termine di ciascuno; pagamenti, corrieri e contabilità li colleghiamo e li verifichiamo prima del lancio; prodotti, clienti e storico degli ordini li trasferiamo conservando la struttura degli URL. Per lavori non standard più grandi lavoriamo a tempo e materiali con un tetto settimanale, perché un prezzo fisso lì di solito significa o un ricarico per il rischio o una lite sul perimetro, e la tariffa oraria nel listino è di 50 €. L’intero percorso richiede 8–32 settimane. Riceva una valutazione del progetto e una raccomandazione tecnologica — risponda a noi alle stesse domande, e Le diremo quale delle tre strade nel Suo caso costa meno.