Quando costruire strumenti interni su misura invece di comprare SaaS

Quando il SaaS standard resta la scelta giusta

Il SaaS vince quando il problema è standardizzato, la roadmap del vendor copre il tuo orizzonte e il vantaggio competitivo non vive dentro quel flusso. Contabilità, email, CRM generico in fase early e processi HR standard sono esempi classici: costi operativi, patch di sicurezza e velocità feature sono esternalizzati. Se serve andare live in settimane, non mesi, il SaaS vince, accettando i limiti di configurazione. L'errore non è scegliere SaaS; è pensare che assorbirà per sempre i casi limite. I casi limite si accumulano: approvazioni diverse per business unit, logica magazzino legata a macchine in produzione, regole prezzo che cambiano ogni trimestre. Quando diventano eccezioni quotidiane gestite su Excel, stai già pagando uno strato custom, solo che non lo hai ancora chiamato così.

• Processo standard, poca differenziazione, time-to-value rapido
• API del vendor sufficienti per reporting, non per operatività core
• IT interno scarso: meglio integrare che costruire prodotto
• Requisiti normativi coperti da SaaS certificato con poca customizzazione

Quando servono strumenti interni su misura

Il software interno su misura serve quando il flusso operativo è il prodotto del tuo business, not un effetto collaterale. Da progetti reali: piattaforme di autorizzazione bancaria con evidenze e approvatori diversi per tipo richiesta; console per vending e ricarica EV con eventi hardware, pagamenti e diagnostica remota; SaaS di lead generation dove scoring e regole di outreach sono il vantaggio competitivo. Forzare questi processi in SaaS generico significa workaround: database ombra, export CSV, riconciliazioni manuali, catene Zapier fragili. Il costo operativo si vede in headcount, errori e cicli decisionali lenti, not in una riga 'software'. Un tool interno unifica il flusso, applica permessi corretti e fa evolvere le regole senza attendere la roadmap del vendor.

Un altro trigger è la profondità delle integrazioni. Se dieci SaaS tengono ciascuno un pezzo della verità, il team umano diventa l'integrazione. Un tool interno focalizzato può orchestrare il lavoro quotidiano sopra ERP, CRM o data warehouse, lasciando al SaaS ciò che è commodity. Comprare commodity e costruire il differenziatore è spesso il massimo ROI per operatori B2B.

I costi nascosti dell'accumulo di SaaS

Le licenze sono il costo visibile. Quelli nascosti sono sovrapposizione, cambio contesto e deriva dati. Tre tool con anagrafiche clienti diverse; operatori che saltano tra ticketing, fogli e chat per chiudere un caso; export notturni che non tornano e dashboard non fidate finché qualcuno corregge a mano. Sicurezza e compliance crescono con ogni vendor: DPA, revisioni accessi, SSO, playbook incidenti. Per aziende UE la responsabilità GDPR resta tua anche se il vendor hosta la UI. Contesti industriali e finanziari aggiungono log, audit trail e segregazione funzioni che il SaaS generico offre solo a tier enterprise non sempre necessari ovunque. Prima di un nuovo abbonamento chiediti: questo tool riduce i passaggi totali o ne aggiunge uno? Se la risposta si ripete tra reparti, consolidare in un tool interno spesso ripaga entro un anno, prima ancora della flessibilità strategica.

Framework pratico build vs buy

Usa sei dimensioni: unicità del flusso, frequenza cambiamenti, complessità integrazioni, sensibilità dati, urgenza temporale, capacità interna. Voto 1–5 per ciascuna. Unicità + integrazioni alti → lean custom. Urgenza alta e unicità bassa → lean SaaS. La frequenza conta: i vendor ottimizzano per il cliente mediano. Se le regole cambiano ogni mese per operatività o normativa, combatti i loro release cycle. La sensibilità dati conta con ruoli granulari, componenti on-prem o segmenti isolati, tipico in banking e IoT industriale. La capacità interna è spesso fraintesa: non serve un team enorme, serve un owner chiaro delle priorità e un partner che consegni codice da produzione. Molti tool interni vivono con un product owner interno e contractor iterativo, puoi prenotare una call breve per validare le assunzioni sul tuo caso.

• Unicità: il flusso definisce come vinci sul mercato?
• Integrazioni: più di tre sistemi di record critici?
• Audit: servono log immutabili e approvazioni per ruolo?
• Volume: centinaia di item/giorno in questo processo?
• Orizzonte: processo attivo per 5+ anni?

Come definire un MVP senza scope infinito

Gli MVP falliscono replicando ogni schermata legacy. Quelli che funzionano scelgono un loop operativo e lo rendono affidabile: intake → decisione → esito → audit. Per approvazioni: un tipo richiesta con notifiche email e audit read-only. Per una console operativa: stato live dispositivi e intervento manuale, not manutenzione predittiva completa. Definisci subito i requisiti non funzionali: auth (SSO?), ruoli, logging, backup, ambienti. Spesso pesano più dei pulsanti UI. Per il budget, incrocia questa sezione con la guida sui costi di sviluppo software per separare feature commodity da lavoro compliance-heavy. Consegna milestone ogni 2–4 settimane con demo usabili. Gli operatori dovrebbero usare la milestone 2 in produzione su un caso stretto, anche se la 5 non esiste. Il feedback da produzione batte i workshop.

Documenta la proprietà dei dati: quale sistema è fonte per clienti, asset, ordini, utenti. Il tool interno dovrebbe referenziare ID di record, non duplicare master data salvo necessità. Riduce rischio migrazione e costo integrazioni future.

Architettura e operatività che reggono il secondo anno

I tool interni spesso partono come CRUD e collassano su permessi, reporting e job asincroni. Pianifica: accessi a livello riga dove serve; job per import e notifiche; osservabilità (log strutturati, error tracking); superficie admin per supporto. Scegli stack manutenibili: TypeScript con React o Next.js, API mainstream (Node, .NET o Python secondo competenze), database adatto al reporting (PostgreSQL è un default solido). Code o stream solo se il throughput giorno uno lo impone, not come esercizio architetturale prematuro. Vercel, AWS o Azure contano meno di CI/CD e ambienti separati. Documentazione e runbook contano quando ruotano i contractor. Se ingaggi esterni, pretendi accesso repo, diagrammi infrastruttura e aspettative on-call scritte.

Lavorare con un contractor su tool interni

Il contractor funziona quando il business possiede priorità e criteri di accettazione e l'engineering possiede qualità implementativa. Evita RFP con centinaia di feature senza ranking. Preferisci discovery breve (1–2 settimane) con user flow, modello dati logico e roadmap con non-goal espliciti. Valuta su evidenze di produzione: sistemi rimasti su, migrazioni completate, integrazioni mantenute, not slide. Chiedi come gestiscono cambi senza erodere l'architettura. Chiedi review e test. Per enterprise e industriale chiedi WCAG, audit log o esperienza hardware, come in esperienza professionale. Contratto: milestone fisse per discovery e MVP, poi T&M o sprint per evoluzione. IP: tipicamente il codice su misura è tuo; librerie riusabili del contractor solo se dichiarate upfront.

Il ritmo di comunicazione batte la moda tech. Review settimanale di 30 minuti con operatori evita deriva. Accesso diretto a chi implementa riduce il telefono senza fili. Se il tool è business-critical, pianifica knowledge transfer dal giorno uno, not un PDF a fine progetto.

Prossimi passi se stai propendendo per un build

Riassumi il flusso in una pagina: attori, input, decisioni, output, sistemi coinvolti. Segna i pain point che costano tempo ogni settimana. Applica lo scorecard con onestà. Se il custom convince, budgetta discovery + MVP prima di roadmap multi-trimestre. Sfoglia altre risorse, oppure invia un messaggio con contesto, settore, team, sistemi, tempistiche. Diagrammi o Loom, anche grezzi, accelerano la valutazione di fattibilità più di 'ci serve un'app' generico.

Domande frequenti