Vai al contenuto principale

Case study

Progetti reali. Risultati misurabili. Ecco come abbiamo aiutato i team a rilasciare software migliore.

Studio di web design · Canale rivenditori

Assistente AI white-label per i clienti di uno studio web

Sfida

Uno studio di web design voleva offrire ai propri clienti un assistente AI che rispondesse alle domande dei visitatori 24 ore su 24. Costruirlo significava allestire per ogni sito una knowledge base, un'integrazione LLM, moderazione, conformità GDPR e isolamento dei dati per cliente. I chatbot generalisti non risolvevano nulla di tutto questo: imponevano il marchio di un fornitore terzo ai clienti dello studio e rispondevano con ciò che riuscivano a raccogliere in rete — inaccettabile per attività che comunicano prezzi e disponibilità.

Approccio

  • Ema Answers fornito come capacità white-label: lo studio rivende con il proprio marchio, e PuglieseWeb non compare mai davanti al cliente finale
  • Un solo tag script per sito — nome dell'attività, colore del brand, avatar e domande suggerite sono configurazione, non un fork
  • Ogni cliente è un tenant separato: knowledge base, conversazioni e lead partizionati per tenant, con blocco per origine e limiti di traffico e di costo per tenant attivi per impostazione predefinita
  • Risposte ancorate esclusivamente ai contenuti approvati dal cliente — protezione contro il prompt injection integrata, e l'assistente passa la mano invece di inventare una risposta
  • Lo studio gestisce contenuti, conversazioni e lead di tutti i clienti da un unico portale, con un numero WhatsApp opzionale per cliente

Risultati

Un nuovo sito cliente va online con l'assistente in pochi minuti — un tag script, nessuna build dedicata
Lo studio vende una capacità AI con il proprio marchio, a margine ricorrente, senza infrastruttura AI da gestire
Le domande fuori orario arrivano come lead qualificati nella casella del cliente
Risposte sempre dentro i contenuti approvati — isolamento per tenant, dati in UE, informativa privacy visibile

Tecnologie

Amazon BedrockAWS LambdaDynamoDBAPI GatewayS3CloudFrontReactTypeScriptPython
Produzione termoidraulica, Italia

Da messaggi vocali a una specifica pronta per lo sviluppo

Sfida

Un produttore italiano stava ingegnerizzando una centralina modulare termoidraulica per il riscaldamento residenziale — un'unità centrale che legge 15 sonde e comanda 11 uscite, con moduli I/O cablati e wireless. L'hardware avanzava, il software di interazione non esisteva, e senza di esso la centralina non era un prodotto vendibile. Il materiale disponibile erano due messaggi vocali, un foglio pin manoscritto e un mockup del monitor — a fronte di un obiettivo di costo di 300–600 € per impianto contro i circa 1.200 € delle schede certificate equivalenti, e di un'interfaccia che deve essere usabile da persone over 60 non tecniche.

Approccio

  • Trascritti integralmente i messaggi vocali del committente e riconciliati riga per riga con lo schema pin manoscritto — ogni canale porta un livello di confidenza esplicito
  • Tradotto "usabile da una persona over 60" in numeri collaudabili: 8 mm di altezza reale delle cifre, aree di tocco da 12 × 12 mm, contrasto WCAG 2.2 AA, verificati sul tablet effettivamente installato
  • Congelato un modello dati che regge qualunque configurazione d'impianto, così che aggiungere un modulo non richieda mai un rilascio dell'app
  • Fissato il confine: la logica di regolazione vive nella centralina, mai nell'app — la casa resta riscaldata anche se cloud, telefono e pannello a muro spariscono
  • Specificato uno strato di astrazione del dispositivo, così che l'intera interfaccia si possa sviluppare e dimostrare su un simulatore prima che l'hardware esista

Risultati

22 questioni tecniche chiuse — ciascuna risolta o ridotta a una singola assunzione dichiarata e contestabile
Due lacune hardware individuate sulla carta e non in cantiere: nessuna uscita per le schermature, nessuna sonda sul puffer che il mockup mostra
Due canali fantasma ricondotti a un errore di lettura della grafia ed eliminati prima di diventare firmware
Interfaccia e firmware procedono ora in parallelo su simulatore, invece che in sequenza dietro l'hardware

Tecnologie

ReactTypeScriptPWAViteESP32-S3RS-485 / Modbus RTUMQTT/TLSAWS (eu-south-1)
Fintech UK

Modernizzazione Pipeline Pagamenti

Sfida

Una fintech britannica gestiva un sistema monolitico di elaborazione pagamenti che non riusciva a scalare oltre i volumi dei giorni di picco. I deploy richiedevano downtime completo e la mancanza di osservabilità rendeva la risposta agli incidenti lenta e soggetta a errori.

Approccio

  • Scomposto il monolite in microservizi event-driven usando SQS, SNS ed EventBridge
  • Implementato retry con backoff esponenziale e dead-letter queue per la resilienza dei pagamenti
  • Introdotto logging strutturato, tracing distribuito e dashboard in tempo reale
  • Migrazione incrementale con il pattern strangler fig — zero downtime durante tutto il processo

Risultati

Aumento di 10 volte del throughput delle transazioni
99,99% di uptime nei primi 12 mesi
Tempo medio di risoluzione (MTTR) ridotto da ore a minuti
Piena conformità PCI DSS mantenuta durante tutta la migrazione

Tecnologie

AWSSQSSNSEventBridgeLambdaDynamoDBCloudWatchPython
SaaS Enterprise

Governance Architetturale per Organizzazione Multi-Team

Sfida

Un'azienda SaaS in crescita con 8 team di ingegneria non aveva standard architetturali condivisi. Ogni team prendeva decisioni tecnologiche indipendenti, causando infrastruttura duplicata, API inconsistenti e debito tecnico crescente che rallentava il rilascio delle funzionalità.

Approccio

  • Stabiliti gli Architecture Decision Record (ADR) come standard per le decisioni cross-team
  • Definiti guardrail architetturali con test di fitness automatizzati nel CI/CD
  • Creata una matrice di conformità che mostra l'aderenza di ogni servizio agli standard condivisi
  • Organizzate revisioni architetturali mensili con i team lead per evolvere gli standard in modo collaborativo

Risultati

Riduzione del 60% dei problemi di integrazione cross-team
Onboarding nuovi servizi 3 volte più veloce con template e guardrail condivisi
Violazioni architetturali rilevate automaticamente nelle PR prima del code review
Backlog del debito tecnico ridotto del 40% nel primo trimestre

Tecnologie

AWSGitHub ActionsTypeScriptPythonCloudFormationSystemDox

Case study

Progetti reali. Risultati misurabili. Ecco come abbiamo aiutato i team a rilasciare software migliore.

Discuti un progetto simile
Basket is empty