Come scegliere una software house: 12 controlli concreti

Il portfolio serve a capire come una software house traduce problemi reali in prodotti leggibili, non a contare quanti loghi espone. Cerca progetti comparabili per complessità: gestione di ruoli, flussi approvativi, pagamenti, notifiche, mappe, sincronizzazione con un gestionale o pubblicazione sugli store. Non è necessario che il settore sia identico; è più importante che siano simili le difficoltà da governare.

Quando osservi un portfolio di app e software realizzati, chiedi che cosa è visibile, quali funzioni sono documentate e quale parte del progetto è stata effettivamente curata dal team. Evita di basare la scelta su risultati commerciali non dimostrabili o su numeri privi di contesto. Una buona presentazione distingue i fatti osservabili dalle considerazioni generali sul valore del prodotto.

Prima di costruire tutto, dovresti poter verificare il flusso principale attraverso una demo, un prototipo navigabile o una prima versione limitata. Vedere e provare riduce le ambiguità che un documento, da solo, non riesce a eliminare: ordine delle schermate, priorità delle informazioni, passaggi mancanti e termini poco chiari emergono molto prima.

Per idee nuove può essere utile partire da un MVP con le sole funzioni essenziali. Non significa consegnare un prodotto trascurato, ma separare ciò che serve per validare l'ipotesi da ciò che potrà essere aggiunto con dati e feedback reali. La software house dovrebbe spiegare cosa verrà imparato dalla prima versione e quale decisione renderà possibile.

«Area riservata», «pagamenti» o «gestione ordini» non sono specifiche. Per ogni funzione bisogna descrivere utenti, permessi, dati, regole, stati ed errori. Un preventivo serio elenca ciò che è incluso e ciò che è escluso, chiarisce le assunzioni e indica come verrà verificata la consegna. Senza questa base, cliente e fornitore possono attribuire significati diversi alla stessa frase.

I criteri di accettazione trasformano un desiderio in un controllo concreto. Per esempio: chi può annullare un ordine, entro quale momento, con quale notifica e quale effetto sul pagamento. Questa precisione non rende il progetto rigido; crea un punto di partenza comune e consente di gestire le nuove idee come cambiamenti consapevoli, invece che come discussioni su ciò che «sembrava compreso».

Non devi diventare sviluppatore, ma devi ricevere una spiegazione comprensibile di dove vivranno applicazione, dati e servizi. Chiedi quali sistemi esterni saranno collegati, quali API sono già disponibili, quali limiti dipendono da terzi e cosa accade se un fornitore cambia prezzi o regole. Database, invio email, mappe, notifiche, pagamenti e strumenti di analisi possono generare costi ricorrenti che vanno separati dal lavoro di sviluppo.

Una buona proposta distingue le parti costruite su misura dai servizi esterni e dai componenti riutilizzati. Indica inoltre chi configura gli ambienti di prova e produzione, come vengono gestite le credenziali e quali passaggi sono necessari per esportare i dati. L'obiettivo non è scegliere l'architettura più complessa, ma quella proporzionata al carico, al rischio e alle competenze che dovranno mantenerla.

Il codice non dovrebbe comparire soltanto alla fine in un archivio difficile da verificare. Con Contat il cliente ha accesso al repository Git fin dall'inizio e può usare e far manutenere il codice consegnato senza limiti di tempo per l'intera vita del progetto commissionato, anche dopo il trasferimento del progetto alle stesse condizioni contrattuali. Il repository documenta l'avanzamento e rende più semplice una consegna ordinata.

Quando richiesto, gli account Apple, Google, cloud e database possono essere intestati al cliente. La software house riceve gli accessi necessari per lavorare, ma l'organizzazione conserva il controllo delle risorse che sostengono il prodotto. Il contratto deve distinguere il codice realizzato per il progetto dai componenti riutilizzabili o preesistenti del fornitore e dal software di terzi o open source, che mantengono proprietà e licenze proprie.

La sicurezza non si aggiunge la settimana prima del lancio. Chiedi quali dati personali vengono raccolti, perché sono necessari, per quanto tempo restano disponibili e chi può consultarli. Autenticazione, ruoli, registri delle operazioni, cifratura, gestione dei segreti e aggiornamento delle dipendenze devono essere proporzionati al tipo di informazioni e alle conseguenze di un accesso improprio.

Fatti spiegare frequenza, conservazione e verifica dei backup, oltre al modo in cui si ripristina il servizio. Chiedi dove risiedono i dati, quali fornitori intervengono e quali responsabilità rimangono al cliente. Il progetto e il contratto devono coprire privacy, sicurezza, backup e GDPR; per valutazioni giuridiche specifiche è opportuno coinvolgere il proprio consulente, perché una checklist tecnica non sostituisce una consulenza legale.

Una data finale senza tappe intermedie non consente di capire se il progetto sta procedendo bene. Cerca un piano con decisioni, consegne verificabili e dipendenze del cliente: accesso ai sistemi, contenuti, approvazioni, account store. Ogni milestone dovrebbe produrre qualcosa che puoi osservare, come un flusso navigabile, un'integrazione funzionante o una versione installabile.

Concorda frequenza degli aggiornamenti, canale principale, responsabile delle decisioni e modalità di approvazione. Le demo periodiche servono a vedere il prodotto, non a sostituire una documentazione chiara. È utile sapere anche come vengono registrati problemi e richieste, quali tempi dipendono da Apple, Google o altri fornitori e come una decisione in ritardo modifica il calendario.

Il preventivo dovrebbe collegare costi e fasi a risultati riconoscibili: analisi, progettazione, sviluppo, test, pubblicazione e assistenza. Deve separare spese una tantum, canoni, licenze e consumi di servizi esterni. Le condizioni di pagamento, la validità dell'offerta e le ipotesi su cui si basa devono essere esplicite. Un totale privo di perimetro non è facile da confrontare né da far rispettare.

Chiedi come funziona una richiesta di modifica: chi la valuta, come vengono stimati impatto e priorità e quando serve un'approvazione economica. Puoi usare Smartquote per mettere a fuoco il progetto e preparare una prima descrizione strutturata, ma la stima definitiva deve arrivare dopo un confronto umano e l'analisi delle funzioni reali.

Un bug è un comportamento che non rispetta quanto approvato. La manutenzione mantiene il prodotto operativo e compatibile, per esempio aggiornando dipendenze o controllando l'infrastruttura. Un cambiamento modifica o amplia ciò che il prodotto deve fare. Sono attività diverse e il contratto dovrebbe indicare perimetro, priorità, tempi e modalità di richiesta di ciascuna.

Nei progetti Contat, manutenzione, bug fixing e modifiche successive per i primi 12 mesi hanno copertura definita e inclusa nel contratto: non una promessa vaga, ma condizioni verificabili rispetto al progetto concordato. Prima della firma vengono chiariti anche eventuali costi dal tredicesimo mese e le spese vive di servizi esterni. Chiedi a ogni fornitore lo stesso livello di precisione.

Un accordo completo non descrive solo lo scenario ideale. Deve disciplinare ritardi, responsabilità, sospensione, recesso, mancata collaborazione, consegna del lavoro incompleto e passaggio delle informazioni necessarie a proseguire. Deve inoltre trattare proprietà intellettuale, utilizzo del codice, materiali forniti dal cliente e componenti con licenze proprie. Questi punti riducono l'incertezza proprio quando la relazione diventa difficile.

Leggi le condizioni prima di approvare la proposta e verifica che siano coerenti con il preventivo e il capitolato. Puoi consultare i nostri termini e condizioni del servizio come riferimento pubblico, sapendo che il progetto concreto viene regolato dal contratto firmato. La prima chiamata con Contat è gratuita: serve a capire il problema e la compatibilità reciproca, non a forzare una decisione.

La software house migliore non è quella che promette assenza di problemi. È quella che rende trasparenti persone, scelte e responsabilità, permette di verificare il prodotto prima di estenderlo e prepara un percorso praticabile anche quando cambiano le condizioni. Porta questi dodici controlli al prossimo incontro: le risposte saranno più utili di qualsiasi slogan.