Applicazioni costruite sul processo reale dell'azienda, non sul processo che un prodotto preconfezionato costringe ad adottare.
Dipende da quanto il processo dell'azienda coincide con quello che il prodotto standard presuppone. Se le esigenze sono generiche — contabilità, fatturazione, magazzino in una forma comune al settore — un gestionale pronto costa meno e si attiva prima. Se invece il processo ha particolarità che danno un vantaggio competitivo, o che oggi vengono gestite a mano su fogli Excel proprio perché nessun prodotto le copre, adattare l'azienda al software standard significa perdere quelle particolarità o duplicare lavoro attorno al sistema per compensarne i limiti. Il su misura ha senso quando il processo, non il software, deve restare com'è.
Varia molto con l'ampiezza delle funzionalità richieste, ma non lavoriamo per consegna unica a fine progetto: dopo un'analisi iniziale delle esigenze si parte con un primo nucleo funzionante, utilizzabile da subito su un sottoinsieme reale del processo, e da lì si procede per rilasci successivi che aggiungono funzionalità. Questo permette all'azienda di iniziare a usare (e verificare) il software con settimane di anticipo rispetto a un modello che aspetta il progetto completo, e di correggere la rotta se qualcosa, in uso reale, non risulta come previsto in fase di analisi.
Il rilascio non è il punto di arrivo. Seguono un periodo di assestamento in cui si correggono comportamenti imprevisti emersi dall'uso quotidiano, e una manutenzione continuativa per mantenere il software allineato a librerie, sistemi operativi e requisiti di sicurezza nel tempo. A questo si aggiunge l'evoluzione vera e propria: quando il processo aziendale cambia, o emerge un'esigenza nuova, il software su misura può essere esteso, perché il codice e la logica sono conosciuti e modificabili — non è un prodotto chiuso da aggirare con soluzioni tampone.
Basta descrivere l'esigenza con parole proprie, anche in modo informale: com'è oggi il processo, dove si perde tempo, cosa dovrebbe fare il software che oggi non fa. Tradurre quella descrizione in requisiti tecnici, schermate e flussi è il nostro lavoro, non quello del cliente. Le specifiche dettagliate, semmai, sono un output dell'analisi che facciamo insieme — un documento che viene condiviso e validato prima di iniziare lo sviluppo, non un prerequisito che l'azienda deve saper scrivere da sola.
Un'applicazione Desktop gira installata su un singolo computer, tipicamente per strumenti che devono accedere a hardware locale o funzionare anche senza connessione internet affidabile. Un'applicazione Web è raggiungibile da browser su qualunque dispositivo della rete aziendale, comoda quando più persone o più sedi devono usarla senza installazioni da mantenere postazione per postazione. Un'applicazione Cloud estende lo stesso principio oltre la rete aziendale, con l'infrastruttura ospitata su server esterni: utile per accesso da remoto, da più sedi geografiche o da dispositivi mobili. La scelta dipende da chi deve usare il software, da dove, e da quali sistemi deve raggiungere — non è una preferenza tecnica astratta, ma una conseguenza diretta di come lavora l'azienda.
Si parte dal capire come il gestionale esistente espone i propri dati — un'API, un database consultabile, un formato di esportazione file — e si costruisce un collegamento che scambia le informazioni necessarie senza duplicare l'inserimento manuale né richiedere di sostituire il gestionale già in uso. Nella maggior parte dei casi il nuovo software non rimpiazza ciò che già funziona: si affianca, legge e scrive dove serve, e lascia al gestionale esistente il ruolo che ha sempre avuto. L'obiettivo è che i dati continuino a coincidere tra i sistemi, non che l'azienda debba scegliere quale abbandonare.