Come le agenzie di sviluppo possono dimostrare la consegna del lavoro con Timestamp GIT

Maya gestisce la delivery in un’agenzia di sviluppo di 14 persone. Martedì scorso, un cliente si è rifiutato di pagare una milestone da 38.000 dollari. La funzionalità era stata rilasciata, i test superati e la pull request era stata mergiata il 14 giugno. Il team procurement del cliente sostiene che la milestone sia arrivata con dieci giorni di ritardo, quindi la fattura dovrebbe essere ridotta.

Maya esporta la cronologia Git dal repository. Mostra il merge esattamente nella data che lei indica. Ma l’avvocato del cliente la liquida con un gesto: «Quello è il tuo server, i tuoi log, le tue date».

È questo il momento in cui Timestamp GIT cambia i termini della discussione.

Timestamp GIT è una GitHub App gestita per agenzie e dev shop che ancora automaticamente ogni hash di commit alla blockchain di Bitcoin. Crea una registrazione immutabile e di terze parti di quando esattamente il lavoro esisteva — senza leggere il codice sorgente, senza installare strumenti CLI sulle macchine degli sviluppatori e senza chiedere a nessuno di diventare un esperto di blockchain.

L’incubo dell’agenzia: quando un cliente contesta la consegna

Per un’agenzia, la contestazione della consegna segue di solito uno schema. Il cliente approva una milestone al kickoff. Il team sviluppa la funzionalità, apre una pull request, ottiene l’approvazione dal product owner del cliente e fa il merge. L’agenzia invia la fattura.

Settimane dopo, il team finanziario del cliente afferma che il lavoro è arrivato in ritardo. Oppure sostiene che la funzionalità era incompleta alla data della milestone e che è stata ricostruita internamente. A volte la contestazione è specifica: «Il modulo dashboard non esisteva il 15».

Il primo istinto dell’agenzia è mostrare il log Git. L’hash del commit c’è. Il timestamp c’è. La cronologia del branch c’è.

Il problema: la cronologia Git standard non è una prova indipendente. Vive su un’infrastruttura che controlli tu. Le date possono essere riscritte, rebasate, forzate con push o ospitate su un server che amministri tu. In una disputa legale o di procurement, l’altra parte può liquidarla come autoreferenziale — perché tecnicamente lo è.

Ciò di cui Maya ha bisogno non è un altro log. Ha bisogno della prova che una specifica impronta digitale del codice esisteva in uno specifico blocco Bitcoin in un momento specifico. Quella prova non può essere modificata, retrodatata o eliminata dall’agenzia, dal cliente o persino dalla piattaforma che l’ha creata.

Timestamp GIT produce quella prova automaticamente.

Perché le agenzie di sviluppo hanno bisogno di una prova crittografica di consegna

Le agenzie affrontano tre rischi correlati che la cronologia Git interna non risolve.

Contestazioni di pagamento

Un cliente può ritardare o ridurre un pagamento sostenendo che una milestone è arrivata in ritardo, incompleta o non è arrivata affatto. Le agenzie spesso accettano un compromesso perché dimostrare la consegna è costoso. Una ricevuta crittografica cambia questo calcolo: il cliente non può contestare quando il commit esisteva quando la prova è ancorata a Bitcoin.

Responsabilità per scadenze mancate

A volte l’agenzia viene accusata di aver causato il mancato lancio di un prodotto. Se la disputa si aggrava, l’agenzia deve mostrare esattamente quali funzionalità sono state completate e in quali date. I timestamp a livello di commit creano una timeline precisa che non dipende dalla parola dell’agenzia.

Contestazioni di inadempimento

Un cliente può sostenere che l’agenzia non ha mai consegnato un determinato codebase, o che ha dovuto ripartire da zero. Gli hash dei commit timestampati collegano il lavoro consegnato a un punto verificabile nel tempo, rendendo queste contestazioni molto più difficili da sostenere.

Le prove tradizionali — email, log interni di project management, screenshot, log di accesso al server — sono spesso trattate come deboli o circostanziali. I timestamp ancorati a Bitcoin sono diversi: sono matematicamente verificabili e immutabili.

Timestamp GIT utilizza un’architettura zero-knowledge. Il codice sorgente dell’agenzia non lascia mai il repository. Timestamp GIT estrae solo l’hash del commit — un’impronta digitale crittografica unica dello stato del repository — e ancora quell’hash a Bitcoin usando il protocollo OpenTimestamps. Il risultato è una ricevuta .ots che può essere verificata contro la blockchain di Bitcoin.

Per un contesto sul perché questo tipo di prova è importante oltre le dispute di consegna, vedi Proof of Existence for Code: What It Is and Why It Matters.

Le garanzie operative contano per le agenzie:

• Integrato in Bitcoin: la prova è pubblica, immutabile e verificabile per sempre.
• Indipendente dal fornitore: la verifica si basa solo su SHA-256 e sui dati dei blocchi Bitcoin. Nessun vincolo proprietario.
• Sicurezza zero-knowledge: Timestamp GIT non vede, copia o memorizza mai il codice sorgente.
• Prove pronte per il tribunale: la prova è una catena crittografica dall’hash del commit al blocco Bitcoin.

Un playbook pratico: configurare Timestamp GIT per la tua agenzia

Il percorso più rapido è la GitHub App in Standard Mode. La configurazione è progettata per essere a manutenzione zero.

Passaggio 1: installa la GitHub App Timestamp GIT

Installa la GitHub App sulla tua organizzazione e concedile accesso ai repository dei clienti che vuoi monitorare. In Standard Mode, l’app legge solo l’hash del commit HEAD di ogni repository monitorato. Non legge il contenuto dei file, i diff delle pull request o il codice sorgente.

L’app richiede accesso in sola lettura al repository sorgente e accesso in lettura-scrittura al repository di destinazione dove verranno archiviate le prove. Puoi conservare le prove in un branch dedicato dello stesso repository o in un repository shadow separato.

Passaggio 2: configura il monitoraggio per i progetti dei clienti

Una volta installata l’app, ogni nuovo commit viene rilevato automaticamente tramite webhook. Non c’è alcun passaggio manuale per commit, nessuno script da eseguire e nessuna configurazione sulle workstation degli sviluppatori.

Passaggio 3: lascia che il worker notturno ancori il lavoro della giornata

Timestamp GIT raggruppa gli hash dei commit in sospeso ogni notte. Crea i file manifest, costruisce un albero di Merkle, genera le prove OpenTimestamps e ancora la radice di Merkle in un blocco Bitcoin.

La conferma su Bitcoin richiede in genere circa tre ore, quindi la consegna della prova non è istantanea. Avviene automaticamente dopo la conferma del blocco.

Passaggio 4: ricevi i file di ricevuta .ots

Timestamp GIT invia il manifest e i file di ricevuta .ots al tuo repository in un branch timestamps dedicato o in un repository shadow. Questi file diventano il tuo archivio di prove a lungo termine.

Passaggio 5: mostra ai clienti la prova di consegna in tempo reale

Non devi dare ai clienti accesso al tuo repository privato. Timestamp GIT fornisce pagine di verifica pubbliche, badge incorporabili, report PDF e un registro di audit CSV.

Ad esempio, puoi interrogare le informazioni sull’ultimo blocco Bitcoin ancorato per un repository:

curl -s https://timestampgit.dev/api/statusLast/acme-agency/client-portal

La dashboard pubblica mostra la data di ancoraggio più vecchia, la regolarità giornaliera, i dati del blocco e della transazione Bitcoin e una heatmap del calendario. I clienti possono usare un link badge per visualizzare lo stato di verifica e scaricare la ricevuta .ots per una verifica indipendente.

Per il flusso di automazione più ampio della GitHub App, vedi Automate Git Commit Timestamping with a GitHub App.

Alternative self-hosted ed enterprise

Se hai bisogno di un deployment air-gapped o self-hosted, Timestamp GIT è disponibile come immagine Docker. Un tipico file Compose si presenta così:

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

Avvialo con:

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

L’app è disponibile su http://localhost:8080. Una procedura guidata di configurazione ti accompagna nella connessione della tua GitHub App e nella configurazione dell’istanza. Una licenza demo a tempo limitato è disponibile dalla pagina Docker License.

Per il massimo isolamento, la Enterprise ZK Mode esegue una GitHub Action di 12 righe sulla tua infrastruttura. Invia solo l’hash del commit all’API di Timestamp GIT, quindi il codice sorgente non lascia mai il tuo ambiente. In questa modalità, Timestamp GIT richiede accesso in lettura-scrittura solo al repository di destinazione — nessun accesso in lettura al repository sorgente.

Se stai valutando l’approccio gestito rispetto alla timestamping manuale, vedi OpenTimestamps Alternative: Managed Timestamping for Git.

Cosa evitare quando si dimostra la consegna del lavoro

Non affidarti esclusivamente alla cronologia Git interna o ai log del server

I log interni possono essere riscritti, retrodatati o contestati come autoreferenziali. Sono utili come prove di supporto, ma non sono prove indipendenti. Ancora l’hash del commit a qualcosa di immutabile.

Evita processi di timestamping manuali

I processi manuali sono soggetti a errori e incoerenti. I team dimenticano di eseguirli, usano il branch sbagliato o perdono le ricevute. Usa l’automazione che cattura ogni commit.

Non esporre il codice sorgente a servizi di timestamping di terze parti

Un sistema di prova di consegna non dovrebbe richiedere il caricamento del codice del cliente su un server esterno. Timestamp GIT elabora solo gli hash dei commit, non il codice sorgente. Il design zero-knowledge protegge sia la tua agenzia sia il tuo cliente.

Non aspettare che sorga una disputa

Quando un cliente sostiene che una milestone non è mai arrivata, è troppo tardi per costruire le prove. Inizia il timestamping dal primo commit così ogni milestone ha una catena ininterrotta di prove.

FAQ

Come fa Timestamp GIT a dimostrare esattamente quando è stato fatto un commit?

Timestamp GIT estrae l’hash del commit — un’impronta digitale unica del tuo codice — e lo ancora alla blockchain di Bitcoin usando il protocollo OpenTimestamps. Il timestamp del blocco Bitcoin fornisce una registrazione immutabile e pubblicamente verificabile dell’esistenza del commit in quel momento.

Un cliente può verificare il timestamp senza accesso al mio repository privato?

Sì. Timestamp GIT fornisce una pagina di verifica pubblica e badge incorporabili. Il cliente può usare il link del badge per visualizzare lo stato di verifica e scaricare la ricevuta .ots, che può essere verificata indipendentemente contro la blockchain di Bitcoin senza esporre il tuo codice sorgente.

Cosa succede se il cliente contesta l’autenticità del timestamp?

Il timestamp è ancorato a Bitcoin, che è matematicamente immutabile. Chiunque può verificare la prova usando la blockchain di Bitcoin e la catena crittografica dal tuo hash di commit al blocco Bitcoin. Quella catena non può essere contraffatta o alterata, rendendo la prova pronta per il tribunale.

Timestamp GIT è adatto ad agenzie che lavorano con più clienti e repository?

Assolutamente. La GitHub App può monitorare più repository nella tua organizzazione. Il piano Pro Agency supporta i repository privati e la dashboard fornisce una panoramica di tutti i commit timestampati, rendendo facile gestire le prove per molti clienti.

Conclusione: rendi le dispute di consegna un ricordo del passato

Per le agenzie e i dev shop, la domanda «quando hai consegnato?» non dovrebbe mai dipendere da quale log del server il cliente sceglie di credere. Timestamp GIT sostituisce quella discussione con una ricevuta ancorata a Bitcoin.

Installa la GitHub App una volta, collega i repository dei tuoi clienti e ogni commit viene automaticamente raggruppato, radicato in un albero di Merkle e ancorato a Bitcoin ogni notte. Le prove arrivano in un branch dedicato o in un repository shadow. Pagine di verifica, badge, report PDF e CSV di audit danno ai tuoi clienti un modo dignitoso di confermare la consegna senza esporre il codice sorgente.

I prezzi partono dal livello Open Source per i repository pubblici, il piano Pro Agency a 49 dollari/mese per i repository privati e Enterprise ZK a 199 dollari/mese per i flussi di lavoro basati su GitHub Actions. Se hai bisogno di un deployment self-hosted, la licenza Docker è disponibile con un’opzione demo.

Inizia con il livello gratuito per repository pubblici o installa la GitHub App per i repository della tua agenzia su timestampgit.dev.

Articoli correlati

• Proof of Existence for Code: What It Is and Why It Matters
• Automate Git Commit Timestamping with a GitHub App
• OpenTimestamps Alternative: Managed Timestamping for Git