NBFire

New Burning Fire — Piattaforma di Gestione Crew di Danza

Cos'è

NBFire è una piattaforma web PWA mobile-first per la gestione di una crew di danza. Sostituisce la comunicazione frammentata tra WhatsApp, fogli Excel e calendari condivisi, centralizzando in un unico posto: gestione membri, calendario eventi, pagamenti condivisi, proposte con votazione, e chat integrata con Telegram.

Il frontend è una SPA Angular 21 con Tailwind CSS, il backend un'API .NET 9 con architettura Clean, chat real-time via SignalR con bridge bidirezionale Telegram, autenticazione Google OAuth, il tutto deployato su VPS Hetzner con Nginx + PM2.

Architettura

graph TB
    subgraph Client["Client — PWA Mobile-First"]
        FE["Angular 21 + Tailwind\nSignals + Standalone"]
    end

    subgraph Server["Hetzner VPS"]
        NGINX["Nginx\nReverse Proxy + SSL"]

        subgraph Backend[".NET 9 — Clean Architecture"]
            API["REST API\nControllers"]
            HUB["SignalR Hub\nReal-time Chat"]
            SVC["Domain Services\nBusiness Logic"]
            EF["EF Core 9\nData Access"]
        end

        DB[("PostgreSQL 16")]
    end

    subgraph External["Servizi Esterni"]
        GOOGLE["Google OAuth 2.0"]
        TELEGRAM["Telegram Bot API"]
        GEMINI["Gemini API\nTraduzioni"]
    end

    FE -->|"HTTPS"| NGINX
    NGINX -->|"/api/*"| API
    NGINX -->|"/hub/*"| HUB
    NGINX -->|"/*"| STATIC["File Statici"]

    API --> SVC
    HUB --> SVC
    SVC --> EF
    EF --> DB

    SVC --> TELEGRAM
    SVC --> GEMINI
    API --> GOOGLE
  

Stima Tempi di Sviluppo

Quanto impiegherebbe un super senior developer .NET/Angular a costruire questo progetto partendo da zero, scrivendo tutto a mano?

Dettaglio per Fase

Dove va il tempo

Il sistema chat (Fase 5) da solo è il ~23% del progetto. Telegram Bot API è la variabile più rischiosa: documentazione non sempre chiara, limiti API, webhook debug. Il primo deploy in produzione rivela sempre problemi invisibili in locale.

Tempo Reale Impiegato (con AI Coding Assistant)

Il progetto è stato costruito da un designer junior che dirigeva un AI coding assistant come sviluppatore AI. L'AI scriveva il codice, l'umano decideva cosa fare, testava su iPhone, e approvava. Dati estratti dalla storia Git: 344 commit, dal 21 dicembre 2025 al 1 febbraio 2026.

Sessioni Giorno per Giorno

Confronto: Senior Umano vs Reale con AI

Confronto per Fase

Osservazioni

1. Boilerplate e codice ripetitivo = 5-6x più veloce. L'AI eccelle nel generare codice strutturato e pattern-based: entità, DTO, servizi CRUD, controllers, test. Il core build (5 Gen, 18:48→19:46) lo dimostra: 7 fasi in 58 minuti.
2. Integrazione API esterne = solo 1.9x. Telegram Bot API e SignalR richiedono debug real-time, test con dati veri, e gestione di edge case che l'AI non può abbreviare. Questa fase da sola ha consumato ~33% del tempo totale.
3. Lo sprint 5-8 Gennaio è stato sovrumano. 4 giorni, 138 commit, il 70% del progetto costruito. Questo volume di codice corretto e testato è fisicamente impossibile senza assistenza AI.
4. Il lavoro umano è stato di direzione, non di esecuzione. Il tempo è stato speso in: decisioni architetturali, prompting, test manuale su iPhone, debug visuale, e approvazione. La scrittura di codice vera e propria è stata minima.
5. I POC hanno risparmiato tempo reale. Validare Telegram prima di costruire (Dic 28-30) ha evitato false partenze e ripensamenti architetturali durante lo sprint di Gennaio.
6. Lo sviluppo non è stato continuativo. 42 giorni di calendario ma solo 16 con attività. Il ritmo era “quando c'era tempo” — weekend, sere, giorni festivi. Un professionista a tempo pieno avrebbe finito in ~2.5 settimane consecutive.