Comprare la piattaforma wholesale o costruirla: i criteri che decidono davvero, dai listini alla fonte di verità al costo che cresce col successo.
Comprare o costruire. La domanda arriva sempre in questa forma, e in questa forma non ha risposta. Un portale B2B non è un prodotto con un capitolato standard: è il tuo modo di vendere all'ingrosso messo dentro un software. E quel modo è pieno di eccezioni che nessuno ha mai scritto da nessuna parte.
Gli errori che si ripetono in questi progetti li abbiamo già raccontati: riguardano i dati e le regole commerciali, quasi mai il codice. Qui parliamo di quello che viene prima, cioè come si decide. Lato consumatore la stessa scelta ha criteri diversi, e l'abbiamo affrontata in Shopify o su misura.
Un SaaS non è un contenitore vuoto: è un insieme di decisioni già prese da altri. Quanti livelli può avere un listino, cosa succede a un ordine dopo la conferma, chi può ordinare per conto di chi. Sono decisioni ragionevoli, prese guardando molte aziende prima della tua. Quando somigliano alle tue il vantaggio è grosso, perché qualcuno ha già risolto problemi che tu non vedi e continuerà a risolverli. Quando non somigliano, non compri una libertà ridotta: compri un aggiramento che non finisce più.
È qui che i SaaS si rompono per primi. Non sul catalogo, non sull'estetica, non sui volumi: sul prezzo. Ogni piattaforma pronta ha il proprio modello di prezzo B2B: listini assegnabili a gruppi di clienti, qualche scaglione per quantità, uno sconto per categoria. Se il tuo commerciale funziona così, hai finito prima di cominciare: prendi il pronto e metti i soldi altrove.
La verifica si fa con carta e penna. Prendi i clienti più complicati che hai, non quelli medi, ed elenca tutto ciò che determina il prezzo di una riga d'ordine: sconti in cascata, condizioni riservate su singoli articoli, scaglioni che cambiano per marca, promozioni a tempo che convivono con lo sconto di listino, prezzi congelati da un accordo annuale. Poi metti tre colonne: lo regge nativamente, lo regge con una configurazione contorta, non lo regge.
A decidere è la terza colonna. Una regola che il prodotto non prevede non resta un buco: diventa un foglio di calcolo tenuto a mano, una telefonata al commerciale, o un software scritto a parte che dovrà restare d'accordo con la piattaforma per sempre. Tre esiti, tutti con un costo ricorrente che nessuno ha messo a preventivo. Lo stesso esercizio vale per fido, scaduto e condizioni di pagamento: chiedi cosa fa il sistema quando ordina un cliente bloccato.
Prima di confrontare i candidati, decidi da che parte sta la verità. Se anagrafiche, articoli, listini e giacenze nascono nel gestionale e il portale li legge per produrre ordini, il portale è un satellite: è il ruolo che un SaaS interpreta meglio. Se invece deve calcolare cose che il gestionale non sa calcolare, o diventare il posto in cui lavora la rete commerciale, il baricentro si sposta altrove.
Attenzione alla risposta che sembra chiudere il discorso: tanto ha le API. Tutti hanno le API. La domanda è se espongono il pezzo che ti serve nel momento in cui ti serve. Quasi tutti ti lasciano leggere e scrivere dati; pochissimi ti lasciano entrare nel mezzo delle proprie decisioni. Se devi intervenire mentre il prezzo viene calcolato, e quel punto non è previsto, ti resta solo correggere dopo.
Il flusso standard è catalogo, carrello, conferma, trasmissione al gestionale. Quasi nessun settore si ferma lì.
Disegna il tuo flusso reale prima di guardare qualunque demo, poi chiedi di percorrerlo davanti a te, dal primo clic al documento trasmesso. Non a parole: sullo schermo, con i tuoi casi.
Il numero di utenti conta meno di come si comportano. Mille buyer che ordinano in momenti diversi sono un carico tranquillo. Poche decine che entrano tutte lo stesso giorno, all'apertura della campagna, contendendosi la stessa merce, sono un problema diverso: lì si decide chi prende l'ultimo pezzo, e si decide bene solo se il sistema è stato progettato per farlo. La disponibilità si impegna al carrello o alla conferma? Un SaaS con molti clienti alle spalle questo caso lo ha già attraversato; un su misura lo affronta se glielo chiedi.
È il criterio che decide più progetti di quanto si ammetta, e quasi nessuno lo mette in tabella. Un portale su misura è codice vivo: dipendenze da aggiornare, un ambiente da presidiare, backup da verificare davvero, qualcuno che risponde quando le sincronizzazioni si accumulano. Senza una persona tecnica interna o un rapporto continuativo con chi l'ha costruito, è la scelta sbagliata anche quando è quella tecnicamente giusta. Con un SaaS quel rischio lo deleghi, in cambio di un canone e di meno margine di manovra.
I due modelli non hanno solo prezzi diversi, hanno forme diverse. Il su misura concentra la spesa all'inizio e lascia un ricorrente prevedibile, che cresce con la complessità e non con il fatturato.
Il SaaS ribalta la curva. Parti con poco e paghi per sempre, ma soprattutto paghi in proporzione a qualcosa: utenti, aziende collegate, volume transato, talvolta ordini. In fase di scelta sembra un dettaglio contrattuale; a regime cambia l'aritmetica, perché il canone sale esattamente quando il progetto funziona: ogni cliente che convinci a usare il portale è una riga in più sulla fattura del fornitore.
Quindi chiedi quale variabile fa salire il prezzo, e simula lo scenario di successo invece di quello di oggi. Vale per ogni preventivo digitale: il confronto si fa sull'arco di qualche anno, perché le voci che spostano il totale sono quelle che nessuno guarda.
Un vincolo ci sarà comunque: cambia soltanto a chi sei legato.
La domanda non è se resterai vincolato, ma se preferisci dipendere da un'azienda che non conosci o da un fornitore che hai scelto tu.
Con il SaaS chiediti cosa esce, il giorno in cui volessi uscire. I dati escono quasi sempre. Le regole no: listini, gerarchie di sconto, permessi e automazioni vivono dentro la piattaforma in un formato che non serve a nient'altro. È l'investimento invisibile, ed è il vincolo vero — non perdi dei file, perdi tutto il lavoro di configurazione che ci hai messo dentro.
Con il su misura la domanda si rovescia: il codice è intestato a te, sta in un repository di cui hai le chiavi, lo prenderebbe in mano un altro fornitore senza riscriverlo? Un codice che conosce una persona sola è un vincolo con meno garanzie.
Una piattaforma pronta ti mette davanti qualcosa di funzionante mentre stai ancora decidendo, e serve a scoprire in fretta se i tuoi clienti il portale lo useranno: il rischio più concreto qui non è tecnico, è che i buyer abituati al telefono continuino con il telefono. Il su misura chiede di decidere quasi tutto prima e paga il conto dei ripensamenti: ha senso quando l'azienda sa già come vende. Nel conto va messo anche il tempo in cui il portale non esiste, cioè le ore spese a trascrivere ordini arrivati via mail.
C'è una terza opzione, e per molte aziende è la migliore: piattaforma pronta per il commercio standard, sviluppo su misura per la parte peculiare. Lasci al prodotto catalogo, accessi, carrello, checkout e infrastruttura, e sposti fuori quello che non sa fare: un servizio che calcola i prezzi secondo le tue regole, un componente intermedio per le sincronizzazioni col gestionale, uno strumento per la rete agenti.
Funziona a una condizione: che la parte peculiare si possa recintare. Scrivila, voce per voce. Se sta in mezza pagina hai un ibrido sano, e paghi sviluppo solo per ciò che ti distingue. Se occupa tre pagine e tocca ogni schermata, la piattaforma ti sta prestando un login: il resto lo costruisci comunque, con più fornitori e più punti di rottura.
La seconda condizione è che il candidato ti lasci entrare nel punto giusto: un prodotto che permette di sostituire il calcolo del prezzo rende l'ibrido possibile, uno che espone soltanto l'esportazione degli ordini a cose fatte no.
Laravel per il dominio e le integrazioni, Next.js per l'interfaccia: è la combinazione con cui lavoriamo su questo tipo di progetti. Ma è la parte meno interessante del confronto. Un portale B2B raramente fallisce per il framework: fallisce quando non è stato deciso chi stabilisce il prezzo, o quando la rete agenti entra nel perimetro a sviluppo avviato. Se il SaaS ti sembra stretto ma non sai spiegare dove, non sei pronto a costruire: sei pronto per l'analisi che viene prima, la fase iniziale di ogni sviluppo software su misura, che è commerciale, non tecnica.
Se all'ultima domanda rispondi in mezza pagina, l'ibrido è probabilmente la tua strada. Se la risposta è lunga e sfumata, stai per costruire un software.
La scelta non si fa confrontando elenchi di funzionalità, si fa confrontando attriti. Una piattaforma che copre gran parte del tuo commercio e ti lascia gestire a mano il resto va benissimo, se quel resto è fatto di casi rari. Se invece è il modo in cui lavorano i clienti più grandi, quel resto non è un'eccezione: è l'azienda.
Il su misura non è un premio che si vince crescendo: serve quando le regole che ti fanno guadagnare non stanno dentro il modello di nessun altro. Finché ci stanno, costruirle da zero è un modo costoso per riavere ciò che potevi affittare.
Se sei nel dubbio, la cosa utile non è guardare un'altra demo: è mettere sul tavolo listini, flusso d'ordine e gestionale, e farli leggere a chi conosce entrambe le strade. Raccontaci come vendi all'ingrosso: la prima call serve a capire se ti serve una piattaforma o un software.
Parliamone. Una prima call di misurazione è sempre gratuita.
Prenota una call