Applicazioni su misura

È vostro: codice, dati e chiavi

Quello che costruiamo per voi è vostro per contratto, non in licenza d’uso. Vi consegniamo il codice sorgente, le istruzioni per rimettere in piedi l’ambiente da zero e le credenziali di tutto quello che serve per farlo funzionare. Senza le ultime due cose il codice da solo vale poco, ed è il motivo per cui vengono consegnate insieme.

Anche i dati restano vostri e leggibili: PostgreSQL, formati aperti, nessuna struttura oscura che richieda il nostro software per essere interpretata. Il giorno in cui volete portare tutto altrove, quel giorno deve costarvi giorni, non mesi.

Gira dove decidete voi: sui vostri server, in colocazione, su un cloud privato o su uno pubblico. Non c’è nessun pezzo nostro nel percorso critico, e non c’è nessun canone per utente che cresce mentre l’azienda cresce.

Un software solo vostro, non un prodotto da adattare

La differenza sostanziale rispetto a un gestionale in abbonamento è che nessun altro condivide quel software con voi: non ci sono compromessi con le esigenze di altri clienti, non ci sono aggiornamenti che cambiano le vostre schermate un martedì mattina, non c’è un listino che decide cosa potete fare.

In cambio c’è una responsabilità che va detta: un software vostro va mantenuto. Qualcuno deve aggiornarlo, correggerlo e farlo evolvere, e quel qualcuno va scelto e pagato. È il patto che rende sostenibile la proprietà, ed è meglio metterlo in chiaro all’inizio che scoprirlo al secondo anno.

Se la piattaforma serve più aziende

Alcuni progetti non finiscono dentro la vostra azienda: servono le vostre filiali, i vostri partner o i vostri clienti, ciascuno con i propri dati. È un caso diverso dal software su misura per un’unica organizzazione, e cambia una cosa in particolare.

Lì la domanda vera non è come si disegna la lista clienti, ma cosa succede il giorno in cui una query dimentica il filtro sull’azienda. Se il controllo è solo nel codice, quel giorno un cliente vede i dati di un altro e nessuno se ne accorge: nessun errore, nessun allarme, solo righe di troppo su una schermata.

Per questo, quando il progetto è di questo tipo, l’isolamento lo mettiamo dentro PostgreSQL con regole per riga, e l’applicazione si collega con un ruolo che non può scavalcarle. Il codice può sbagliare: il database no. Se invece il software è per voi soli, questo strato non serve e non lo aggiungiamo: complessità che non paga.

Veloce da subito, in ogni lingua

Le pagine arrivano già disegnate dal server: conta per chi le legge, che le vede subito, e conta per Google, che non esegue JavaScript. Il browser si prende solo le parti che devono davvero reagire.

Il multilingua è struttura, non traduzione appiccicata: indirizzi puliti per ogni lingua, rimandi reciproci fra le versioni e una scelta esplicita su cosa mostrare quando una traduzione manca.

Una fetta alla volta, in mano alle persone

Non consegniamo a fine progetto: consegniamo pezzi che qualcuno usa mentre il resto è ancora da fare. Ogni fetta è una funzione completa — non una schermata bella senza niente dietro — e viene messa in mano a chi dovrà usarla davvero.

Serve a scoprire in tempo la cosa che nessuna analisi trova: che una funzione richiesta con convinzione, una volta provata, non serviva. È molto meno costoso accorgersene alla terza settimana che al collaudo finale.

Prima ancora, dove la cosa è dubbia, si fa un prototipo navigabile: si tocca e si discute quando cambiare idea costa un pomeriggio invece che due settimane.

Cosa si rompe, e come ce ne accorgiamo prima di voi

Ogni percorso che conta — chi entra, chi ordina, chi paga — è coperto da prove automatiche che girano a ogni modifica e bloccano il rilascio se qualcosa non torna. Non è perfezionismo: è quello che permette di correggere una cosa senza aver paura di romperne un’altra.

In produzione gli errori arrivano a noi con il contesto di cosa stava facendo l’utente, non come segnalazione generica. La differenza pratica è che un problema si corregge il giorno stesso invece che alla terza telefonata.

Le prestazioni si misurano sui dispositivi veri, non sul portatile di chi sviluppa: una pagina che apre in due secondi sul telefono di un vostro cliente vale più di qualsiasi ottimizzazione teorica.

Non dipendere da noi

Le tecnologie che usiamo sono diffuse di proposito: se un domani volete cambiare fornitore, trovate qualcuno che ci lavori senza doverlo formare per mesi. È il contrario di quello che conviene a noi nel breve, ed è la ragione per cui potete fidarvi del resto.

Ogni scelta strutturale lascia scritto il perché — non un manuale, due paragrafi. È quello che permette, tre anni dopo, di cambiare idea sapendo cosa si sta toccando, e a un altro fornitore di capire in un giorno com’è fatto il sistema.

Nessun pezzo deve essere comprensibile a una persona sola. Se dentro un progetto esiste una parte che solo chi l’ha scritta sa far funzionare, quella parte è un problema vostro anche se il codice è vostro.

Chi lavora fuori dall’ufficio

L’app mobile è il bordo del sistema: il punto in cui il dato nasce. Se lì è comoda, tutto il resto a valle funziona; se è scomoda, la gente torna al foglio di carta e il gestionale racconta una storia falsa.

Deve reggere guanti, sole, fretta e una mano sola: pochi tocchi per l’operazione più frequente, testo grande, conferme chiare. Una sola base di codice per iOS e Android, e dove si tocca valore o identità le credenziali restano nell’enclave sicura del dispositivo.