Dinghy: la fine della scusa “da me funziona” e del debito tecnico che vi sta dissanguando.

Quella volta alle 3 del mattino in cui tutto è andato a fuoco. Di nuovo.

Ce l'hai presente quella sensazione? Quel misto di gelo e rabbia quando il deploy, quello che "sulla mia macchina andava una bomba", tira giù la produzione alle 3 del mattino. O quando i tuoi passano giorni a fare il giro del fumo per capire perché l'ambiente di sviluppo di Tizio è diverso da quello di Caio e dalla pipeline di CI/CD. Qua in ThinkPink Studio, questo teatrino dell'orrore l'abbiamo visto fin troppe volte. E non è solo una scocciatura. È debito tecnico che si accumula, sono costi che nessuno vede ma che pagate tutti i giorni. È un business che arranca. In un mercato dove chi non corre è morto e la resilienza è l'unica cosa che ti tiene a galla, la scusa dell'ambiente non è più un lusso. È un suicidio aziendale.

Avete presente la vostra cassetta degli attrezzi? È un colabrodo.

Diciamoci la verità. La maggior parte delle software house naviga a vista in una giungla di strumenti che non si parlano tra loro: un tool per i diagrammi, un altro DSL per l'infrastruttura, un sistema per la documentazione che nessuno aggiorna, un altro ancora per le slide. Ognuno vive nel suo piccolo mondo, con la sua toolchain, le sue versioni che cambiano col vento e le sue subdole, maledette, derive. Il risultato non è solo il classico "dependency hell". È un continuo e sfiancante context switching che incenerisce la produttività di chiunque metta mano al codice. È una lezione che si impara sulla propria pelle: il costo reale di un software non è scriverlo. È tenerlo in piedi, aggiornarlo e non farlo andare a gambe all'aria dopo sei mesi. E oggi, nel 2026, con l'AI che riscrive le regole del gioco a ogni ciclo di sviluppo, il problema delle dipendenze si è allargato a macchia d'olio: non sono più solo le librerie, ma i compilatori, gli strumenti di build, gli ambienti, le configurazioni di ogni singolo pezzo dell'infrastruttura.

Dinghy. L'accrocchio geniale che impedisce al vostro software di marcire.

Ecco perché quando abbiamo provato Dinghy, abbiamo capito che la musica stava per cambiare. Dinghy non è l'ennesimo tool luccicante. È una toolchain open-source che lega tutti questi pezzi con lo spago, ma in modo intelligente: una CLI, un'installazione, un unico modo per dire *come codice* cosa vuoi ottenere. Il resto lo fanno gli strumenti. Sotto il cofano girano Deno e Docker, e questo significa che puoi finalmente smettere di fare da babysitter a versioni di Node, virtualenv Python, provider Terraform e tutta la legione di demoni che infesta le vostre dipendenze. Questo non è un capriccio da smanettoni. È una scelta strategica per non ritrovarsi con un pezzo da museo tra 12 mesi, buono solo per essere buttato.

Basta disegnini. L'architettura è codice, il resto è fuffa.

Smettiamola di produrre diagrammi di architettura che sono già vecchi nell'esatto istante in cui li salvate. Con Dinghy, il diagramma diventa "Diagram as Code" (DaC). In pratica, si scrive l'architettura in React TSX e la si renderizza direttamente in draw.io. Sembra una piccolezza, ma non lo è. Il DaC, che nel 2026 è ormai prassi consolidata nei team che non vogliono impazzire, significa avere diagrammi versionati che respirano insieme alla codebase. I vantaggi sono brutali: controllo di versione (diff, blame, history), revisioni tramite pull request, automazione nelle pipeline CI/CD per validare e generare la documentazione da sola. Certo, ci sono tool come PlantUML o Structurizr, ma l'integrazione di Dinghy con React TSX offre una flessibilità che i DSL più rigidi si sognano.

Infrastructure as Code: la rivincita dell'Open Source (e la fine dei ricatti sulle licenze)

Il mercato dell'Infrastructure as Code (IaC) sta esplodendo: da 2,03 miliardi di dollari nel 2026 a 5,25 miliardi previsti per il 2030, con una crescita annua del 26,8%. Il motivo? Multi-cloud, continuous deployment, AI che si fa strada nelle operations. In questo scenario, è successa una cosa interessante. Dopo la mossa arrogante di Terraform con il cambio di licenza a BSL nel 2023 e la successiva acquisizione di HashiCorp da parte di IBM a fine 2024, la community ha reagito. È nato OpenTofu, un fork sotto l'ala della Linux Foundation e della CNCF. Tradotto: un'alternativa veramente open-source, senza padroni e senza sorprese. Ad aprile 2026, OpenTofu si è già preso il 12% del mercato, con un altro 27% di team pronti a migrare. Dinghy sposa questa filosofia al 100%, permettendo di definire l'infrastruttura OpenTofu/Terraform da React TSX e garantendo una migrazione indolore per chi arriva da Terraform. Per chi parte da zero nel 2026, OpenTofu non è più una scommessa, è la scelta di default per non avere rimpianti.

Deno e Docker: la coppia di buttafuori che tiene in ordine l'ambiente.

Il motore di Dinghy è una combinazione letale: Deno e Docker. Deno, creato da quel volpone di Ryan Dahl (il papà di Node.js), è uscito dalla fase "giocattolo per nerd" ed è pronto per la produzione. Nel 2026, Deno significa supporto nativo a TypeScript (basta con le build separate!), un modello di sicurezza che ti obbliga a pensare prima di fare danni e una compatibilità quasi totale con i moduli npm. Certo, l'ecosistema è più giovane di quello di Node.js, ma la velocità con cui gestisce le dipendenze fa impallidire npm. E poi c'è lui, Docker. L'eroe che ha ucciso la frase "da me funziona". Impacchetta l'applicazione e tutte le sue dipendenze in un container che gira uguale ovunque. È la spina dorsale del DevOps moderno. Punto. Con Dinghy, tutto questo viene gestito in un unico posto: un singolo file .dinghyrc blocca le versioni esatte di Deno, Node, OpenTofu e di ogni singolo provider. Una sola "lock" per dire addio per sempre alle dipendenze marce che ti impediscono di ricompilare un progetto dopo due anni.

Non solo codice: siti e slide che non fanno (troppo) schifo.

Dinghy non si ferma all'infrastruttura. Tira su anche un "Site Builder" per creare al volo siti di documentazione con Docusaurus e uno "Slide Builder" per generare presentazioni RevealJS. Estende la filosofia "as Code" a tutto il contorno, garantendo che anche la documentazione e le slide non diventino un cimitero di informazioni obsolete. In un mondo che pretende agilità su tutto, è un vantaggio che si sente.

Come facciamo a non impazzire tra Rosignano e Kampala? Così.

Qui a ThinkPink Studio abbiamo due anime: la pignoleria strategica imparata in Toscana e la capacità di tirare su le cose con quello che c'è, appresa sul campo a Kampala. Questa dualità ci obbliga a cercare soluzioni che non siano solo belle, ma che funzionino, scalino e non ci costringano a bestemmiare tra sei mesi. Vediamo un sacco di PMI italiane che annaspano, schiacciate tra la velocità del cambiamento, i costi e la difficoltà a trovare gente capace. Il nostro team a Kampala, per necessità, è maestro nell'ottimizzare le risorse e nel far funzionare le cose anche quando l'infrastruttura è quello che è. Strumenti come Dinghy sono ossigeno puro per questa filosofia. Implementarlo significa dare a una realtà locale le armi per giocarsela su un mercato globale, costruendo software fatto per durare, non solo per essere venduto.

La scelta è semplice: o gestite la complessità, o la complessità gestirà voi.

In parole povere, Dinghy non è un giocattolo. È una dichiarazione di intenti. È il modo per mettere un punto alla frammentazione e all'obsolescenza che stanno divorando i vostri progetti. Adottare i principi dell'"as Code" su tutta la linea, sfruttando la solidità di Deno e Docker, è l'unica via per avere prevedibilità, riproducibilità e un minimo di sanità mentale. Non è solo un modo migliore per scrivere software. È il modo per scrivere software che non dovrete buttare l'anno prossimo. Smettetela di riempire il cimitero delle dipendenze marce. Se avete bisogno di mettere ordine in questo casino, sapete dove trovarci.