Come sviluppare un nuovo eCommerce nel 2026

Q: Quanto costa sviluppare un eCommerce nel 2026?

Non esiste una risposta documentata: nessuna fonte primaria italiana o europea pubblica costi di sviluppo di un eCommerce con metodologia verificabile, e le fasce "da X a Y euro" in circolazione sono listini di venditori senza campione. Quello che si può costruire è il tuo numero: conta i punti di integrazione (gestionale, corriere, fatturazione, pagamento, marketplace) chiedendo una stima separata per ciascuno, poi somma i costi del primo anno — canoni, commissioni sui pagamenti, hosting, manutenzione, contenuti, acquisizione. Il totale è tipicamente due o tre volte il preventivo di sviluppo.

Q: Quali obblighi di legge riguardano un nuovo eCommerce?

Quelli che cambiano il progetto tecnico: accessibilità (obbligatoria dal 28 giugno 2025, con esenzione per le microimprese sotto i dieci occupati e i due milioni); dati del fabbricante e avvertenze nelle schede prodotto (GPSR, dal 13 dicembre 2024); prezzo più basso dei trenta giorni in ogni annuncio di sconto e trasparenza sulle recensioni (Omnibus); IVA del Paese di destinazione oltre i 10.000 euro annui intra-UE; trasparenza sull'uso di sistemi di IA dal 2 agosto 2026; consenso per i pixel nelle email entro il 29 ottobre 2026. Due cose che invece non servono: i corrispettivi telematici per la vendita di beni spediti e il link alla piattaforma ODR, dismessa dal 20 luglio 2025.

Dalla ricerca di mercato al go-live: le otto fasi di un progetto eCommerce, quali scelte e conseguenze su tempi, costi e organizzazione

Il costo di un eCommerce non è un prezzo: è una curva. Il preventivo di sviluppo è il primo punto e quasi mai il più alto. Sotto ci sono le commissioni sui pagamenti, che crescono con il fatturato; i canoni della piattaforma, che crescono a scaglioni; il lavoro di chi tiene allineati catalogo e magazzino; gli adeguamenti normativi, che arrivano quando arrivano. La risposta utile alla domanda "quanto costa" non è una cifra: è il metodo per calcolare la tua.

Questa guida è la prima di due parti e copre tutto ciò che accade prima che il negozio entri in produzione: ricerca di mercato, make or buy, budget, scelta delle risorse, integrazione con il gestionale, obblighi di legge, preparazione al lancio e go-live. Per ogni fase trovi come si sceglie e cosa si paga per aver scelto così, in mesi, in dipendenza da un fornitore e in lavoro d'ufficio permanente. C'è anche una sezione su linguaggi, framework e strumenti più usati nel 2026, con i dati di diffusione reali e con gli strumenti per le valutazioni prima di vendere. Il giorno dopo il lancio — manutenzione, sicurezza, magazzino, catalogo, marketing in esercizio — è il tema della seconda parte.

Dove esistono dati verificabili sono riportati con la fonte. Dove non esistono, l'articolo lo dice: non esiste alcuna fonte primaria sui costi di sviluppo di un eCommerce in Italia, e le fasce "da 5.000 a 15.000 euro" che trovi ovunque sono listini di venditori travestiti da ricerca di mercato. Non esiste nemmeno un dato difendibile sul CPC medio italiano né sul costo di acquisizione cliente nel retail. Sapere quali numeri non reggono, quando devi difendere un budget, serve quanto sapere quali reggono.

INDICE DEI CONTENUTI

Che cosa stai comprando davvero
Fase 1 — La ricerca di mercato: i numeri che cambiano il progetto
Fase 2 — Make or buy: quattro strade, quattro tipi di dipendenza
Con che cosa è fatto un eCommerce: linguaggi, framework e strumenti nel 2026
Fase 3 — Il budget: quello che paghi una volta e quello che paghi per sempre
1. I pagamenti: la voce più grande e la meno negoziata
2. Infrastruttura, servizi e la voce che sfora sempre
Fase 4 — La ricerca delle risorse: cinque mestieri, non un fornitore
Fase 5 — L'integrazione con il gestionale: il punto in cui i progetti si fermano
Fase 6 — Gli obblighi di legge: requisiti tecnici, non un capitolo legale
Fase 7 — Quello che va predisposto prima del lancio, perché dopo costa il doppio
Fase 8 — Il go-live: la settimana in cui si scopre cosa è stato dimenticato
I tempi: cosa determina davvero la data di lancio
Come si costruisce un budget che regge
La scelta in pratica, per tipo di azienda
Conclusioni
Domande frequenti

Che cosa stai comprando davvero

Un eCommerce sembra un sito e non lo è. Un sito pubblica informazioni; un eCommerce esegue transazioni e le riconcilia con il resto dell'azienda. È la seconda metà a fare il costo, e a non comparire quasi mai nei preventivi. Ogni ordine deve diventare un documento fiscale, un movimento di magazzino, una spedizione tracciata e, quando serve, un reso e una nota di credito. Se non lo fa il software lo fa una persona: il costo non sparisce, diventa permanente.

Da qui il criterio che attraversa tutte le fasi. Ogni scelta va valutata su tre assi: quanto costa farla, quanto costa mantenerla, quanto costa disfarla. Il terzo è quello che nessuno guarda ed è quello che decide se fra tre anni potrai cambiare fornitore o piattaforma senza rifare tutto. Una soluzione che ti fa partire in sei settimane e non ti fa esportare gli ordini in un formato utile non è economica: è un prestito.

Fase 1 — La ricerca di mercato: i numeri che cambiano il progetto

Non serve a decidere se vendere online — quella decisione l'hai già presa — ma tre cose tecniche che poi costano care da cambiare: quanto è maturo il tuo comparto online, quanto pesano i marketplace, quale sia il ticket medio realistico. Da lì discendono piattaforma, complessità del checkout e budget di acquisizione.

Quanto è già online il tuo comparto

Il dato italiano con metodologia dichiarata è quello dell'Osservatorio eCommerce B2c Netcomm–Politecnico di Milano: nel comunicato del 19 maggio 2026 l'eCommerce di prodotto in Italia vale 42,6 miliardi di euro (+6%), con una penetrazione dell'11,5% sul totale acquisti; sommando i servizi si arriva a 66,6 miliardi e 35 milioni di consumatori digitali.

Il numero che conta è però quello del tuo comparto, e le distanze sono enormi: informatica ed elettronica vale 9,5 miliardi con una penetrazione del 45%, l'editoria è al 41%, abbigliamento (6,6 miliardi) e arredamento (4,9 miliardi) stanno intorno al 20%. La ricaduta è immediata: in un comparto al 45% entri dove il cliente confronta prezzi in tre secondi e la logistica è uno standard, e il vantaggio dovrà venire da assortimento o servizio; in un comparto al 20% puoi ancora vincere con l'esperienza d'acquisto e con la scheda prodotto.

Una nota di metodo: il rapporto annuale di Casaleggio Associati stima per il 2025 un fatturato eCommerce italiano di 90,6 miliardi. Le due cifre misurano perimetri diversi e non vanno sommate né confrontate. Se in riunione qualcuno usa il numero più grande per giustificare il budget più grande, la domanda giusta è quale universo stia misurando.

I marketplace non sono un canale in più: sono una scelta di architettura

Nei dati Eurostat sul commercio elettronico delle imprese (anno di riferimento 2024), il 65% delle imprese italiane con vendite via web passa anche dai marketplace: secondo valore dell'Unione dopo la Lituania.

Se prevedi di venderci — ed è probabile — non è una decisione di marketing da prendere dopo il lancio: cambia il progetto dal primo giorno. Il catalogo smette di essere "quello che si vede sul sito" e diventa una fonte di dati che alimenta canali con attributi obbligatori diversi, scorte condivise fra canali che vendono insieme e prezzi che possono divergere. Chi apre Amazon sei mesi dopo scopre spesso che il catalogo va rifatto, e quel rifacimento costa più di quanto sarebbe costato prevederlo.

Il ticket medio decide il checkout, non il contrario

L'ultimo numero da portare a casa è il valore medio dell'ordine atteso, con una forchetta onesta. Da lì discendono i metodi di pagamento da integrare, la sostenibilità della spedizione gratuita e quanto puoi spendere per acquisire un cliente. Un errore del 30% sul ticket medio non produce un errore del 30% sul progetto: produce una struttura di costi sbagliata, perché le commissioni hanno una componente fissa per transazione che sui carrelli piccoli pesa il doppio.

Fase 2 — Make or buy: quattro strade, quattro tipi di dipendenza

È la decisione che determina tutte le altre e viene presa peggio, perché viene trattata come una scelta di prodotto — "quale piattaforma è la migliore" — mentre è una scelta su chi controlla il tuo negozio e quanto ti costa cambiare idea. Le opzioni sono quattro, in ordine di controllo e di responsabilità crescenti.

SaaS chiuso: velocità in cambio di un affitto proporzionale

Compri un servizio completo: niente server, niente aggiornamenti, niente vulnerabilità da tappare di notte. Il listino di Shopify, alla verifica del 28 agosto 2026, espone i piani in dollari: Basic 39 $ al mese (29 $ annuale), Grow 105 $, Advanced 399 $, Plus da 2.300 $. BigCommerce va da 29 $ a 1.499 $, con tetti di fatturato oltre i quali si cambia piano.

Il numero da guardare non è il canone ma la clausola sotto: se non usi il loro sistema di pagamento paghi una commissione aggiuntiva su ogni transazione — 2% su Basic, 1% su Grow, 0,6% su Advanced, 0,2% su Plus, con struttura analoga su BigCommerce. Su un milione di euro transati, un 1% sono diecimila euro l'anno che non compaiono in nessun preventivo.

Ricaduta. Tempi in settimane, costi iniziali bassi, nessuna competenza sistemistica. In cambio il costo cresce col fatturato, le personalizzazioni profonde del checkout sono limitate o riservate ai piani alti, e l'integrazione con un gestionale non standard passa da app di terze parti a canone. È la scelta giusta quando il tuo processo di vendita somiglia a quello di tutti gli altri, e diventa cara nel momento esatto in cui smette di somigliargli.

Open source self-hosted: partire da un framework esistente

Una base già scritta che gira su infrastruttura tua. WooCommerce dichiara core gratuito e nessuna commissione sulle vendite, con estensioni fra 29 e 299 dollari l'anno; PrestaShop distribuisce gratis l'edizione Classic e offre una versione ospitata a 29 € al mese; Shopware ha una Community Edition MIT e piani da 600 € al mese; Sylius, su Symfony, è MIT con un'edizione Plus da 800 € l'anno. Adobe Commerce non pubblica alcun prezzo e non dichiara nemmeno il criterio di calcolo.

Ricaduta. Nessuna commissione sul fatturato e controllo su codice e dati: a volumi alti è strutturalmente la strada più economica. Il prezzo lo paghi in responsabilità operativa — aggiornamenti di sicurezza, versioni del linguaggio che escono di supporto, compatibilità delle estensioni, backup da provare e non solo da configurare. Un negozio open source senza un contratto di manutenzione non è più economico di un SaaS: è un SaaS di cui nessuno sta pagando il canone, finché non si rompe.

Headless e composable: potenza in cambio di superficie

La logica di vendita in un motore accessibile via API, la vetrina come applicazione separata. Medusa è open source con cloud da 29 $ al mese; Saleor parte da 1.599 $ al mese fino a 200.000 $ di transato mensile; commercetools non pubblica prezzi.

Ricaduta. Rende naturali le cose difficili: più vetrine sullo stesso catalogo, app mobile, negozio fisico collegato, catalogo esposto agli agenti conversazionali. In cambio raddoppia la superficie da costruire e mantenere, perché frontend e backend diventano due progetti con due cicli di rilascio. Su un catalogo piccolo e un canale solo, headless è una complicazione pagata in anticipo per un beneficio che non arriva.

Da zero: quando ha senso e quando è vanità

Scrivere l'applicazione partendo da un framework generalista — Laravel, Symfony, Django — senza adottare un motore di commercio. Ha senso in un caso solo, ma reale: quando il processo di vendita è il prodotto. Configuratori che calcolano il prezzo su misure e materiali, listini contrattualizzati per cliente, preventivazione con approvazione, noleggio con calendario, B2B con fidi e scadenzari. Lì il carrello è la parte facile, e piegare una piattaforma nata per vendere magliette costa più che scrivere il pezzo che serve.

Ricaduta. Prima versione più lunga e nessuna scorciatoia sulle funzioni che altrove sono gratis: imposte, resi, promozioni, multilingua. In compenso non paghi nulla che non usi e non hai tetti. La domanda che smaschera la vanità è una: quali sono le tre cose che il tuo negozio deve fare e che una piattaforma esistente non fa? Se non ci sono tre risposte concrete, non serve partire da zero.

Come si decide: tre domande, non una tabella comparativa

Quante integrazioni ha il progetto. Contale: gestionale, magazzino, corriere, fatturazione, CRM, marketplace, cassa del negozio fisico. Fino a due, la piattaforma conta poco. Da cinque in su la vera piattaforma è l'integrazione, e va scelto ciò che espone API pulite, non ciò che ha il tema più bello.

Quanto è unico il processo. Se lo descrivi con "catalogo, carrello, pagamento, spedizione", ogni soluzione pronta va bene e il denaro va speso in contenuti e acquisizione. Se contiene una parola che nessun altro negozio userebbe, quella parola è il progetto.

Chi lo manterrà fra due anni. È la domanda decisiva ed è organizzativa. Se in azienda nessuno sa leggere un log e non ci sarà un contratto di manutenzione, l'open source self-hosted è la scelta sbagliata anche quando è la più economica sulla carta. Se invece hai già un reparto IT o un fornitore stabile, il SaaS ti farà pagare per anni un servizio che sapresti gestire.

Con che cosa è fatto un eCommerce: linguaggi, framework e strumenti nel 2026

Prima di leggere i numeri di questa sezione serve una premessa, perché è la differenza fra usarli e farsi usare: nessuna di queste statistiche misura il fatturato. W3Techs rileva firme tecnologiche sui siti, la Stack Overflow Survey è un campione autoselezionato che lo dichiara apertamente, GitHub misura attività su GitHub e DB-Engines misura menzioni e annunci di lavoro — lo scrive nella propria metodologia. Sono ottimi indicatori di quanto sarà facile trovare persone e componenti, che è il motivo per cui contano in un progetto. Non sono classifiche di qualità.

Il lato server: PHP è ancora il fondo del mercato

Secondo W3Techs, alla rilevazione del 28 agosto 2026 il 70,2% dei siti con un linguaggio server-side riconosciuto usa PHP. Il dato più interessante è però un altro, e riguarda la manutenzione: PHP 8 copre il 63,2% delle installazioni, PHP 7 il 28,8% e PHP 5 ancora il 7,9% — oltre un terzo dei siti PHP gira su versioni che non ricevono più aggiornamenti di sicurezza. È il rischio numero uno che erediti comprando un progetto già fatto.

Su PHP, il framework di riferimento per lo sviluppo su misura è Laravel, arrivato alla versione 13 nel marzo 2026 e con una politica di supporto dichiarata di 18 mesi di correzioni e due anni di patch di sicurezza per versione. Nella Stack Overflow Developer Survey 2025 (31.771 rispondenti nella sezione tecnologie, campione autoselezionato) PHP è dichiarato dal 18,9% e Laravel dall'8,9%: sono percentuali basse rispetto al peso reale sul web, e la ragione è che quella platea è sbilanciata verso il mondo JavaScript. Per un eCommerce su misura la combinazione PHP + Laravel resta quella con il bacino di professionisti più ampio in Italia, ed è anche la strada su cui si innestano più facilmente le funzioni di intelligenza artificiale applicate al catalogo e all'assistenza.

JavaScript: il frontend, e quando serve davvero

Nella stessa survey, JavaScript è il linguaggio più dichiarato (66%), con Node.js al 48,7%, React al 44,7%, Next.js al 20,8% e Vue al 17,6%. Il State of JS 2025 (13.002 risposte, pubblicato a febbraio 2026) conferma React come il più usato, dichiarando esplicitamente il proprio bias di campione.

La traduzione per un eCommerce è semplice: un negozio tradizionale non ha bisogno di un frontend JavaScript separato, e aggiungerlo raddoppia il lavoro di manutenzione. React con Next.js diventa una scelta sensata quando la vetrina è headless, quando ci sono più canali sullo stesso catalogo o quando il negozio è anche un'applicazione. Una nota pratica sui cicli di rilascio, che in esercizio pesano: Node.js mantiene due versioni LTS alla volta e le altre escono di supporto a date fisse, mentre Next.js ha rilasciato una nuova versione maggiore nell'ottobre 2025 e aggiornamenti minori fino ad agosto 2026. Chi sceglie questa strada compra anche il ritmo di aggiornamento di questo ecosistema, che è più veloce di quello PHP.

Python: non costruisce il negozio, costruisce i dati

Python raramente è il linguaggio del negozio, ma è quello con cui si fanno le cose intorno: normalizzare i cataloghi dei fornitori, generare e validare i feed, calcolare prezzi e riordini, riconciliare gli incassi, costruire i modelli di raccomandazione. Nella Python Developers Survey di Python Software Foundation e JetBrains (oltre 30.000 rispondenti) il 49% lo usa per analisi dei dati e il 48% per sviluppo web, con machine learning al 42%.

Ricaduta. Se il tuo progetto prevede lavoro sui dati — e quasi tutti i progetti con più di mille referenze lo prevedono — è probabile che serva una competenza Python accanto a quella della piattaforma, spesso per poche giornate ma ricorrenti. Metterlo in conto all'inizio evita di scoprire dopo sei mesi che l'unico modo per aggiornare il catalogo è un pomeriggio di copia e incolla ogni settimana.

Database, code, ricerca e container

Sempre dalla survey 2025: PostgreSQL è dichiarato dal 55,6% e MySQL dal 40,5%, con Redis al 28% ed Elasticsearch al 16,7%; Docker è usato dal 71,1%, in crescita di diciassette punti in un anno. Per un eCommerce la scelta fra i due database principali raramente è decisiva — spesso la impone la piattaforma — mentre contano molto di più i due componenti che si aggiungono quando il negozio cresce: una coda per il lavoro asincrono (gli ordini verso il gestionale, le email, la generazione dei feed) e un motore di ricerca dedicato quando il catalogo supera qualche migliaio di articoli.

Le piattaforme, in numeri (e cosa quei numeri non dicono)

Nella rilevazione W3Techs sui sistemi di eCommerce, fra i siti che ne usano uno, WooCommerce pesa il 48,1% e Shopify il 31,7%, seguiti da PrestaShop (2,9%), OpenCart (1,9%), Adobe Commerce (1,5%) e BigCommerce (0,6%). WordPress da solo è rilevato sul 40,7% di tutti i siti.

Due letture opposte e entrambe sbagliate: "WooCommerce è il migliore perché è il più diffuso" e "è diffuso solo perché è gratis". La lettura utile è quanto costa trovare qualcuno che ci lavori e quante integrazioni esistono già, e su questo la diffusione conta davvero. Va detto anche cosa quei numeri non contengono: sono siti rilevati, non fatturato né transazioni, quindi non dicono nulla su quale piattaforma vende di più. E i motori headless — Medusa, Vendure, Saleor — non compaiono in nessuna rilevazione di mercato: gli unici numeri disponibili sono stelle su GitHub e download, che misurano l'interesse degli sviluppatori e non i negozi in produzione.

Gli strumenti per le valutazioni prima di vendere

Prima del lancio servono tre tipi di dato, e per ciascuno ci sono strumenti con prezzi pubblici. La domanda: Google Trends è gratuito, il Keyword Planner è incluso in Google Ads ma richiede un account con la fatturazione completata per dare volumi utili; Ahrefs parte da 29 $ al mese e sale a 1.499 $, Semrush parte da 139 $ al mese e non ha un piano gratuito permanente.

I concorrenti: gli stessi strumenti mostrano quali pagine portano traffico ai siti che ti somigliano, ed è l'analisi che orienta la struttura delle categorie meglio di qualunque riunione. Il mercato: i dati dell'Osservatorio eCommerce B2c e dei rapporti di settore, che servono a stimare la penetrazione del tuo comparto. Un avvertimento utile prima di firmare qualunque consulenza: i dati di campo sulle prestazioni esistono solo per i siti che hanno traffico sufficiente — il Chrome UX Report, che alimenta PageSpeed Insights, non copre i siti piccoli. Su un negozio nuovo si lavora con misurazioni di laboratorio finché i visitatori non bastano.

Gli strumenti dello sviluppo: cosa deve esserci nel preventivo

Tre voci vanno chieste esplicitamente, perché distinguono un lavoro professionale da uno artigianale e costano poco se previste. Il controllo di versione e un'automazione dei rilasci: GitHub Actions include 2.000 minuti al mese sui piani gratuiti, quanto basta a un negozio. Gli ambienti separati, sviluppo e prova, oggi quasi sempre in container. I test automatici: sul lato PHP gli standard sono PHPUnit e Pest, mentre per simulare un acquisto vero dal browser lo strumento diffuso è Playwright.

Non servono cento test: ne servono cinque, sul percorso che porta i soldi — ricerca, scheda prodotto, aggiunta al carrello, checkout, ordine ricevuto dal gestionale. Se girano automaticamente prima di ogni rilascio, hai eliminato la categoria di guasti più comune e più costosa, che è quella del negozio che smette di vendere senza che nessuno se ne accorga.

Fase 3 — Il budget: quello che paghi una volta e quello che paghi per sempre

Il preventivo di sviluppo si paga una volta; tutto il resto ogni mese, per anni, e cresce col fatturato. Qui interessa quanto serve per scegliere bene la piattaforma: la gestione di questi costi nel tempo è il tema della seconda parte.

I pagamenti: la voce più grande e la meno negoziata

Listini pubblicati per l'Italia, verificati alla fonte il 28 agosto 2026. Stripe: 1,5% + 0,25 € sulle carte europee standard, 2,8% + 0,25 € sulle premium, 3,15% + 0,25 € sulle carte non europee, +2% con conversione di valuta. PayPal, tariffe aggiornate al 15 luglio 2026: 3,40% + 0,35 € sulle transazioni commerciali nazionali. Satispay: 1% per pagamento e, da settembre 2026, nulla sotto i 10 € e 0,95% sopra.

Fai il conto sul tuo transato, perché la differenza è strutturale. Su 500.000 € di vendite con ticket medio di 60 € — circa 8.300 ordini — fra 1,5% + 0,25 € e 3,40% + 0,35 € ballano circa 10.300 euro all'anno, spesso più dell'intero costo di sviluppo. Non significa eliminare il metodo più caro: significa sapere che ogni metodo offerto ha un prezzo, e che la quota fissa per transazione punisce i carrelli piccoli — su un ordine da 15 euro, 0,35 € sono da soli il 2,3%.

Due avvertenze sulle fonti: le percentuali di Shopify Payments per l'Italia non sono pubblicate e Nexi non pubblica un listino eCommerce. Se una comparazione online riporta quelle cifre con tre decimali, l'autore le ha stimate.

Infrastruttura, servizi e la voce che sfora sempre

Con una soluzione self-hosted l'hosting non è una riga da 5 € al mese: come ordine di grandezza, Kinsta va da 35 $ a 375 $ al mese a seconda del traffico, e Cloudflare da gratuito a 200 $ per il piano Business. Poi ci sono i servizi che diventano necessari col catalogo: la ricerca interna (Algolia è gratis fino a 10.000 ricerche al mese, poi 0,50 $ ogni mille) e le email transazionali (Amazon SES da 0,10 $ ogni mille). Ogni servizio esterno aggiunge un canone, una dipendenza e un punto di rottura: vanno contati tutti e tre.

La voce che sfora quasi sempre non è software: fotografie, schede prodotto, traduzioni. Moltiplicare due righe di descrizione per ottocento referenze è un progetto in sé. Su un catalogo di centinaia di articoli il contenuto costa più del software e ha tempi più lunghi: va avviato in parallelo allo sviluppo, non dopo.

Fase 4 — La ricerca delle risorse: cinque mestieri, non un fornitore

"Cerco uno che mi faccia l'eCommerce" produce i preventivi meno confrontabili, perché nasconde cinque lavori diversi: chi disegna l'esperienza d'acquisto, chi scrive il codice e collega i sistemi, chi tiene in piedi pagamenti e dati, chi imposta gli strumenti di intelligenza artificiale, chi porta traffico che converte. Un freelance ne copre bene due o tre; nessuno le copre tutte e cinque, e chi dice di sì sta descrivendo la propria tolleranza al rischio.

I driver comuni a tutti e cinque sono quelli di qualunque scelta di fornitore software e li trovi nella guida su come scegliere uno sviluppatore web e app freelance: requisiti scritti prima di cercare, portafoglio verificabile su cose vive, colloquio strutturato, prova pratica breve e retribuita, contratto che assegna a te codice e account. Qui interessa cosa cambia da mestiere a mestiere.

Progettazione: il driver è la conversione, non il portfolio bello

Il lavoro si misura in ostacoli rimossi. L' aggregazione di cinquanta studi curata da Baymard colloca l'abbandono medio del carrello al 70,22% — ed è la media di ricerche altrui dal 2006 al 2025, non una rilevazione recente. Contano soprattutto i motivi dichiarati, esclusi quelli di chi stava solo guardando: costi extra troppo alti (40%), consegna lenta (20%), diffidenza sui dati della carta (19%), obbligo di registrarsi (18%), checkout lungo (17%), errori del sito (17%). Quasi nessuno è un problema grafico.

Sempre Baymard misura un checkout medio da 23,48 elementi di form contro un ottimo di 12–14. Il driver diventa concreto: chiedi al candidato di guardare un tuo concorrente e di dirti quali campi toglierebbe e perché, e se ritiene che si debba poter comprare senza registrazione. Chi risponde parlando di colori e font sta rispondendo a un'altra domanda. Chiedi anche come intende trattare l'accessibilità, che dal 2025 è un obbligo di legge.

Sviluppo e integrazione: il driver è cosa ha collegato, non quali linguaggi conosce

La parte difficile non è costruire le pagine, è far parlare i sistemi. Il driver più predittivo è: ha già integrato un gestionale, un corriere e un sistema di fatturazione, e sa raccontare cosa è andato storto? Chi l'ha fatto descrive senza esitare i casi sporchi — l'ordine che arriva mentre il magazzino è in inventario, il prodotto esaurito fra carrello e pagamento, il reso parziale, la riconciliazione degli incassi. Chi non l'ha mai fatto parla di API come di un dettaglio di configurazione.

Le domande che separano rapidamente: come gestisce gli errori di sincronizzazione (una coda con ritentativi o un cron che spera?), chi è la fonte di verità per prezzi e giacenze, cosa succede se il gestionale è spento mentre arrivano ordini, come si accorge qualcuno che la sincronizzazione è ferma da sei ore. La risposta giusta all'ultima è sempre la stessa: un allarme che arriva a una persona.

Sicurezza: il driver è la riduzione della superficie, non l'elenco degli strumenti

Un eCommerce tratta dati personali e movimenta pagamenti: due responsabilità distinte. Il profilo giusto non è chi propone più strumenti, è chi parte da cosa non deve toccare il tuo server. I dati della carta non devono mai transitare dal tuo codice, ma essere raccolti dai campi ospitati dal fornitore di pagamento: questo abbassa drasticamente l'ambito di conformità PCI e il costo di ogni verifica futura.

Le domande che separano un professionista da un venditore di antivirus: dove stanno chiavi e segreti e chi li può leggere; ogni quanto si aggiornano le dipendenze e chi se ne accorge; quando è stato provato l'ultimo ripristino da backup — non l'ultimo backup, l'ultimo ripristino; come si limita l'accesso al pannello di amministrazione. E la domanda che nessuno fa: chi riceve l'avviso alle tre di notte, con quale tempo di risposta contrattuale?

Intelligenza artificiale: il driver è il dato disponibile, non il modello

Ogni fornitore propone qualcosa con l'IA dentro, e la distinzione utile è netta: ci sono usi in cui l'IA lavora sui tuoi dati e usi in cui produce testo plausibile. I primi valgono soldi — ricerca interna che capisce le query scritte male, raccomandazioni sugli acquisti reali, classificazione di un catalogo disordinato, smistamento dell'assistenza. I secondi, come le descrizioni prodotto generate in serie e pubblicate senza revisione, producono un catalogo indistinguibile da quello di chiunque altro.

Il driver è quindi la prima domanda che il candidato fa a te: chi capisce il mestiere chiede quali dati hai e in che stato sono — storico ordini, attributi, log di ricerca interna — mentre chi non lo capisce parte dal modello. Chiedi anche come misurerà il risultato: una funzione IA senza un indicatore prima e dopo è un costo senza verifica.

Marketing online: il driver è la disponibilità a essere misurato

È il mestiere in cui è più facile vendere fumo. Il driver più efficace è banale: quali numeri si impegna a muovere, in quanto tempo, e cosa considererebbe un fallimento del proprio lavoro. Un professionista serio pone limiti — sotto una certa spesa la pubblicità non produce dati sufficienti, la SEO su un dominio nuovo ha tempi incomprimibili, senza un margine noto non si fissa un obiettivo di costo per acquisizione.

Attenzione a un'intera categoria di numeri: non esiste una fonte con metodologia dichiarata sul CPC medio italiano di Google Ads, né sul costo medio di acquisizione cliente nel retail. Google non pubblica benchmark per Paese e le cifre in circolazione vengono da campioni proprietari di agenzie, quasi sempre statunitensi. Chi te li presenta come dati di mercato o non li ha verificati o conta sul fatto che non lo farai tu.

Quanto costano queste risorse, per quel che si può dire

In Italia non esiste un barometro pubblico delle tariffe freelance per sviluppatori con metodologia verificabile. Il riferimento europeo con metodo dichiarato è il barometro Malt 2026, francese e basato su tariffe auto-riportate dagli iscritti: 576 € al giorno per sviluppatori con 8–15 anni di esperienza, 435 € nella fascia 3–7, 317 € nei primi due, con la cybersecurity a 720 €. Ordine di grandezza di un mercato vicino, non listino italiano.

L'unico dato italiano solido è indiretto: la Salary Guide 2026 di Hays indica una retribuzione media nazionale di 56.360 €. È trasversale a tutti i settori e non un dato IT, e riguarda i dipendenti: non va divisa per i giorni lavorativi per ottenere una tariffa freelance, perché il costo di un dipendente contiene contributi, ferie e malattia che nella tariffa di un autonomo sono a suo carico, insieme ai periodi non fatturati.

Fase 5 — L'integrazione con il gestionale: il punto in cui i progetti si fermano

È la fase stimata peggio, perché sembra un dettaglio tecnico ed è una decisione organizzativa: stai decidendo dove nasce ogni dato dell'azienda e chi ha il diritto di modificarlo.

Le quattro anagrafiche e chi comanda su ciascuna

Il catalogo. Il gestionale conosce i codici ma quasi mai contiene descrizioni vendibili e fotografie: nella pratica è misto — codici e prezzi dal gestionale, contenuti dal sito — ed è la configurazione più delicata, perché ogni campo va assegnato a un padrone. Senza quella assegnazione, la prima importazione massiva sovrascrive mesi di lavoro sulle schede.

Le giacenze. Comanda quasi sempre il gestionale, ma la domanda vera è con quale frequenza e con quale margine: fra una sincronizzazione e l'altra puoi vendere ciò che non hai. La soluzione è commerciale, non tecnica — una soglia sotto la quale il prodotto risulta non disponibile, decisa guardando quanto costa una cancellazione d'ordine.

I prezzi. Qui la risposta ovvia è spesso sbagliata: il prezzo online può dover essere diverso da quello di listino e le promozioni hanno regole che il gestionale non conosce. Va deciso se il sito riceve un prezzo o una base di calcolo, e chi gestisce gli sconti. Serve inoltre lo storico dei prezzi per variante, per un obbligo di legge descritto più avanti.

Ordini e clienti. Nascono sul sito e devono arrivare al gestionale con tutto ciò che serve a fatturarli: dati fiscali, codice destinatario, aliquote per Paese, spese di spedizione come riga documento. È qui che si gioca il ritorno economico dell'integrazione: ogni ordine reinserito a mano costa qualche minuto e un tasso di errore.

Quando il gestionale ha una API, e quando invece no

La differenza di costo fra i due casi è molto superiore a quella fra due piattaforme eCommerce, e va verificata prima di scegliere la piattaforma. Alcuni gestionali pubblicano documentazione aperta: SAP Business One con il Service Layer, Dynamics 365 Business Central con le API REST v2.0, Fatture in Cloud con API v2 e OpenAPI pubblica. Lì l'integrazione è un lavoro noto.

Altri hanno modelli diversi, e vanno conosciuti prima perché cambiano l'architettura: Danea Easyfatt, diffusissimo nelle piccole imprese, non espone una API REST — è il gestionale a interrogare, su richiesta o su pianificazione, un indirizzo del tuo sito che restituisce gli ordini in XML. Per Zucchetti e TeamSystem non è disponibile pubblicamente una documentazione tecnica consultabile senza credenziali: se l'accesso alle API passa da un modulo a pagamento o da un rivenditore, quel modulo e quei tempi vanno nel preventivo prima di firmare.

Sincrono, asincrono o batch: una scelta che si vede in bolletta

Batch periodico (ogni notte, ogni ora): il più semplice e robusto, perché un'esecuzione fallita si ripete senza conseguenze. Va bene per il catalogo e spesso per le giacenze; il prezzo è la latenza. Asincrono a eventi, con una coda che accumula e riprova: è la scelta corretta per gli ordini, perché il cliente conclude l'acquisto anche se il gestionale non risponde. Richiede coda, worker e monitoraggio — infrastruttura in più, da prevedere.

Sincrono, cioè il sito che interroga il gestionale in tempo reale mentre l'utente naviga, sembra elegante ed è quasi sempre la scelta peggiore: lega la disponibilità del negozio a quella di un gestionale non costruito per reggere traffico pubblico. Va riservato ai pochi casi in cui il dato in tempo reale è indispensabile — un fido, una disponibilità su commessa — e sempre con un piano B.

Una domanda sola, da porre per iscritto al fornitore del gestionale prima di firmare qualunque cosa: "quale documentazione tecnica mi date per leggere e scrivere articoli, giacenze, ordini e clienti, a quali condizioni economiche e con quale ambiente di prova?" Vale più di tutte le funzionalità elencate nelle brochure delle piattaforme.

Fase 6 — Gli obblighi di legge: requisiti tecnici, non un capitolo legale

Non sono un adempimento successivo al lancio: cambiano il modello dei dati e il disegno delle pagine. Se entrano dopo, si pagano due volte.

Accessibilità: dal 28 giugno 2025 è un obbligo

L'European Accessibility Act, recepito con il D.Lgs. 82/2022, si applica ai servizi di commercio elettronico rivolti ai consumatori dal 28 giugno 2025. Sono esenti le microimprese di servizi: meno di dieci occupati e fatturato o bilancio non superiore a due milioni. Il riferimento tecnico è la EN 301 549, che incorpora le WCAG 2.1 AA; le indicazioni AgID raccomandano di puntare alle 2.2. Sanzioni in Italia da 5.000 a 40.000 euro.

In pratica: navigazione, ricerca, identificazione e checkout devono essere usabili da tastiera e con uno screen reader, con contrasti sufficienti, etichette corrette e messaggi di errore comprensibili. Due cose false molto diffuse: non esiste alcuna proroga al 2030 per i siti, e nessun widget o overlay produce conformità. Il costo è modesto se il requisito entra in progettazione, alto se arriva a interfaccia finita.

Il catalogo: GPSR e direttiva Omnibus sono requisiti di database

Il Regolamento (UE) 2023/988 sulla sicurezza dei prodotti, applicabile dal 13 dicembre 2024, impone che l'offerta online riporti nome e indirizzo del fabbricante, i dati della persona responsabile nell'Unione se il fabbricante è extra-UE, gli elementi identificativi e le avvertenze in italiano. Sono attributi di catalogo, non testo in una pagina statica.

Dal recepimento italiano della direttiva Omnibus (D.Lgs. 26/2023), ogni annuncio di riduzione deve indicare il prezzo più basso praticato nei trenta giorni precedenti, salve le eccezioni di legge come i prodotti deperibili. Tradotto: serve lo storico prezzi per variante, con data, e serve prima della prima promozione. Se pubblichi recensioni devi dichiarare se e come verifichi che vengano da acquirenti reali.

IVA, dogana e documenti: tre cose che cambiano il carrello

Superata la soglia di 10.000 euro annui di vendite a distanza intra-UE, l'IVA si applica con l'aliquota del Paese del cliente: il carrello deve saperla calcolare e va valutato il regime OSS. Per le importazioni resta la soglia IOSS di 150 euro, ma dal 1° luglio 2026 si aggiunge un dazio forfettario di 3 euro sulle spedizioni di basso valore, calcolato per categoria merceologica presente nella spedizione e non per singolo pezzo: un pacco con tre tipologie diverse ne paga nove.

Un mito che fa spendere soldi inutilmente: il commercio elettronico indiretto — beni fisici spediti — non richiede registratore telematico né corrispettivi telematici. È esonerato da fattura e certificazione salvo richiesta del cliente, con annotazione nel registro dei corrispettivi. Serve invece raccogliere correttamente i dati di fatturazione quando la fattura è richiesta.

Consensi, pagamenti sicuri e chi non è soggetto a NIS2

Restano vigenti le linee guida del Garante sui cookie: niente scroll come consenso, rifiuto facile quanto l'accettazione. La novità che riguarda un eCommerce è il provvedimento n. 284 del 17 aprile 2026 sui pixel di tracciamento nelle email, con adeguamento entro il 29 ottobre 2026: i pixel che misurano aperture e clic richiedono consenso preventivo e revocabile. Va previsto ora nel modello dei consensi. Il Consent Mode v2, invece, è un requisito contrattuale di Google e non un obbligo di legge, e il link alla piattaforma ODR che molti template mettono ancora nel footer non serve più: è dismessa dal 20 luglio 2025.

Sui pagamenti, l'autenticazione forte è obbligatoria dal 2019 e il checkout deve supportare 3-D Secure 2.x con le sue esenzioni e i rifiuti che chiedono una nuova verifica; la PSD3 è ferma all'accordo politico dell'aprile 2026 e non è ancora legge. Sulla direttiva NIS2 circola confusione commerciale: un negozio che vende beni propri non rientra fra i soggetti obbligati — rientrano, sopra la soglia di media impresa, i fornitori di mercati online, il cloud, i data center e le CDN.

Fase 7 — Quello che va predisposto prima del lancio, perché dopo costa il doppio

Tre cose non si vedono nella prima versione di un negozio e, se non entrano ora, obbligano a rimettere le mani nel catalogo e nei template più avanti.

Il feed prodotto e i dati strutturati: si fanno una volta, nel template

La presenza nelle schede shopping di Google passa da un feed che rispetti gli attributi richiesti — identificativo, titolo, link, immagine, prezzo, descrizione, disponibilità, condizione, marca, GTIN, più taglia e colore per l'abbigliamento — e dalle informazioni su spedizione e resi. Un dettaglio tecnico che smaschera i preventivi copiati: la vecchia Content API for Shopping è stata dismessa il 18 agosto 2026 e il canale ufficiale è la Merchant API.

In parallelo, i dati strutturati sulle pagine prodotto rendono il catalogo leggibile a motori di ricerca e assistenti. Il minimo per i risultati arricchiti è ridotto — nome, immagine e un'offerta con prezzo e valuta — ma disponibilità, condizione, spedizione, politica di reso e recensioni distinguono una scheda ricca da una anonima. È lavoro da fare una volta sola, nel template.

Le prestazioni non sono un vezzo tecnico

Le soglie di Google sono pubbliche e stabili: LCP entro 2,5 secondi, INP entro 200 millisecondi, CLS sotto 0,1, misurati al 75° percentile degli utenti reali. Sull'effetto economico esistono casi documentati da Google e non stime di agenzia: nella raccolta ufficiale, Vodafone Italia ha misurato +8% di vendite a fronte di un miglioramento del 31% dell'LCP.

La ricaduta è una scelta contrattuale: i valori target vanno scritti nel contratto, misurati sui dati di campo e non su una simulazione, e verificati su catalogo pieno. Un tema carico di caroselli che passa i test con tre prodotti di prova e li fallisce con ottocento è un problema che si scopre sempre troppo tardi.

Assistenti conversazionali e commercio agentico

Se metti un assistente sul sito, l' AI Act ha reso applicabili dal 2 agosto 2026 gli obblighi di trasparenza: l'utente deve sapere che parla con un sistema automatico e i contenuti sintetici vanno marcati. Da dire con precisione, perché in rete si legge il contrario: gli obblighi sui sistemi ad alto rischio sono stati rinviati a dicembre 2027 e agosto 2028. È un requisito di interfaccia a costo quasi nullo se previsto, fastidioso se aggiunto dopo.

Sul commercio agentico — acquisti conclusi dentro un assistente — esistono protocolli pubblici: l'Agentic Commerce Protocol di OpenAI e Stripe, con licenza Apache 2.0 e ultima revisione del 17 aprile 2026, e l'AP2 di Google, alla versione 0.1. Nessuno dei due è ancora uno standard consolidato: non serve inseguirli, serve non chiudersi la porta. La preparazione utile coincide con cose che servono comunque — catalogo strutturato, feed corretto, ordini leggibili e scrivibili via API. Chi tiene prezzi e disponibilità solo dentro le pagine HTML dovrà rifare il catalogo.

Fase 8 — Il go-live: la settimana in cui si scopre cosa è stato dimenticato

Il passaggio in produzione non è un pulsante: è una sequenza, e quasi tutti i problemi del primo mese nascono da tre cose fatte in fretta l'ultimo giorno.

Le prove che contano davvero

Un ordine vero, con una carta vera, fino alla fatturazione — e al rimborso. Non un ordine in ambiente di prova: un acquisto reale di importo minimo che attraversi pagamento, autenticazione 3-D Secure, email di conferma, arrivo nel gestionale, documento fiscale, spedizione e rimborso. Il rimborso è la parte che nessuno prova e la prima che serve quando qualcosa va storto.

Un ordine sbagliato di proposito. Carta rifiutata, indirizzo incompleto, prodotto esaurito fra carrello e pagamento, gestionale spento. Il negozio deve dire qualcosa di comprensibile in tutti e quattro i casi, e nessuno deve produrre un ordine a metà — pagato e non registrato, o registrato e non pagato. È qui che si vede se l'integrazione è stata fatta con una coda o con un cron ottimista.

Se stai sostituendo un sito esistente: i redirect valgono il fatturato

È il punto in cui si perdono più soldi, ed è invisibile finché non è tardi. Ogni indirizzo che cambia va rediretto in modo permanente al nuovo corrispondente, uno a uno e non tutti alla home: una mappa di redirect fatta male costa mesi di traffico organico. Vanno verificati anche i feed già collegati agli account pubblicitari, gli account che non devono cambiare proprietario nella fretta — dominio, analisi, Merchant Center — e lo storico degli ordini, che serve per garanzie e contestazioni per almeno due anni.

Il giorno del lancio e i primi sette

La lista corta del giorno: togliere il blocco all'indicizzazione messo durante lo sviluppo — è l'errore più comune e più banale del settore; verificare che i consensi blocchino davvero e che la scelta venga ricordata; controllare che le email transazionali escano e arrivino; e sapere come si torna indietro, con una copia ripristinabile e una procedura provata almeno una volta.

Nella prima settimana servono tre presidi, assegnati a persone con nome e cognome: la verifica quotidiana che il numero di ordini sul sito e quello nel gestionale coincidano ogni sera, la lettura degli errori del server e dei pagamenti rifiutati, e la raccolta delle domande che arrivano al servizio clienti — che nella prima settimana valgono più di qualunque test di usabilità, perché dicono quali informazioni mancano dalle schede.

Ricaduta organizzativa. Il go-live sposta il progetto da una logica di consegna a una di esercizio, e il contratto deve seguirlo: da quel giorno servono un tempo di risposta dichiarato, un monte ore di manutenzione e la reperibilità per i guasti che bloccano le vendite. Va contrattualizzato prima del lancio, non dopo il primo problema — ed è il tema della seconda parte di questa guida.

I tempi: cosa determina davvero la data di lancio

I ritardi hanno quasi sempre le stesse tre cause, e nessuna riguarda la velocità di chi programma. Il catalogo: fotografie, descrizioni, attributi, traduzioni. È lavoro dell'azienda e va avviato il primo giorno; la domanda che rivela il rischio è chi scriverà le schede, quante ne scrive in un'ora e quante ore ha a settimana. Le dipendenze da terzi: contratto con il fornitore di pagamento, credenziali del corriere, accesso alle API del gestionale, ambiente di prova — attese che non si comprimono lavorando di più. Le decisioni interne: chi approva la politica di resi, chi decide le spese di spedizione, chi risponde ai clienti.

Da qui la regola che vale più di qualunque diagramma di Gantt: consegne piccole e frequenti, e data di apertura decisa in funzione del catalogo pronto, non del codice pronto. Un negozio che apre con cinquanta schede fatte bene vende più di uno che apre con ottocento schede vuote.

Come si costruisce un budget che regge

Poiché le fasce di prezzo pubblicate online non hanno fonte, l'unico modo serio è costruire la cifra. Conta i punti di integrazione — gestionale, corriere, fatturazione, pagamento, marketplace, newsletter — e chiedi per ciascuno una stima separata: sono la parte a varianza più alta. Chiedi il costo del primo anno, non del lancio: sviluppo più canoni, commissioni stimate sul fatturato previsto, manutenzione, contenuti, acquisizione. Tipicamente è due o tre volte il preventivo di sviluppo, ed è il numero su cui si decide.

Metti un accantonamento per le modifiche e chiamalo per nome: non è un imprevisto, è la certezza che dopo tre mesi di vendite vere vorrai cambiare qualcosa nel checkout e nelle spedizioni. E separa la prima fase di analisi, pagandola a parte a prezzo fisso: due settimane che producono modello dei dati, mappa delle integrazioni e disegno del checkout rendono confrontabili tutti i preventivi successivi, inclusa la possibilità di darli a qualcun altro. È la spesa con il rendimento più alto dell'intero progetto, e quasi nessuno la fa.

La scelta in pratica, per tipo di azienda

Piccola attività, catalogo limitato, nessun gestionale complesso. SaaS o WooCommerce, tema standard, poche personalizzazioni, e il risparmio investito in fotografie e contenuti. Serve un freelance solo, con competenze di progettazione e sviluppo. Il vincolo da sorvegliare è che dominio, hosting e account di pagamento siano intestati a te.

Azienda con gestionale e magazzino reale. Il progetto è l'integrazione: si parte verificando cosa espone il gestionale, si sceglie la piattaforma di conseguenza, si mettono in preventivo coda, monitoraggio e allarmi. Servono un profilo con esperienza di integrazioni e un referente interno che decida chi comanda su prezzi e giacenze.

B2B o processo di vendita particolare. Listini per cliente, fidi, preventivazione, configuratori: è il caso in cui partire da un framework generalista o da un motore headless è giustificato, con una fase di analisi separata e una prima versione ristretta a un gruppo di clienti.

Progetto che deve durare anni. Qualunque strada scegli, la differenza la fanno tre condizioni contrattuali: codice sul tuo repository dal primo giorno, account intestati alla tua azienda, e possibilità di esportare in qualunque momento catalogo, clienti e ordini in un formato leggibile da un altro fornitore. Senza queste tre righe non stai comprando un negozio: lo stai affittando senza saperlo.

Conclusioni

Se di questa prima parte dovesse restare una riga: il costo di un eCommerce non si decide scegliendo la piattaforma, si decide scegliendo quante cose devono parlarsi. Il numero di integrazioni, la loro qualità e la chiarezza su chi comanda su ciascun dato spiegano quasi tutta la differenza fra un progetto che costa il previsto e uno che raddoppia.

Sul resto: le commissioni sui pagamenti valgono in pochi anni più dello sviluppo e si scelgono una volta sola; gli obblighi europei sono requisiti tecnici e vanno nella prima versione; le fasce di prezzo che trovi in rete non hanno fonte, e l'unico budget difendibile è quello costruito contando le integrazioni sul primo anno intero. E prima di scegliere qualunque piattaforma, la domanda va fatta al fornitore del tuo gestionale. Il giorno dopo il go-live comincia un mestiere diverso, ed è quello della seconda parte.

Domande frequenti

Quanto costa sviluppare un eCommerce nel 2026?

Non esiste una risposta documentata: nessuna fonte primaria italiana o europea pubblica costi di sviluppo di un eCommerce con metodologia verificabile, e le fasce "da X a Y euro" in circolazione sono listini di venditori senza campione. Quello che si può costruire è il tuo numero: conta i punti di integrazione (gestionale, corriere, fatturazione, pagamento, marketplace) chiedendo una stima separata per ciascuno, poi somma i costi del primo anno — canoni, commissioni sui pagamenti, hosting, manutenzione, contenuti, acquisizione. Il totale è tipicamente due o tre volte il preventivo di sviluppo.

Meglio partire da zero o usare una piattaforma esistente?

La domanda che scioglie il dubbio è: quali sono le tre cose che il tuo negozio deve fare e che una piattaforma esistente non fa? Se non esistono tre risposte concrete, partire da zero è una spesa senza contropartita. Si giustifica quando il processo di vendita è il prodotto — configuratori, listini contrattualizzati, preventivazione con approvazione, noleggio, B2B con fidi — perché lì piegare una piattaforma standard costa più che scrivere il pezzo che serve. Negli altri casi il denaro rende molto di più in contenuti, integrazione e acquisizione.

Quanto incidono davvero le commissioni sui pagamenti?

Più dello sviluppo, nel giro di pochi anni. I listini pubblicati per l'Italia sono 1,5% + 0,25 € per Stripe sulle carte europee standard e 3,40% + 0,35 € per PayPal sulle transazioni nazionali, con Satispay all'1% e, da settembre 2026, gratuito sotto i 10 euro. Su 500.000 € di transato con ticket medio di 60 euro, la differenza fra le due strutture vale circa 10.300 euro l'anno. Va aggiunta la commissione che alcune piattaforme SaaS applicano se non usi il loro sistema di pagamento: su Shopify dal 2% del piano Basic allo 0,2% del Plus.

Il mio gestionale si può collegare al sito?

Quasi sempre sì, ma il come cambia il costo di un ordine di grandezza e va verificato prima di scegliere la piattaforma. Alcuni pubblicano documentazione aperta — SAP Business One con il Service Layer, Dynamics 365 Business Central con le API REST v2.0, Fatture in Cloud con API v2 e OpenAPI pubblica — e lì l'integrazione è un lavoro noto. Altri hanno modelli diversi: Danea Easyfatt non espone una API REST, è il gestionale a interrogare un indirizzo del tuo sito che restituisce gli ordini in XML. Per alcune suite italiane molto diffuse non è disponibile pubblicamente una documentazione consultabile senza credenziali: in quel caso metti a preventivo modulo, rivenditore e tempi prima di firmare.

Quali obblighi di legge riguardano un nuovo eCommerce?

Quelli che cambiano il progetto tecnico: accessibilità (obbligatoria dal 28 giugno 2025, con esenzione per le microimprese sotto i dieci occupati e i due milioni); dati del fabbricante e avvertenze nelle schede prodotto (GPSR, dal 13 dicembre 2024); prezzo più basso dei trenta giorni in ogni annuncio di sconto e trasparenza sulle recensioni (Omnibus); IVA del Paese di destinazione oltre i 10.000 euro annui intra-UE; trasparenza sull'uso di sistemi di IA dal 2 agosto 2026; consenso per i pixel nelle email entro il 29 ottobre 2026. Due cose che invece non servono: i corrispettivi telematici per la vendita di beni spediti e il link alla piattaforma ODR, dismessa dal 20 luglio 2025.

Cosa va controllato il giorno del go-live?

Cinque cose, in quest'ordine: che il blocco all'indicizzazione messo durante lo sviluppo sia stato rimosso; che un ordine vero, pagato con una carta vera, attraversi tutta la catena fino alla fattura e al rimborso; che i redirect dal vecchio sito siano attivi uno a uno e non tutti verso la home; che le email transazionali arrivino davvero; che esistano una copia ripristinabile e una procedura di ritorno indietro già provata. Nella prima settimana, il numero di ordini sul sito e quello nel gestionale devono coincidere ogni sera: è il controllo che smaschera le integrazioni fragili.

Quanto tempo serve per aprire un eCommerce?

Dipende quasi sempre da fattori non tecnici. Le tre cause ricorrenti di ritardo sono il catalogo (fotografie, descrizioni, attributi, traduzioni: è lavoro dell'azienda e va avviato il primo giorno), le attese da terzi (contratto con il fornitore di pagamento, credenziali del corriere, accesso alle API del gestionale) e le decisioni interne mai assegnate a nessuno, come la politica di resi. La regola pratica è fissare la data in funzione del catalogo pronto e non del codice pronto.

Quante persone servono per fare un eCommerce?

I mestieri sono cinque — progettazione, sviluppo e integrazione, sicurezza, intelligenza artificiale, marketing — e un freelance ne copre bene due o tre. Su un progetto piccolo una persona basta, purché sia chiaro cosa non farà: di solito l'acquisizione e la manutenzione di sicurezza. Con gestionale e magazzino servono almeno due profili distinti, più un referente interno che possa decidere. Il segnale d'allarme è il fornitore che dichiara di coprire tutte e cinque le aree con la stessa competenza.