# Sviluppare un software senza buttare soldi: guida per chi non è tecnico

> Per sviluppare un software senza buttare soldi devi scoprire presto, e spendendo poco, se stai costruendo la cosa giusta: scrivi il problema prima delle funzioni, parti da una prima versione minima, lavora a cicli brevi con consegne che puoi provare e decidi sui dati di utilizzo. Il rischio più caro non è il codice scritto male, ma il codice giusto per il problema sbagliato.

Di Matteo Taverna (https://tavernaconsulting.it/chi-sono) · pubblicato il 2026-11-01 · Product management
Versione web: https://tavernaconsulting.it/blog/sviluppare-software-senza-buttare-soldi

Per sviluppare un software senza buttare soldi devi fare una cosa sola, prima di tutte le altre: **scoprire il prima possibile se stai costruendo la cosa giusta**, quando sbagliare costa ancora poco. Il codice scritto male si riscrive. Il codice scritto bene per un problema che nessuno ha è soldi andati.

Questa guida è per chi deve far sviluppare un gestionale, un'app o una piattaforma e non è tecnico. Magari ha già chiesto preventivi e ha ricevuto cifre che non si somigliano, o ci è già passato una volta e il ricordo non è bello.

## Dove si buttano davvero i soldi quando si sviluppa un software?

Si buttano quasi sempre prima di scrivere una riga di codice, nelle decisioni sbagliate o mai prese. Le sei voci che vedo più spesso:

1. **Funzioni che nessuno usa.** Si costruisce tutto quello che è venuto in mente in riunione, "già che ci siamo". Una buona parte resterà inutilizzata, ma si paga lo stesso: sviluppo, test e manutenzione per sempre.
2. **Requisiti vaghi.** "Una dashboard con le statistiche" può voler dire due giorni di lavoro o due mesi. Chi sviluppa sceglie un'interpretazione, e non è detto che sia la tua.
3. **Un unico grande progetto consegnato alla fine.** Sei mesi di silenzio, poi la consegna. Se qualcosa non va, lo scopri quando hai già pagato tutto.
4. **Nessuno che decide.** Il team fa domande, nessuno risponde in tempo, e gli sviluppatori indovinano o aspettano. Entrambe le cose si pagano a giornata.
5. **Lancio senza piano.** Il software è pronto, ma nessuno sa come farlo conoscere a chi dovrebbe usarlo o comprarlo.
6. **Nessuna misura.** Dopo il rilascio non si sa chi lo usa, per cosa, e cosa migliorare. Si continua a sviluppare a sensazione.

Nota che nessuna di queste voci riguarda la tecnologia.

## Prima del codice: qual è il problema che stai risolvendo?

Il primo documento da scrivere non è l'elenco delle funzioni, è la descrizione del problema. Se non riesci a scriverla in poche righe, non sei pronto per chiedere un preventivo. Usa questo schema:

```
Chi ha il problema: [es. i tecnici che fanno assistenza a domicilio]
Qual è il problema: [es. compilano il rapportino a mano e lo ricopiano la sera]
Quanto spesso: [es. 6-8 interventi al giorno per tecnico]
Quanto costa oggi: [es. circa un'ora al giorno a testa, più gli errori di trascrizione]
Come lo risolvono adesso: [es. carta, foto con il telefono, un foglio Excel condiviso]
Come capiremo di averlo risolto: [es. rapportino chiuso dal telefono entro la fine dell'intervento]
```

Gli esempi sono ipotetici. Con questo schema in mano, chiunque ti faccia un preventivo risponde alla stessa domanda, e tu hai già un criterio per dire se il software funziona.

Per riempirlo bene devi parlare con chi ha il problema, non solo con chi lo immagina. È il lavoro di [product discovery](https://tavernaconsulting.it/blog/product-discovery): interviste, osservazione, dati che hai già. Bastano spesso una decina di conversazioni fatte bene per cambiare metà dell'idea iniziale.

## Comprare, configurare o sviluppare su misura?

Prima di sviluppare, chiediti se esiste già qualcosa che risolve il problema all'80%. Lo sviluppo su misura ha senso quando il processo è davvero tuo e ti dà un vantaggio, non quando stai rifacendo un CRM o una fatturazione elettronica.

| Strada | Quando conviene | Rischio principale |
|---|---|---|
| Software già pronto in abbonamento | Il processo è standard (fatture, CRM, calendario) | Adattarsi allo strumento invece che il contrario |
| Software pronto più configurazione o integrazioni | Il processo è quasi standard, con qualche passaggio tuo | Integrazioni fragili se nessuno le mantiene |
| Strumenti no-code | Devi provare un'idea in fretta o gestire un processo interno semplice | Limiti che arrivano quando cresci |
| Sviluppo su misura | Il processo è il tuo vantaggio o non esiste niente di adatto | Costi e tempi, se non è gestito bene |

Se il tuo problema è gestire i contatti che arrivano dalle campagne, per esempio, prima di sviluppare qualcosa guarda cosa c'è sul mercato: ne parlo nella guida al [CRM per piccole imprese](https://tavernaconsulting.it/blog/crm-piccole-imprese). Sviluppare costa sempre di più di quanto sembra, perché dopo il rilascio il software va mantenuto.

## Quanto costa sviluppare un software?

Il costo di sviluppo dipende quasi tutto da quante giornate di lavoro servono, moltiplicate per il costo di una giornata. Il resto sono dettagli. Per questo i preventivi sono così diversi: ognuno stima giornate diverse, perché ognuno ha immaginato un software diverso a partire dalla stessa richiesta vaga.

Facciamo un conto ipotetico, solo per vedere il meccanismo. Mettiamo che una giornata di sviluppo costi 400 € e che la prima versione richieda 60 giornate tra sviluppo, design e test: sono 24.000 €. Se metà delle funzioni previste non serviva, ne hai buttati circa 12.000. Il numero vero dipende da chi sviluppa, dalla zona e dal tipo di progetto, ma il ragionamento resta: **ogni funzione tolta prima di iniziare è il risparmio più grande che puoi fare.**

Le voci che fanno salire le giornate:

- **Integrazioni** con altri sistemi (gestionale, fatturazione, pagamenti, CRM).
- **Ruoli e permessi** diversi per tipi di utenti diversi.
- **App per telefono** oltre alla versione web, soprattutto se servono sia Android sia iPhone.
- **Dati sensibili** da proteggere, con i relativi obblighi di privacy.
- **Funzioni offline**, sincronizzazioni, notifiche.
- **Importazione di dati vecchi** da sistemi esistenti, quasi sempre più disordinati del previsto.

E ricorda i costi dopo il lancio: server, manutenzione, aggiornamenti di sicurezza, correzioni, piccole modifiche. Chiedi sempre di metterli nero su bianco insieme al preventivo di sviluppo, anche come stima.

## Come si parte senza rischiare tutto: la prima versione minima

Si parte costruendo la versione più piccola che permette di imparare qualcosa di vero da utenti veri. Si chiama [MVP](https://tavernaconsulting.it/blog/mvp-cosa-e), *minimum viable product*: prodotto minimo funzionante. Non è un prototipo che non funziona, è un software che fa bene poche cose.

Per decidere cosa ci entra, prendi l'elenco delle funzioni e per ognuna chiediti: "Se manca, il primo utente riesce comunque a risolvere il suo problema?". Se la risposta è sì, la funzione aspetta. Di solito resta fuori più della metà dell'elenco, e va bene così.

Una buona prima versione ha tre caratteristiche:

- **Risolve un problema intero** per un gruppo piccolo di utenti, non metà problema per tutti.
- **Si usa davvero**, nel lavoro di tutti i giorni, non solo in una demo.
- **Ha un numero da guardare** fin dal primo giorno, deciso prima di iniziare.

## Perché lavorare a cicli brevi fa risparmiare

Lavoro a cicli brevi, di una o due settimane, così scopriamo di aver sbagliato quando costa poco invece che a sei mesi dal lancio. È la differenza tra correggere la rotta e rifare il viaggio.

Alla fine di ogni ciclo c'è una funzione che gira, anche piccola, non una percentuale di avanzamento. La provi, la fai provare a chi la userà, e si decide il ciclo successivo.

Riprendiamo il conto ipotetico di prima. Se scopri un errore di direzione dopo due settimane, hai speso 10 giornate. Se lo scopri a fine progetto, ne hai spese 60, e una parte va rifatta. I cicli brevi non rendono il progetto più economico per magia: rendono gli errori più piccoli.

Il metodo con cui organizzare i cicli dipende dal team, e li confronto nell'articolo su [Scrum o Kanban](https://tavernaconsulting.it/blog/scrum-o-kanban). Per te, che paghi, conta che ci sia una consegna da vedere a intervalli regolari.

> **Stai per firmare un preventivo per un software?** Prima di firmare, mandami il preventivo e due righe sul problema che vuoi risolvere. Ti dico cosa toglierei dalla prima versione, cosa manca e quali domande fare a chi sviluppa. Scrivi a info@tavernaconsulting.it o usa il modulo su https://tavernaconsulting.it/blog/sviluppare-software-senza-buttare-soldi#contatto

## Come si scrivono requisiti che si possono verificare?

Un requisito verificabile dice chi usa la funzione, cosa vuole ottenere e come si controlla che funzioni. Io li scrivo sempre dal punto di vista di chi userà il prodotto, con criteri di accettazione. Un esempio ipotetico:

> Come tecnico in assistenza, voglio chiudere il rapportino dal telefono a fine intervento, così da non doverlo ricopiare la sera.
>
> Criteri di accettazione: il rapportino si compila anche senza connessione e si invia appena torna la rete; il cliente può firmare sullo schermo; l'ufficio vede il rapportino entro cinque minuti dall'invio.

Con un requisito così, a fine ciclo non si discute se la funzione "è fatta": si prova, e i criteri sono rispettati oppure no. Il metodo completo è nell'articolo su [user story e criteri di accettazione](https://tavernaconsulting.it/blog/user-story-criteri-di-accettazione).

## Chi deve sviluppare: interno, freelance o software house?

Dipende da quanto è grande il progetto e da quanto durerà dopo il lancio. Nessuna opzione è sbagliata in assoluto.

| Chi sviluppa | Punti di forza | Attenzione a |
|---|---|---|
| Sviluppatori interni | Conoscono l'azienda, restano dopo il lancio | Costo fisso, difficile trovarli, una persona sola è un rischio |
| Freelance | Flessibile, spesso meno caro | Se si ferma lui, si ferma tutto; servono più competenze diverse |
| Software house | Team completo, più continuità | Va guidata: senza un cliente competente costruisce quello che c'è scritto, non quello che serve |

In tutti i casi, il codice e gli accessi devono essere tuoi: il repository (l'archivio dove sta il codice), il dominio, i server, gli account dei servizi esterni. Se un giorno cambi fornitore, devi poter consegnare tutto al successivo. Ho scritto una guida su come [lavorare con una software house senza sorprese](https://tavernaconsulting.it/blog/lavorare-con-software-house), con le domande da fare e cosa mettere nel contratto.

## Come controllare i lavori se non sei tecnico?

Non serve leggere il codice. Serve vedere il software funzionare a intervalli regolari e avere regole chiare su quando una cosa è finita. La mia lista minima:

- **Demo a ogni ciclo.** Ogni una o due settimane vedi il software girare, non delle slide.
- **Un ambiente di prova.** Una versione del software, separata da quella vera, dove tu e i futuri utenti potete provare le novità.
- **Il backlog visibile.** La lista ordinata delle cose da fare, che puoi leggere quando vuoi.
- **Criteri di accettazione scritti.** Una funzione è finita quando li rispetta, non quando lo dice chi l'ha sviluppata.
- **Accessi a tuo nome.** Codice, server e servizi intestati all'azienda.
- **Una persona che decide.** Dalla tua parte, qualcuno che risponde alle domande del team in giornata.

Se questa persona non ce l'hai, o non ha tempo, è il momento di valutare un [product manager](https://tavernaconsulting.it/blog/product-manager-cosa-fa): qualcuno che sta in mezzo tra chi scrive il codice, chi disegna e chi firma gli assegni, e che traduce tra i tre.

## Il software va anche venduto (o fatto usare)

Un software pronto che nessuno usa ha lo stesso valore di un software mai fatto, ma è costato di più. Che sia un prodotto da vendere o uno strumento interno, il lancio va preparato mentre si sviluppa, non dopo.

Per un prodotto da vendere, significa sapere fin dall'inizio a chi si rivolge, con quale messaggio e su quali canali. Nel mio lavoro chi decide cosa costruire sa già come si venderà, perché tengo insieme prodotto e marketing: è lo stesso approccio con cui ho progettato, costruito e lanciato Skeo, il CRM leggero per i contatti delle campagne. Ne parlo nella guida su come [lanciare un prodotto digitale](https://tavernaconsulting.it/blog/lanciare-prodotto-digitale).

Per uno strumento interno, significa formare chi lo userà e correggere in fretta i problemi della prima settimana. Un gestionale che il team aggira con il vecchio Excel è un fallimento, anche se funziona.

## Dopo il lancio: decidere con i dati, non con le sensazioni

Dopo il rilascio si guarda chi usa il software e per fare cosa, e si decide il ciclo successivo su questi numeri. Senza dati vince chi alza di più la voce.

Le domande minime da farsi nel primo mese: quante persone hanno iniziato a usarlo? Quante lo usano ancora dopo due settimane? La funzione principale viene usata, o le persone si fermano prima? Dove si bloccano? Le [metriche di prodotto](https://tavernaconsulting.it/blog/metriche-di-prodotto) da guardare sono poche, ma vanno decise prima del lancio, perché vanno misurate dal primo giorno.

## Da dove partire domani mattina

Se hai un software in testa, o in un preventivo sulla scrivania, questi sono i primi passi, nell'ordine:

1. **Scrivi il problema con lo schema sopra.** Sei righe, niente funzioni.
2. **Parla con cinque persone che hanno quel problema.** Chiedi come fanno oggi e l'ultima volta che ci hanno perso tempo.
3. **Cerca se esiste già uno strumento** che lo risolve all'80%. Se sì, provalo prima di sviluppare.
4. **Taglia l'elenco delle funzioni a metà.** Tieni solo quelle senza cui il primo utente non risolve il problema.
5. **Decidi un numero** che ti dirà se il software ha funzionato.
6. **Chiedi a chi sviluppa consegne ogni due settimane**, con demo e ambiente di prova.

Se vuoi una mano su uno di questi passi, trovi il servizio di [product management](https://tavernaconsulting.it/#product) e il [metodo](https://tavernaconsulting.it/#metodo) con cui lavoro: ascolto, definisco, costruisco, lancio, ottimizzo.

## Domande frequenti

### Quanto costa far sviluppare un software su misura?

Dipende da quante giornate di lavoro servono e da quanto costa una giornata, quindi da cosa si costruisce e da chi lo costruisce. Per questo due preventivi per "lo stesso gestionale" possono essere molto diversi: hanno immaginato software diversi. Il modo più efficace per tenere basso il costo è definire bene il problema e ridurre la prima versione alle funzioni indispensabili, poi aggiungere il resto in base all'uso reale.

### Meglio un preventivo a corpo o pagare a giornate?

Il preventivo a corpo dà un prezzo fisso, ma solo per quello che è scritto: ogni cambiamento diventa una variante da pagare, e nel software i cambiamenti sono inevitabili. Il pagamento a giornate è più flessibile ma richiede controllo. Una via di mezzo che funziona spesso è pagare a cicli brevi con un tetto di spesa e consegne verificabili a ogni ciclo, così puoi fermarti o cambiare direzione.

### Posso sviluppare un software se non sono tecnico?

Sì, a patto di avere chiaro il problema da risolvere e qualcuno di fiducia che faccia da ponte con chi sviluppa. Non serve leggere il codice: serve vedere il software funzionare a intervalli regolari, avere requisiti scritti con criteri di accettazione e accessi intestati all'azienda. Molti progetti falliti avevano sviluppatori bravi e un cliente senza tempo per decidere.

### Quanto tempo serve per avere una prima versione utilizzabile?

Per una prima versione davvero minima, ridotta a un solo problema per un gruppo piccolo di utenti, si ragiona spesso in settimane o pochi mesi, non in anni. Dipende dalla complessità, dalle integrazioni con altri sistemi e da quanto in fretta l'azienda prende le decisioni. Se la prima versione richiede più di qualche mese, quasi sempre contiene troppo.

### Cosa succede al software se cambio fornitore?

Se codice, server, dominio e account dei servizi esterni sono intestati alla tua azienda, e il codice è documentato almeno nelle parti principali, un nuovo fornitore può riprendere il lavoro, anche se servirà un periodo per prendere confidenza. Se invece tutto è sugli account del vecchio fornitore, il passaggio diventa lento e costoso. Chiarisci questo punto nel contratto, con l'aiuto di un legale.

---

Matteo Taverna è Product Manager agile e Full Stack Marketer (Taverna Consulting), in presenza e da remoto. Contatti: info@tavernaconsulting.it · https://tavernaconsulting.it/#contatti