01 - Indie maker italiano: stack completo 2027

Quanto costa tenere in piedi un prodotto digitale da solo

Chi comincia un prodotto digitale da solo si fa quasi sempre la domanda sbagliata: quale framework scelgo? La domanda che decide se il progetto sopravvive è un'altra: quanto devo incassare ogni mese perché il progetto non mi costi soldi e sera dopo sera? Con un server piccolo la risposta sull'infrastruttura è sorprendentemente bassa, e il resto del costo è il tuo tempo, le tasse e il supporto. Questo articolo apre la serie e mette in fila le scelte tecniche con questo criterio, rimandando agli articoli successivi per fisco, pagamenti, marketing e assistenza.

La risposta breve: un server virtuale sufficiente per un'applicazione web con database parte, sul listino ufficiale consultato il 2026-11-13, da 5,49 euro al mese IVA esclusa (piano «Regular Performance» di Hetzner Cloud, indicato come «a partire da»). Una commissione di incasso con carta standard dello Spazio economico europeo costa, sul listino italiano di Stripe, 1,5% più 0,25 euro a transazione. Con queste due cifre il pareggio dell'infrastruttura si raggiunge con pochissimi clienti; l'obiettivo vero è un altro, e lo calcoliamo sotto.

Come scegliere lo stack quando lavori da solo

Uno stack, per chi lavora da solo, è un debito di manutenzione che pagherai nei weekend. Per questo i criteri contano più dei nomi: ogni tecnologia in più è un aggiornamento di sicurezza in più, un modo in più di rompersi alle due di notte e una cosa in più da spiegare a chi ti sostituirà o ti aiuterà. Prima di leggere i nomi, guarda i cinque criteri con cui li ho scelti.

• La conosci già. Il tempo di apprendimento è un costo che il prodotto non rimborsa.
• Esiste da anni e ha documentazione ufficiale aggiornata. Così i problemi sono già stati incontrati da altri.
• Gira su un solo server. Niente orchestratori finché un server basta.
• Si riavvia da sola. Se il processo muore, il sistema operativo lo rialza.
• Si può sostituire pezzo per pezzo. Database, applicazione e web server restano separati.

I criteri sono in ordine di importanza, non di comodità: il primo da solo basta a scartare metà dei consigli che leggi online. Se conosci Python e non hai mai toccato Java, un backend Spring Boot ti fa perdere mesi, per quanto sia un ottimo framework. Se invece vieni dal mondo Java e il tuo prodotto è un gestionale, restare su Java è la scelta competente. L'ultimo criterio protegge il futuro: tenere database, applicazione e web server come tre pezzi distinti ti permette di spostare solo quello che cresce.

Lo stack che l'autore usa davvero, e perché non è una ricetta

Per trasparenza: il sito su cui stai leggendo gira con Angular in rendering lato server, Spring Boot su Java 21, PostgreSQL, Redis e nginx come reverse proxy, su un server virtuale Hetzner. È uno stack che l'autore conosceva prima di costruirlo; non è un consiglio universale. Se il tuo prodotto è un sito di contenuti, un generatore di pagine statiche con un solo processo è più semplice e più sicuro. Se è uno strumento con account e pagamenti, serve un backend: scegli quello che sai riparare da solo.

Il punto di pareggio, calcolato

Un pareggio calcolato sul foglio è un'idea; un pareggio calcolato da un programma che puoi rieseguire con i tuoi numeri è uno strumento. Lo script seguente usa tre costanti documentate (prezzo del server, percentuale e quota fissa di Stripe) e due ipotesi dichiarate: il dominio e l'obiettivo mensile. La funzione netto_per_abbonato sottrae la commissione al prezzo; math.ceil arrotonda sempre per eccesso, perché un cliente a metà non paga. Le cifre sono prima delle tasse e della tua contribuzione, che trovi negli articoli 3 e 4.

# Punto di pareggio mensile di un piccolo SaaS con un solo server.
# Le tre costanti vengono da pagine ufficiali consultate il 2026-11-13;
# dominio e obiettivo sono IPOTESI: sostituiscile con le tue.
import math

SERVER_MESE = 5.49          # Hetzner, piano "Regular Performance", da, IVA esclusa
DOMINIO_ANNO = 12.00        # ipotesi del lettore, non una fonte
STRIPE_PERCENTUALE = 0.015  # carte standard SEE, listino Stripe Italia
STRIPE_FISSO = 0.25         # euro per transazione riuscita
OBIETTIVO_NETTO = 1000.00   # ipotesi: euro al mese dopo le commissioni, prima delle tasse

costo_fisso = SERVER_MESE + DOMINIO_ANNO / 12

def netto_per_abbonato(prezzo):
    """Quanto resta di un pagamento mensile dopo la commissione Stripe."""
    return prezzo - (prezzo * STRIPE_PERCENTUALE + STRIPE_FISSO)

print(f"costo fisso mensile: {costo_fisso:.2f} EUR")
for prezzo in (3, 9, 19):
    netto = netto_per_abbonato(prezzo)
    pareggio = math.ceil(costo_fisso / netto)
    obiettivo = math.ceil((OBIETTIVO_NETTO + costo_fisso) / netto)
    print(f"{prezzo:>2} EUR: netto {netto:5.2f} | pareggio {pareggio} abbonati | {OBIETTIVO_NETTO:.0f} EUR/mese a {obiettivo} abbonati")

# Output:
# costo fisso mensile: 6.49 EUR
#  3 EUR: netto  2.71 | pareggio 3 abbonati | 1000 EUR/mese a 373 abbonati
#  9 EUR: netto  8.62 | pareggio 1 abbonati | 1000 EUR/mese a 117 abbonati
# 19 EUR: netto 18.46 | pareggio 1 abbonati | 1000 EUR/mese a 55 abbonati

Il risultato racconta due cose. Primo: con un abbonamento da 9 euro bastano pochi clienti a coprire il server e il dominio, cioè l'infrastruttura non è il problema. Secondo: per arrivare a 1.000 euro al mese al netto delle commissioni servono 117 abbonati a 9 euro, ma 55 a 19 euro. Il prezzo cambia più dell'ottimizzazione del server. Il programma è deterministico e l'uscita è identica in due esecuzioni consecutive; la commissione cambia da carta a carta, per esempio le carte premium e quelle di fuori dallo Spazio economico europeo costano di più sul listino Stripe, e per questo il listino va riletto al momento di decidere.

Attenzione a ciò che il programma non sa: non include le tasse, i contributi previdenziali, l'IVA sugli acquisti del server né i rimborsi. Per un servizio digitale venduto a consumatori in altri Paesi dell'Unione l'IVA dipende dal Paese del cliente (l'articolo 58 della direttiva 2006/112/CE), un tema che ritroverai nell'articolo sul regime forfetario. Nessuna delle cifre sopra è una previsione di ricavo: sono costi e ipotesi dichiarate.

Un solo server, tre pezzi e un processo che si rialza

Il disegno minimo ha un web server che riceve le richieste e le inoltra all'applicazione, l'applicazione che parla con il database e un gestore che rialza l'applicazione se muore. Su Linux il gestore è systemd, e la sua configurazione sta in un file di unità. Il blocco seguente è lo schema da adattare: il percorso dell'applicazione e il binario sono d'esempio, e l'unità non è stata avviata su un server reale. È stata però controllata con systemd-analyze verify, che legge il file senza avviare nulla e non segnala errori di sintassi.

[Unit]
Description=Il mio SaaS (backend)
After=network.target

[Service]
Type=simple
DynamicUser=yes
WorkingDirectory=/opt/mio-saas
ExecStart=/usr/bin/node /opt/mio-saas/server.js
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
PrivateTmp=true

[Install]
WantedBy=multi-user.target

# Output:
# (nessun messaggio, exit 0)

Tre righe fanno il lavoro. Restart=on-failure dice a systemd di rialzare il processo se esce con errore o viene ucciso; senza, il valore predefinito è no e un crash notturno ti lascia fermo fino al mattino. RestartSec=5 aspetta cinque secondi tra un tentativo e l'altro, perché il valore predefinito è 100 millisecondi e un'applicazione che muore subito entrerebbe in un ciclo frenetico. DynamicUser=yes crea un utente temporaneo senza privilegi, e insieme a ProtectSystem=strict rende il file system in sola lettura per il processo: se qualcuno sfrutta una vulnerabilità, il danno possibile è molto minore. Dove sta il limite: ProtectSystem=strict impedisce di scrivere ovunque, perciò un'applicazione che salva file deve dichiarare le sue cartelle scrivibili con StateDirectory=. I dettagli di installazione e di nginx sono nell'articolo sull'hosting low-cost su VPS.

Che cosa lasciare fuori dallo stack iniziale

Il modo più rapido per bruciare mesi è costruire l'infrastruttura di un'azienda per un prodotto che ancora non ha clienti. Tre cose si rimandano quasi sempre senza danno, e ogni voce ha un motivo.

• Un orchestratore di container. Con un solo server, un'unità systemd fa lo stesso lavoro con un decimo della complessità.
• Una pila di monitoraggio completa. Un controllo esterno che ti avvisa quando il sito non risponde, più il log del sistema, coprono il bisogno principale all'inizio: sapere che qualcosa si è rotto.
• Più di un database. Un solo PostgreSQL copre dati relazionali, ricerca di testo e dati in formato JSON per molto tempo.

Rimandare non significa ignorare: significa scrivere nel diario di progetto la soglia che farà cambiare idea, per esempio «quando il server supera l'80% di CPU per una settimana». Così la scelta di fare di più la prende un numero, non l'entusiasmo del momento. Nell'articolo di pre-mortem trovi un metodo per elencare questi rischi prima di lanciare.

Dove si trovano pagamenti, fisco, clienti e assistenza

La parte tecnica è solo una frazione del lavoro. Prima di scrivere codice conviene sapere dove troverai il resto, nell'ordine in cui di solito serve. La pre-mortem del lancio serve a scoprire i rischi prima di spendere mesi. Il regime forfetario spiega come si tassa quello che incassi. I pagamenti con Stripe mostrano come ricevere i soldi in modo verificabile. Il marketing organico spiega come farsi trovare, il supporto da solo come non essere sommerso dalle email e i numeri dei progetti piccoli come leggere i casi di successo senza farsi ingannare.

Domande frequenti

Quanto costa tenere online un piccolo prodotto digitale?

Il server parte da 5,49 euro al mese IVA esclusa sul listino Hetzner consultato il 2026-11-13; a questo vanno aggiunti il dominio (l'importo dipende dal registrar e dall'estensione, controlla il listino) e le commissioni di incasso, che sul listino italiano di Stripe sono l'1,5% più 0,25 euro per le carte standard europee. Il costo più grande resta il tuo tempo.

Serve un database separato dall'applicazione?

Serve un database separato dal processo dell'applicazione, non per forza da un altro server. PostgreSQL sullo stesso server dell'applicazione è una scelta ragionevole all'inizio, purché i backup escano dal server stesso: l'articolo sull'hosting mostra come.

Meglio un VPS o un servizio gestito?

Un VPS costa meno e ti insegna come funziona il sistema, ma gli aggiornamenti di sicurezza e i backup sono tuoi. Un servizio gestito costa di più e ti toglie quel lavoro. Se non sai né vuoi imparare a gestire un server, il servizio gestito è la scelta onesta, anche se il conto mensile sale.

Che cosa sai fare adesso

Sai calcolare con il tuo prezzo e i tuoi costi quanti abbonati servono a coprire l'infrastruttura e a raggiungere un obiettivo mensile, sai scegliere uno stack con cinque criteri verificabili, e sai scrivere un'unità systemd che rialza l'applicazione quando muore. Sai anche che le altre voci del conto, fisco e pagamenti, hanno un loro articolo.