Quanto costa davvero una piattaforma Node.js personalizzata: sviluppo, lancio e tre anni di gestione

Le hanno presentato un preventivo per realizzare una piattaforma personalizzata. È una cifra importante e sta cercando di capire se sia corretta. La risposta, poco piacevole, è che il costo di realizzazione — chiunque l'abbia stimato — rappresenta circa la metà di quanto la piattaforma Le costerà in tre anni, e la parte mancante non è nascosta. Semplicemente, non rientra in uno statement of work.

Questo è il modello che utilizziamo quando un cliente ci chiede di aiutarlo a pianificare il budget in modo completo, anche per attività che potrebbe non affidarci.

Anno Zero: la fase di sviluppo

La cifra visibile. Di solito si scompone in modo più prevedibile di quanto i merchant si aspettino:

• Analisi e architettura: 8–12% del costo di realizzazione. Risparmiare qui è il modo più sicuro per spendere di più in seguito.
• Applicazione principale: 40–50%. Le funzionalità previste dal brief.
• Integrazioni: 15–30%. Quasi sempre sottovalutate — veda sotto.
• Lavoro non funzionale: 10–20%. Autenticazione, permessi, rate limiting, gestione file, email transazionali, logging, gestione errori. Invisibile in demo, essenziale in produzione.
• Testing e rafforzamento: 8–15%.
• Deployment e configurazione infrastruttura: 5–10%.

Per una piattaforma realmente personalizzata con integrazioni effettive, il costo realistico si colloca tra £120.000 e £450.000. Sotto circa £80.000 si acquista un MVP, che può avere senso purché sia chiaro a tutti.

Perché le integrazioni fanno saltare la stima

Integrare con l’ERP è una riga nel brief e da tre a otto settimane di lavoro. La variabilità dipende da fattori che nessuno può conoscere in fase di preventivo: se l’API è documentata, se esiste una sandbox, se i rate limit del fornitore sono compatibili con il suo volume, se il modello dati è compatibile e se la persona che conosce il sistema lavora ancora lì.

Valuti le integrazioni come intervallo, con un’ipotesi dichiarata per ciascuna, e aggiorni il prezzo dopo una spike tecnica. Un’integrazione quotata a prezzo fisso senza aver visto l’API è una stima travestita da certezza.

Anno Uno: lancio e stabilizzazione

L’anno che molti budget considerano manutenzione ma che di fatto non lo è.

• Stabilizzazione post-lancio: 15–25% del costo di realizzazione. Gli utenti reali trovano sempre ciò che il testing non ha rilevato.
• Infrastruttura: £500–£5.000/mese a seconda di scala e ridondanza.
• Servizi terzi: monitoraggio, error tracking, invio email, ricerca, autenticazione. £200–£2.000/mese, con crescita silenziosa.
• Il backlog delle modifiche: tutto ciò che l’azienda desiderava ma ha deciso di rimandare. Preveda 20–35% del costo di realizzazione per il primo anno, oppure rischia che la piattaforma si blocchi il giorno stesso del lancio.

Anni Due e Tre: gestione diretta

Qui il software personalizzato si distingue radicalmente da quello con licenza, ed è il punto in cui la maggior parte dei business plan smette di fare previsioni.

Manutenzione delle dipendenze

Un’applicazione Node.js ha una catena di dipendenze ampia e in continuo movimento. Il ciclo di rilascio di Node prevede la dismissione programmata delle versioni; framework e librerie introducono breaking change; le segnalazioni di sicurezza arrivano indipendentemente dalla sua capacità di gestirle.

Preveda 5–10% del costo di realizzazione ogni anno solo per restare aggiornato. Saltare questa voce non è un risparmio — è un debito che si paga tutto insieme, di solito quando una vulnerabilità rende urgente l’aggiornamento e la catena di versioni da colmare è lunga cinque major release.

Operatività e reperibilità

Qualcuno risponde quando si rompe alle 3 di notte. È un servizio che ha un costo, e il costo varia di un ordine di grandezza a seconda delle reali esigenze:

• Orario lavorativo, best effort: £1.500–£4.000/mese
• Orario esteso con SLA di risposta: £4.000–£10.000/mese
• Vero 24/7 con turnazione: £10.000+/mese, perché servono abbastanza persone per rendere il turno sostenibile

Valuti onestamente ciò di cui ha bisogno. Acquistare il 24/7 per una piattaforma con utenti in un solo fuso orario è uno spreco; scegliere solo orario lavorativo per un sistema che gestisce ordini notturni è un risparmio apparente che si rivelerà nel modo peggiore.

Sviluppo continuo

Una piattaforma che non evolve è una piattaforma superata. La maggior parte dei progetti personalizzati di successo richiede 15–30% del costo iniziale ogni anno in sviluppo continuativo. Non è un limite dello scope iniziale; è la realtà della proprietà del software.

Rischio legato alle persone chiave

La voce più difficile da quantificare e la più facile da ignorare. Se una sola persona conosce la piattaforma, si trova di fronte a un rischio, non a un asset. Ridurlo — documentazione, affiancamento, un secondo tecnico che conosca davvero il sistema — ha un costo, ma è inferiore all’alternativa. Lo consideri esplicitamente, oppure lo pagherà a sorpresa.

La prospettiva a tre anni

Prenda un progetto da £200.000. Un totale realistico su tre anni, con roadmap moderata e supporto in orario lavorativo, si attesta intorno a £520.000–£700.000 includendo stabilizzazione, infrastruttura, manutenzione delle dipendenze, operations e sviluppo continuativo.

Non è un argomento contro la realizzazione. È il dato da confrontare con le alternative, che è il senso dell’analisi.

Quando non conviene sviluppare

Rifiutiamo regolarmente richieste di sviluppo personalizzato, e questi sono i motivi:

• Un prodotto configurabile copre l’80% delle esigenze. Il restante 20% quasi mai giustifica la gestione completa e perpetua della soluzione.
• Nessuno in azienda può farsene carico. Un software personalizzato senza un referente interno diventa rapidamente un rischio non gestito, indipendentemente dalla qualità della realizzazione.
• I requisiti sono ancora in evoluzione. Se sviluppa su un target mobile, pagherà per rifarlo. Prototipi prima su una soluzione economica.
• Il totale a tre anni supera il valore generato. Faccia questi conti prima di iniziare, non durante il secondo anno.
• Non è il suo elemento distintivo. Sviluppi ciò che genera valore; acquisti ciò che serve a tutti.

Il motivo più solido per sviluppare è l’opposto: il software è il business, oppure rappresenta un vantaggio competitivo che nessuno offre come prodotto standard. È il caso sia della piattaforma SaaS di Hotelogix sia di Dad.Live: in entrambi i casi il prodotto coincideva con il core business, non era un supporto.

Domande da porre su ogni preventivo

1. Cosa è escluso? La domanda più utile che possa porre, e la risposta rivela l’esperienza del team.
2. Per quali integrazioni avete effettivamente visionato l’API? Tutto ciò che non è stato visto è una stima, non un prezzo.
3. Cosa comprende il passaggio di consegne — documentazione, runbook, decisioni architetturali, ambiente locale funzionante per un nuovo tecnico?
4. Chi possiede codice, repository, account cloud e domini? Lo chieda prima di firmare, non quando vuole cambiare fornitore.
5. Qual è il modello di supporto dopo il lancio e quanto costa?
6. Cosa realizzerebbe in modo diverso se il budget fosse inferiore del 30%? La risposta rivela cosa considera indispensabile.

Se desidera un modello triennale costruito sui Suoi requisiti, il nostro team Node.js e full-stack svolge questa attività prima dell’avvio del progetto, non durante. La nostra pratica di sviluppo full-stack copre gli aspetti di gestione che il preventivo di realizzazione non include.

Modellare prima di impegnarsi

Ci invii il brief e costruiremo il quadro triennale — anche nei casi in cui la raccomandazione onesta sia acquistare una soluzione già esistente. Contatti il nostro team; rispondiamo entro un giorno lavorativo.