Software house o freelance: come scegliere per il tuo progetto
La risposta breve
Per un lavoro circoscritto, con un inizio e una fine chiari, un freelance va bene. Se invece il software entra nel modo in cui lavora l'azienda e andrà mantenuto, corretto ed esteso per anni, conviene una software house.
La bravura c'entra poco. Esistono freelance eccellenti e software house mediocri. Conta la forma del progetto. Uno che mette insieme progettazione, sviluppo, dati, infrastruttura e assistenza chiede competenze diverse e una continuità che una persona sola fatica a garantire, anche se è molto capace.
Quando un freelance è la scelta giusta
Quando il perimetro è piccolo e stabile, e dalla vostra parte c'è già qualcuno che prende le decisioni tecniche. Pensate a un sito vetrina, a una singola integrazione, a una funzionalità da aggiungere a un prodotto che ha già una sua squadra.
Qui un freelance ha vantaggi veri. Parlate direttamente con chi scrive il codice, senza passaggi in mezzo. Può entrare e uscire dal progetto senza complicazioni. E se vi serve una competenza molto precisa, trovate chi fa solo quello.
Il quadro migliore è quello in cui in casa c'è già un responsabile tecnico che definisce l'architettura, rivede il lavoro e tiene il filo. Il freelance esegue e qualcun altro governa.
Quando serve una software house
Serve quando il progetto richiede più ruoli insieme e deve reggere nel tempo. Un gestionale, una piattaforma, un'app con un backend e dei dati da proteggere. Qui il codice è solo una parte del lavoro.
Provate a elencare cosa comporta un sistema del genere. Qualcuno deve capire i processi e tradurli in requisiti, qualcuno progetta le schermate. Poi c'è chi scrive il backend, chi l'interfaccia, chi si occupa di server, backup e sicurezza. E dopo il lancio qualcuno deve rispondere quando qualcosa si rompe.
Una persona sola può coprire molti di questi ruoli. Non tutti bene, però, e non tutti nello stesso momento. Una squadra ci riesce, anche quando uno di loro è in ferie, malato o preso da altro.
Cosa succede dopo il lancio
La differenza più grande si vede nei mesi dopo la consegna. Durante lo sviluppo quasi non si nota. Dopo, capite se avete comprato un software o un problema.
Un sistema in produzione va mantenuto. Ci sono aggiornamenti di sicurezza, piccoli errori che saltano fuori con l'uso reale, richieste nuove degli utenti. Se chi l'ha scritto non è più disponibile, farlo capire a qualcun altro può costare parecchio, soprattutto con un codice senza documentazione.
A chiunque stiate valutando, fate sempre le stesse domande:
- Chi risponde se il sistema si ferma un sabato mattina?
- Per quanto tempo dopo la consegna è prevista assistenza, e a quali condizioni?
- Se la persona che ha scritto il codice se ne va, chi lo conosce?
- Il codice, il database e gli accessi ai server sono intestati a voi?
Sui costi di questa fase trovate un approfondimento in Il conto dopo il lancio. Noi includiamo sei mesi di assistenza dopo la consegna, gestiamo i ticket urgenti entro 24 ore e siamo reperibili 7 giorni su 7 per le emergenze operative. Ve lo diciamo perché è proprio il genere di voce da mettere a confronto, chiunque scegliate alla fine.
Rischio e dipendenza da una persona
Con un freelance il rischio principale è dipendere da una persona sola. La sua serietà non è in discussione. Una persona può cambiare lavoro, attraversare un periodo pieno o non essere raggiungibile proprio quando serve.
Con una software house il rischio cambia posto, ma resta. Le domande diventano altre. Chi lavora sul progetto? Sono dipendenti o il lavoro viene subappaltato? Parlerete sempre con un commerciale o con chi sviluppa?
Da noi il team è interno, senza subappalti, e chi lavora al progetto è la stessa persona che parla con il cliente. Con qualsiasi fornitore conviene verificarlo prima. Una software house che rivende il lavoro di terzi porta gli stessi rischi di un freelance, con un passaggio in più nel mezzo.
In tutti e due i casi vi tutela la stessa cosa, cioè avere per contratto la proprietà di codice, dati e infrastruttura. Ne parliamo in Di chi è il codice.
Come decidere in pratica
Guardate quanto è grande il lavoro, quanto a lungo dovrà vivere e chi prende le decisioni tecniche. Messe insieme, queste tre cose di solito danno la risposta.
- Lavoro piccolo, vita breve, un tecnico interno già presente: freelance.
- Lavoro piccolo che però diventerà centrale per l'azienda: pensate subito a chi lo manterrà fra due anni, oltre a chi lo costruisce adesso.
- Lavoro grande, o con più ruoli coinvolti: software house.
- Nessuno in azienda in grado di valutare il lavoro tecnico: software house, oppure un freelance affiancato da qualcuno che faccia da garante.
Per una startup senza una persona tecnica in squadra il ragionamento è simile, con qualche attenzione in più che trovate in Startup senza CTO.
Resta un criterio che si trascura spesso, ed è come vi faranno vedere l'avanzamento. Freelance o squadra che sia, dovreste vedere software funzionante a intervalli regolari invece di sentirvi dire che "procede". Noi lavoriamo a sprint di due settimane, con una demo funzionante ogni 14 giorni. Il principio però vale per chiunque. Se per due mesi non vedete niente, il rischio lo state correndo voi.
Domande frequenti
Un freelance costa sempre meno di una software house?
Sulla tariffa oraria spesso sì, sul costo complessivo non per forza. Bisogna mettere nel conto i tempi, le competenze che mancano e quanto costa sostituire la persona se smette di essere disponibile. Il confronto giusto è sull'intera vita del software.
Posso iniziare con un freelance e passare poi a una software house?
Sì, capita spesso. Per un passaggio senza traumi servono codice documentato, accessi intestati a voi e un repository da consegnare. Se manca uno di questi pezzi, chi subentra dovrà prima ricostruire cosa è stato fatto.
Come verifico che una software house non subappalti il lavoro?
Chiedetelo apertamente e chiedete di conoscere chi lavorerà sul progetto. Un buon controllo sono le demo. Chi vi mostra il software dovrebbe essere chi l'ha costruito, e dovrebbe saper rispondere nel merito alle vostre domande.
