Esperienza · Software su misura

Un sistema costruito per il modo in cui lavora la vostra organizzazione, non per il caso generale.

Costruiamo sistemi da zero, quando nessun prodotto sul mercato si adatta: piattaforme con più applicazioni e un database comune, connettori verso sistemi che non hanno API, pipeline che leggono documenti e movimenti di denaro, e programmi il cui risultato non è uno schermo, ma un dossier di fabbricazione. Alla fine consegniamo il repository, il documento di messa in servizio e gli accessi.

Parliamo di un progetto

Già costruitoAm ales patru sisteme proprii din discipline diferite, tocmai ca să nu arate ca patru variante ale aceluiași site, și am rulat testele fiecăruia azi. Un monorepo cu 3 aplicații și 12 pachete, 486 de fișiere TypeScript și 68 de fișiere de test, 151 de comituri, arbore de lucru curat. Un sistem de interogare a două portaluri B2B fără API public: 38 de teste trecute în 0,52 s, pe răspunsuri reale salvate ca fixturi. O conductă care citește notificări bancare din e-mail și PDF și le scrie în Postgres cu deduplicare prin amprentă. Și un generator de documentație de inginerie, în Python, cu 44 de teste trecute în 0,50 s. Cifrele sunt din rulările mele de pe 6 septembrie 2026, nu din README-uri.

«Su misura» significa che il sistema viene scritto secondo il modo in cui le vostre persone lavorano già, non il contrario. Ha un costo che è onesto dire prima: qualcuno dovrà mantenerlo, e quel qualcuno saremo noi o il vostro team. Per questo la prima domanda che vi poniamo non è cosa volete costruire, ma se esiste già un prodotto che fa l’80% del lavoro. Se esiste, lo diciamo, anche se significa che non ci affidate il lavoro. Ciò che resta dopo quella domanda — la parte che non si compra — è esattamente ciò che costruiamo bene.

L’ampiezza si vede più chiaramente da quattro sistemi diversi che da un elenco di tecnologie. Il primo è una piattaforma per un’istituzione di spettacoli: un monorepo con tre applicazioni (sito pubblico, cabinet amministrativo, API) e dodici pacchetti comuni — biglietti, commercio, contenuti, notifiche, rimborsi, sicurezza. Il secondo interroga, su richiesta, i portali B2B di alcuni tour operator che non pubblicano alcuna API: autenticazione programmatica, ritorno al login quando la sessione scade, e un parser testato su risposte reali catturate in file. Il terzo legge notifiche bancarie da e-mail e estratti PDF e le inserisce in Postgres. Il quarto non ha alcuno schermo: è il programma che genera il modello, la distinta base e le tavole di una macchina industriale.

Ciò che tiene in piedi un sistema del genere non è lo stack, ma le regole scritte prima del primo schermo. Nella piattaforma per l’istituzione di spettacoli, il contratto di implementazione fissa nel testo cose che altrimenti si negoziano a ogni riunione: il denaro è mantenuto in unità minori intere, con la valuta accanto; la disponibilità di un posto è data solo da una prenotazione duratura nel database, mai dalla cache; gli ordini critici hanno chiavi di idempotenza; i percorsi P0 e P1 falliscono chiusi, non aperti; i dati della carta non vengono mai memorizzati. Queste regole si scrivono all’inizio perché, scritte alla fine, significherebbe riscrivere il sistema.

Alla fine si consegnano tre cose, non una: il repository con tutta la sua cronologia, il documento che dice come si mette in funzione su un server vuoto, e gli accessi. Sotto la nostra directory di progetti ci sono 150 repository git, 103 file README e 19 documenti di messa in funzione o di consegna — contati oggi, non stimati. La regola di proprietà la scriviamo nel contratto prima dell’avvio ed è semplice: il codice scritto apposta per voi è vostro, le librerie terze restano sotto la loro licenza, mentre i nostri componenti riutilizzabili e i nostri prodotti vengono concessi in licenza, non ceduti. Se una parte del lavoro si risolve meglio con un nostro prodotto, ve lo diciamo esattamente così, così sapete dall’inizio cosa comprate e cosa ricevete.

Cosa comprende

Il lavoro, per componenti

Scriviamo le regole del dominio prima del primo schermo

Un contratto di implementazione, in testo, che fissa il vocabolario e gli invarianti: che cosa significa un posto prenotato, che cosa significa un pagamento incassato, che cosa va in fail closed quando un servizio non risponde. Nella piattaforma per l’istituzione di spettacoli le regole sono esplicite — denaro in unità minori intere più la valuta, disponibilità solo da prenotazioni durature nel database, chiavi di idempotenza sugli ordini critici, cache mai come fonte di verità per lo stock, dati della carta mai memorizzati. Sono regole che si verificano nel codice, non principi.

Costruiamo il nucleo su test che girano senza il sistema vivo

Le risposte reali dei sistemi esterni vengono salvate come fixture e l’analizzatore viene testato su di esse, non sul portale che può essere giù proprio nel giorno in cui Lei lavora. Nel sistema di interrogazione dei portali di voli, la suite viene eseguita in 0,52 secondi e passa integralmente; i test che toccano davvero i portali sono marcati separatamente e devono essere richiesti esplicitamente. La stessa separazione esiste in tutti e quattro i sistemi: ciò che si può verificare al banco si verifica al banco.

Consegniamo il repository, la messa in funzione e gli accessi

Non un file zip. Il repository con la cronologia dei commit, un documento che descrive come si solleva il sistema su una macchina vuota — database, variabili d’ambiente, servizio di sistema, server web davanti — e gli accessi che lo rendono vostro. Sotto la nostra directory di progetti esistono oggi 150 repository git, 103 README e 19 documenti di tipo DEPLOY o HANDOVER; questa forma di consegna è l’abitudine, non l’eccezione.

Quando il sistema dell’altro non ha API, diciamo quale rischio assumete

I portali B2B che interroghiamo non pubblicano un’interfaccia programmatica, quindi l’autenticazione avviene come per un utente, con cookie di sessione e chiave di connessione, e viene rifatta automaticamente alla scadenza. Il rischio è scritto nel README del progetto, non scoperto in seguito: l’autenticazione programmatica è una zona grigia rispetto alle condizioni d’uso del portale, e per un volume di produzione intenso la soluzione corretta è chiedere all’operatore la sua API ufficiale. Un cliente ha il diritto di saperlo prima di firmare, non dopo.

I documenti entrano una sola volta, anche se li leggiamo dieci volte

Ogni transazione estratta da una notifica bancaria o da un estratto PDF riceve un identificatore esterno calcolato come fingerprint SHA-256 sui suoi campi, e l’inserimento in Postgres avviene con `ON CONFLICT (external_id) DO NOTHING`. Conseguenza pratica: la casella postale può essere riletta quante volte volete, e il saldo non si raddoppia. Senza questa regola, qualunque pipeline di ingestione finisce per produrre duplicati, cioè un problema di contabilità.

La classificazione con modello avviene tramite strumenti, non con testo libero

Il modello non scrive una frase che poi indoviniamo noi: riceve sette strumenti — pagamento da cliente, stipendio, imposta, pagamento verso creditore, spesa di esercizio, sconosciuto — e deve sceglierne uno, con un punteggio di confidenza tra 0 e 1. Per l’abbinamento approssimativo dei nomi della controparte esiste una riserva separata, basata sulla similarità dei vettori. «Sconosciuto» è un’uscita legittima, con motivo, non un fallimento nascosto.

A volte il risultato non è uno schermo, ma un dossier

Un sistema proprietario in Python genera il modello tridimensionale di una macchina industriale, la distinta base con stato di rilascio per ogni posizione, il piano di verifica, lo schema dei cavi e le tavole PDF — con un solo comando, così che nulla del pacchetto possa restare indietro rispetto al modello. Ha 44 test che passano in mezzo secondo e verificano regole di ingegneria, non solo codice: che il dominio attivo sia esattamente un metro cubo, che nessuna posizione della distinta base resti senza riga di verifica, che la macchina non estruda mai in riposo.

La misurazione continua è una disciplina diversa dall’interrogazione su richiesta

Un sistema proprietario acquisisce simultaneamente più stazioni radio con `ffmpeg`, trascrive localmente con un modello open-source, poi cerca gli spot pubblicitari con un punteggio trasparente su gruppi di segnali in romeno e russo, con soglia configurabile, e raggruppa lo stesso spot trasmesso su stazioni diverse tramite un fingerprint audio di tipo chromaprint — perché le trascrizioni divergono, ma il suono è identico. Ha 81 test che passano in 1,14 secondi. Un sistema che gira senza supervisione ha bisogno di contatori di copertura, retry con leasing di task e un autotest, altrimenti tace quando si guasta.

Diciamo anche cosa non costruiamo

Non costruiamo da zero ciò che si risolve con un prodotto esistente, nostro o di qualcun altro, solo perché il lavoro sarebbe più grande. Non prendiamo in carico sistemi che non possiamo eseguire localmente, con dati di test, entro la fine della prima fase. E non avviamo un sistema che dipende da un fornitore esterno prima di verificare quale gate pubblico abbia quel fornitore: quella verifica è la prima, non l’ultima.

Come si presenta

Il percorso, passo dopo passo.

Delimitiamo il dominio e scriviamo le regole

Una fase di lettura dei sistemi e di confronto con le persone che svolgono il lavoro oggi, conclusa con un breve documento con il vocabolario, le invarianti e ciò che si chiude in caso di errore. Consegniamo questo documento anche se non si arriva alla costruzione: è utile anche senza di noi. Include anche l’elenco dei sistemi esterni da cui dipende il lavoro e la verifica di quale gate pubblico abbia ciascuno, perché le sorprese arrivano da lì.

Costruiamo il nucleo, con i suoi test, prima delle interfacce

Le regole del dominio, i modelli di dati, gli analizzatori, i calcoli — più i test che girano senza i sistemi vivi, su fixture catturate da risposte reali. Consegnamo la suite e il suo risultato, con il comando di esecuzione, così puoi eseguirla tu. Un nucleo che non può essere testato senza l’ambiente di produzione è un nucleo che non possiamo riparare rapidamente in seguito.

Mettiamo l’interfaccia e le integrazioni sopra il nucleo

Il pannello amministrativo, le schermate pubbliche, i punti di ingresso per altri sistemi. Qui si collegano i fornitori esterni, ciascuno con un proprio adattatore e con una variante di simulazione, così che il sistema possa essere eseguito integralmente senza account reali. Consegnamo anche la modalità di esecuzione locale, con database e servizi avviati da container.

Mettiamo in funzione e consegniamo

Installazione sull’infrastruttura concordata, servizio di sistema, server web davanti, log e loro rotazione, autotest. Poi la consegna: repository, documento di messa in funzione scritto per una macchina vuota, accessi, e una rassegna di ciò che resta da fare. Ciò che non si è fatto in tempo a includere nel lavoro si scrive come elenco, non si lascia non detto.

Trei pași și ordinea lor, care e jumătate din lucrare. Întâi regulile domeniului scrise în text — ce înseamnă un loc rezervat, cum se țin banii, ce cade închis când un serviciu tace. Apoi nucleul cu testele lui, care rulează pe răspunsuri reale salvate ca fixturi, fără sistemele vii. La final punerea în funcțiune și predarea: depozit, documentul pentru o mașină goală, accese. Săgeata înapoi de la pasul trei la pasul unu e reală: ce se descoperă la punerea în funcțiune schimbă regulile, nu se ascunde sub ele.

I dati

Cosa tocchiamo, dove risiedono e quanto rimangono

Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.

Dove gira e chi tiene la chiave: Il sistema gira sull’infrastruttura concordata per iscritto all’inizio: il tuo server, un server gestito da noi, oppure un fornitore di hosting scelto insieme. I quattro sistemi sopra girano in modo diverso tra loro — uno come servizio di sistema dietro un server web, uno da container, uno come processo pianificato su una macchina locale, uno solo su comando, sulla postazione di lavoro. La scelta si prende dai vincoli dei dati, non dall’abitudine.
Le credenziali non stanno nel codice e, dove si può, neppure su disco: Le password e le chiavi si leggono da variabili d’ambiente, e il file che le contiene è ristretto all’utente corrente. In un connettore verso un sistema esterno, il token di sessione si tiene solo in memoria e si rinnova alla scadenza o al primo rifiuto — la password e il token non si scrivono in nessun file. La regola si verifica in revisione: una chiave finita nel repository è un incidente, non una svista.
I dati che entrano dai documenti: Quando il sistema legge e-mail o PDF, tocca dati reali di business: importi, date di calendario, denominazioni della controparte, numeri di conto. Si memorizzano nel database del beneficiario, con un identificatore proprio, non ripetibile per record, e ricostruibile dalla fonte. Ciò che passa a un modello esterno, se se ne usa uno, è la descrizione della transazione — non l’intero documento e non l’allegato.
Cosa viene conservato e per quanto tempo: Il termine di conservazione si stabilisce per tipo di dato, non in modo globale, e si scrive prima della messa in funzione: le registrazioni di business secondo gli obblighi legali del beneficiario, i log tecnici su una finestra breve, i file intermedi — acquisizioni audio, allegati scaricati — con pulizia automatica. Un sistema che non ha una politica di eliminazione finisce, in sei mesi, per essere un rischio maggiore del problema che doveva risolvere.
Cosa rimane da noi dopo la consegna: Dopo la consegna, il nostro accesso ai tuoi sistemi esiste solo se esiste un contratto di manutenzione che lo richiede, e viene revocato quando esso si conclude. Le copie di lavoro sulle nostre postazioni vengono eliminate su richiesta. Ciò che conserviamo in ogni caso sono i componenti generici che abbiamo scritto e che non contengono i tuoi dati — e quelli li dichiariamo fin dall’inizio, così che non sia una sorpresa alla fine.

Un caso

Un sistema di interrogazione per due portali che non hanno alcuna API

La situazione

Un’agenzia di viaggi aveva bisogno, su richiesta, della disponibilità dei posti e delle tariffe sui voli charter nei portali B2B di due tour operator. I portali sono pensati per l’occhio umano: si accede, si cerca, si legge una tabella. Non esiste un’interfaccia programmatica pubblicata, e l’informazione veniva riletta manualmente, più volte al giorno, da una persona.

Cosa abbiamo costruito

Ho scritto un client che si autentica in modo programmatico e rinnova da solo la sessione quando scade, un analizzatore che trasforma le risposte in oggetti e un livello di identificatori per gli aeroporti, dove il codice è formato da città e porto, e alcune chiamate richiedono le due parti separatamente. Sopra di essi: un comando da riga di comando che restituisce un percorso completo con disponibilità e prezzo, una modalità di richieste in lotto con pause tra esse per evitare che l’account si blocchi, e due punti di ingresso JSON nel caso in cui un’altra piattaforma voglia consumare il risultato. L’analizzatore viene testato su risposte reali, salvate come fixture nel repository, mentre i test che toccano davvero i portali sono marcati separatamente e non vengono eseguiti in modo predefinito.

Cosa è emerso

La suite passa integralmente: 38 verifiche in 0,52 secondi, senza toccare i portali. Una richiesta restituisce, in un’unica risposta, la disponibilità nelle quattro stati usati dal portale e la tariffa con classe e bagaglio, nella valuta richiesta. Il risultato può essere consumato dalla riga di comando, come JSON, oppure tramite i due punti di ingresso HTTP.

Cosa non dice il caso

L’autenticazione programmatica rimane una zona grigia rispetto ai termini di utilizzo dei portali, e questo è scritto nel README del progetto, non scoperto dopo la consegna. Per un volume di produzione intenso, la nostra raccomandazione è esplicita: si richiede l’API ufficiale agli operatori. Il sistema effettua richieste puntuali e inserisce pause tra esse proprio per non diventare uno strumento di estrazione in massa.

Domande

Cosa ci chiedono le persone prima di chiamare

Perché non c’è alcun prezzo su questa pagina?

Perché non potremmo scriverlo onestamente. L’impegno di un sistema su misura è determinato da tre cose che non sappiamo prima di guardare: quanti sistemi esterni bisogna toccare e se qualcuno abbia un’API, quante regole di business esistono già scritte da qualche parte e quante devono essere scoperte dalle persone, e chi mantiene il sistema in vita dopo la consegna. Un numero dato prima di vedere il sistema è una congettura con fattura. Ciò che possiamo fare rapidamente è la prima fase — lettura, delimitazione, scrittura delle regole — che si stima correttamente e resta utile anche se vi fermate lì.

Chi possiede il codice alla fine?

Il codice scritto appositamente per voi è vostro, repository e storico inclusi. Le librerie di terze parti restano sotto le loro licenze — non possiamo cedervele, perché non sono nostre. I nostri componenti riutilizzabili e i nostri prodotti esistenti vengono concessi in licenza per l’uso, non trasferiti; se il vostro lavoro si basa su uno di essi, ve lo diciamo nell’offerta scritta, prima dell’avvio, non nell’ultima riunione.

Cosa succede se vogliamo continuare con qualcun altro?

La consegna deve rendere questo possibile senza di noi, altrimenti non è stata una consegna. Per questo il documento di messa in funzione viene scritto per una macchina vuota e non presuppone nulla dalla nostra testa, mentre i test restano nel repository così che il team successivo sappia cosa si rompe quando modifica. Ciò che non possiamo promettere è che un sistema complesso venga preso in carico senza sforzo — possiamo promettere solo che non gli manca nulla di ciò che serve per essere preso in carico.

Posso vedere un sistema costruito da voi, per giudicare la qualità?

In parte, ed è corretto dire dove si ferma. I sistemi costruiti per i clienti non sono nostri da mostrare, e quelli interni contengono dati reali di business. Ciò che possiamo fare davanti a voi, sullo schermo, è altro: apriamo il repository, vi mostriamo le regole del dominio scritte in testo, eseguiamo le suite di test — 38 in mezzo secondo su uno, 81 in poco più di un secondo su un altro, 44 sul terzo — e leggiamo insieme il codice che fa l’affermazione che mettete in dubbio. Questo sito, a sua volta, è un sistema proprio che può essere ispezionato dall’esterno.

Il nostro vecchio sistema non ha API. Si può fare qualcosa?

Di solito sì, ma con rischio dichiarato. L’ordine è: prima chiediamo se il fornitore ha un’API ufficiale che semplicemente non ha documentato pubblicamente — succede spesso. Se non ce l’ha, si può lavorare tramite autenticazione programmatica, esattamente come un utente, con sessione rinnovata automaticamente; abbiamo costruito così un sistema che interroga due portali B2B. Allora le scriviamo chiaramente che è una zona grigia rispetto alle condizioni d’uso del fornitore e che, per volumi alti, la soluzione sostenibile è chiedere l’API ufficiale. La decisione resta sua, ma informata.

Usate l’intelligenza artificiale per scrivere il codice?

Sì, e non lo nascondiamo. Conta le regole con cui si fa: ogni pezzo di lavoro si chiude con test eseguiti, con verifica dei tipi e con una revisione delle differenze prima del commit, e i limiti sono scritti nel repository — senza pubblicazioni in produzione dall’interno del lavoro, senza modifiche in account esterni, adattatori per fornitori solo con variante di simulazione. Un codice scritto in fretta e non dimostrato è più costoso di uno scritto lentamente. Ciò che vende questo è la velocità nella parte noiosa, non l’assenza di verifica.

Cosa fate quando, a metà, si scopre che l’idea iniziale era sbagliata?

Lo diciamo. In un progetto interno di ingegneria siamo arrivati, dopo la valutazione, a una seconda architettura completamente diversa per lo stesso problema e l’abbiamo scritta come alternativa documentata, con i gate che devono essere superati prima di qualsiasi ordine, invece di continuare sulla prima solo perché era già iniziata. Il costo di un cambio di direzione a metà è inferiore a quello di un sistema consegnato nella forma sbagliata, e la differenza la paga il beneficiario in entrambi i casi.

Quanto grande può essere il lavoro?

A un estremo, un sistema con tre applicazioni e dodici pacchetti comuni in un unico repository, 486 file TypeScript, 68 file di test e 151 commit, con database relazionale, coordinamento effimero separato dalla fonte di verità e contratti comuni tra applicazioni. All’altro estremo, un sistema con un solo processo e venti punti di ingresso, che è esattamente quanto serve. L’ampiezza non è una promessa su qualsiasi dimensione — è l’osservazione che abbiamo lavorato a entrambe le estremità.

Fate anche manutenzione dopo la consegna?

Sì, ma come accordo separato, non come sottinteso. Un sistema su misura ha bisogno di aggiornamenti di sicurezza, del monitoraggio delle modifiche ai fornitori esterni e di qualcuno che guardi i log. Se preferite farlo con il vostro team, la consegna è costruita per poterlo fare. Se preferite che lo facciamo noi, si scrive cosa copre e cosa no — incluso cosa significa «urgente», perché senza definizione questa parola non significa nulla.

Su cosa si basano le affermazioni sopra (15 fonti)

15 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.

Come lavoriamo Tutti i servizi

Cosa vorresti che funzionasse meglio?

Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.

Parliamone