Quanto costa un progetto Blazor Server: le voci che pesano davvero

Il costo di un progetto Blazor Server dipende più dalla complessità dell'interattività richiesta (quanti stati condivisi, quanta logica realtime) che dal numero di pagine — due progetti con lo stesso numero di schermate possono costare cifre molto diverse se uno è essenzialmente form e liste, l'altro dashboard con aggiornamenti live e più utenti che agiscono sullo stesso dato in contemporanea. Non esiste un prezzo "a pagina" affidabile per questo motivo: chi lo propone sta semplificando una variabile che semplificata non dovrebbe essere.

Perché Blazor Server ha un profilo di costo diverso da altri framework

Blazor Server tiene lo stato dell'interfaccia sul server e comunica con il browser via SignalR — questo significa che ogni interazione (un click, una validazione, un aggiornamento di stato) è un round-trip di rete, non un ricalcolo locale nel browser come in una SPA tradizionale (React, Angular, Blazor WebAssembly). Le conseguenze sul costo sono concrete, non solo teoriche:

Le voci che pesano di più, in ordine tipico

Non in termini assoluti (variano troppo da progetto a progetto per dare cifre affidabili), ma in ordine di impatto relativo:

I sovracosti nascosti a cui prestare attenzione

Sono la parte che un preventivo scritto in fretta tende a lasciare fuori, e che poi genera le famose "richieste di modifica extra" che gonfiano il budget a metà progetto:

Come farsi un preventivo più realistico

Prima di chiedere (o dare) un numero secco, tre domande che valgono più di qualsiasi tabella prezzi:

Domande frequenti

Blazor Server costa di più o di meno di una SPA React/Angular a parità di funzionalità? Dipende dal profilo del progetto, non c'è una regola generale valida sempre. Blazor Server riduce il lavoro di duplicazione della logica (niente API REST separata da scrivere e mantenere se il backend è già .NET), ma introduce i costi di gestione del circuito realtime descritti sopra. Un progetto con poca interattività e molta logica di dominio condivisa tende a costare meno in Blazor Server; un progetto che deve funzionare bene anche offline o con latenza di rete alta tende a essere più semplice (e quindi più economico) in un'architettura client-side.

Un progetto Blazor Server "semplice" può davvero costare poco? Sì, se è davvero semplice: poche pagine, un solo ruolo utente, nessuna integrazione esterna complessa, traffico contenuto. Il problema è che "semplice" viene spesso dichiarato all'inizio e poi si scopre non esserlo strada facendo — da qui l'importanza di essere specifici sullo scope fin dal preventivo, non genericamente ottimisti.

Conviene chiedere un preventivo a corpo (prezzo fisso) o a consumo (a ore)? A corpo ha senso solo se lo scope è davvero chiuso e ben definito — altrimenti il rischio si sposta tutto sul fornitore, che tenderà a proteggersi con un margine più alto o con uno scope scritto in modo molto rigido. A consumo è più onesto quando il progetto è ancora da esplorare, ma richiede fiducia reciproca e un referente che segua l'avanzamento, non un assegno in bianco.

Cosa succede se a metà progetto emerge che serve più interattività realtime del previsto? È uno scenario comune, non un'anomalia — motivo in più per discutere fin dal preventivo iniziale come vengono gestite le richieste di modifica in corsa (change request), invece di scoprirlo nel momento peggiore, cioè quando succede davvero.