The latest articles on DEV Community by Dev-Iadicola (@dev_iadicola). https://dev.to/dev_iadicola https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F2138925%2F6dd30c44-71a1-4568-a668-759ac9486600.png https://dev.to/dev_iadicola en Dev-Iadicola Fri, 30 Oct 2026 18:00:18 +0000 https://dev.to/dev_iadicola/consulenza-tecnica-web-cosa-aspettarsi-e-come-prepararsi-4gp6 https://dev.to/dev_iadicola/consulenza-tecnica-web-cosa-aspettarsi-e-come-prepararsi-4gp6 <h2> A cosa serve una consulenza tecnica web </h2> <p>Una <strong>consulenza tecnica web</strong> non è una vendita mascherata: è un momento in cui un professionista analizza la situazione attuale, identifica problemi e opportunità, e propone soluzioni concrete con tempi e costi realistici. È il punto di partenza razionale per qualsiasi decisione tecnologica — che si tratti di costruire qualcosa di nuovo, rifare quello che non funziona o decidere se vale la pena intervenire.</p> <p>Serve quando hai un'idea ma non sai da dove partire, quando il sito attuale non funziona come dovrebbe, quando devi decidere se rifare o evolvere quello che hai, o quando vuoi un parere esterno e indipendente prima di investire budget significativo in un progetto.</p> <h3> Quando è il momento giusto per una consulenza? </h3> <p>Il momento migliore è <strong>prima</strong> di prendere decisioni importanti, non dopo. Troppo spesso la consulenza viene richiesta quando il progetto è già in crisi: budget sforato, tempi saltati, fornitore che non consegna. In quel caso la consulenza è comunque utile — ma costa di più correggere errori che prevenirli. Ecco i momenti chiave in cui una consulenza tecnica ha il massimo valore:</p> <ul> <li> <strong>Prima di un nuovo progetto</strong>: per definire architettura, stack tecnologico e roadmap realistica</li> <li> <strong>Quando le performance degradano</strong>: il sito rallenta, il server va in sofferenza, le pagine non si indicizzano</li> <li> <strong>Prima di una migrazione</strong>: cambiare CMS, linguaggio, hosting o fornitore richiede una strategia chiara</li> <li> <strong>Per valutare codice esistente</strong>: code audit per capire la qualità del lavoro fatto da un precedente fornitore</li> <li> <strong>Per formare il team interno</strong>: trasferimento di competenze su best practice, architettura e strumenti moderni</li> </ul> <h2> Cosa aspettarsi da una consulenza tecnica </h2> <p>Una consulenza tecnica seria segue un percorso strutturato. Non è una chiacchierata informale — è un <strong>processo di analisi</strong> che produce output concreti e utilizzabili:</p> <ul> <li> <strong>Analisi dello stato attuale</strong>: revisione del codice sorgente, dell'architettura, delle performance, della sicurezza e della SEO tecnica. Si parte dai dati, non dalle opinioni</li> <li> <strong>Identificazione dei colli di bottiglia</strong>: cosa rallenta il sito? Cosa causa bug ricorrenti? Dove si perde tempo in manutenzione? Ogni problema viene documentato con priorità e impatto</li> <li> <strong>Proposta di intervento</strong>: per ogni problema identificato, una soluzione concreta con stima di effort, costi e tempistiche. Non promesse vaghe, ma numeri realistici</li> <li> <strong>Roadmap prioritizzata</strong>: non tutto si può fare subito. La consulenza produce una mappa degli interventi ordinata per impatto e urgenza, per investire il budget dove genera più valore</li> <li> <strong>Indipendenza totale</strong>: la consulenza è indipendente dalla realizzazione. Il documento di analisi è tuo e puoi usarlo per procedere con qualsiasi fornitore</li> </ul> <h2> Cosa NON è una consulenza tecnica </h2> <p>Per evitare fraintendimenti, è utile chiarire anche cosa una <strong>consulenza tecnica professionale</strong> non include:</p> <ul> <li> <strong>Non è una vendita</strong>: l'obiettivo è darti informazioni per decidere, non convincerti a comprare qualcosa</li> <li> <strong>Non è una stima gratuita</strong>: un'analisi seria richiede tempo e competenza, e ha un costo proporzionato alla complessità</li> <li> <strong>Non è un tutorial</strong>: non è formazione generica, ma analisi specifica del tuo caso</li> <li> <strong>Non è un impegno a procedere</strong>: puoi usare i risultati come vuoi, con chi vuoi</li> </ul> <h2> Come prepararsi per ottenere il massimo </h2> <p>Il valore della consulenza dipende in buona parte dalla qualità delle informazioni che fornisci. Ecco come <strong>prepararsi al meglio</strong>:</p> <h3> Documenti e accessi da preparare </h3> <ul> <li> <strong>Accessi al codice</strong>: repository Git, accesso FTP/SSH, pannello hosting — tutto quello che permette di vedere il codice e l'infrastruttura</li> <li> <strong>Accessi analytics</strong>: Google Analytics, Search Console, eventuali strumenti di monitoring (New Relic, Sentry, etc.)</li> <li> <strong>Documentazione esistente</strong>: specifiche tecniche, wireframe, diagrammi di flusso — anche se datati o incompleti, sono utili</li> <li> <strong>Storico problemi</strong>: lista di bug ricorrenti, lamentele degli utenti, interventi di emergenza passati</li> </ul> <h3> Domande da avere pronte </h3> <p>Più contesto fornisci, più la consulenza sarà utile e mirata. Preparati a rispondere a domande come: quali sono gli <strong>obiettivi di business</strong> del sito? Chi sono gli utenti target? Cosa funziona bene e cosa no? Qual è il budget disponibile per gli interventi? Ci sono vincoli temporali (lancio prodotto, scadenze contrattuali)?</p> <h2> Il deliverable: cosa ricevi alla fine </h2> <p>Una consulenza tecnica professionale produce un <strong>documento di analisi</strong> che tipicamente include:</p> <ul> <li>Executive summary per i decisori non tecnici</li> <li>Analisi tecnica dettagliata per il team di sviluppo</li> <li>Lista problemi con priorità, impatto e costo stimato di risoluzione</li> <li>Roadmap interventi su 3-6-12 mesi</li> <li>Raccomandazioni su stack tecnologico e architettura</li> </ul> <p>Questo documento diventa il tuo riferimento per prendere decisioni informate, confrontare preventivi e monitorare i progressi degli interventi.</p> <h2> Il valore reale: evitare errori costosi </h2> <p>Il valore di una buona consulenza è <strong>evitare errori costosi prima che diventino problemi reali</strong>. Un investimento di poche centinaia di euro in analisi può far risparmiare migliaia di euro in sviluppo sbagliato, migrazioni forzate e rifacimenti. È il tipo di spesa che si ripaga da sola — a patto di farla al momento giusto, con il professionista giusto.</p> <p>Se stai pensando di investire in un progetto web, inizia dalla consulenza. È il passo più razionale e meno rischioso che puoi fare.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/consulenza-tecnica-web-cosa-aspettarsi-e-come-prepararsi?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> architettura business consulenza Dev-Iadicola Thu, 29 Oct 2026 18:00:16 +0000 https://dev.to/dev_iadicola/api-rest-in-php-integrare-sistemi-senza-complicazioni-5cc8 https://dev.to/dev_iadicola/api-rest-in-php-integrare-sistemi-senza-complicazioni-5cc8 <h2> Perché le API sono diventate indispensabili </h2> <p>Quasi nessuna applicazione vive isolata nel 2026. Un gestionale deve parlare con il sistema di fatturazione. Un e-commerce deve inviare ordini al magazzino. Un CRM deve ricevere lead dal sito web. Un'app mobile deve accedere agli stessi dati del pannello admin. Le <strong>API REST</strong> sono il modo standard per far comunicare sistemi diversi senza creare accoppiamenti fragili che si rompono al primo aggiornamento.</p> <p>Progettare una buona API non significa solo esporre endpoint: significa pensare a chi li userà, come gestire gli errori in modo che il client possa reagire sensatamente, come evitare che un cambiamento rompa le integrazioni esistenti e come proteggere i dati in transito. Un'<strong>API ben progettata</strong> è un contratto tra sistemi — e come ogni contratto, deve essere chiaro, completo e rispettato.</p> <h3> Il valore di business delle API </h3> <p>Le API non sono solo un dettaglio tecnico — sono un asset strategico. Un'applicazione con API ben documentate può essere integrata con nuovi sistemi senza toccare il codice esistente. Questo significa che quando il business evolve — un nuovo canale di vendita, un nuovo partner, un nuovo strumento interno — l'integrazione è questione di settimane, non di mesi di sviluppo.</p> <h2> Principi che fanno la differenza in produzione </h2> <p>In teoria le <strong>API REST</strong> sono semplici: risorse, verbi HTTP, JSON. In pratica la differenza tra un'API che funziona e una che crea problemi sta nei dettagli implementativi che emergono solo in produzione, sotto carico reale, con dati reali e integrazioni reali.</p> <h3> Design degli endpoint </h3> <p>Gli endpoint devono essere <strong>coerenti e prevedibili</strong>. Se l'endpoint per gli ordini è <code>/api/v1/orders</code>, quello per i clienti sarà <code>/api/v1/customers</code> — non <code>/api/getClients</code> o <code>/clienti/lista</code>. La coerenza riduce la curva di apprendimento per chi integra e diminuisce gli errori. Usa i verbi HTTP come previsto: GET per leggere, POST per creare, PUT/PATCH per aggiornare, DELETE per eliminare.</p> <h3> Gestione degli errori </h3> <p>I codici di stato HTTP esistono per un motivo: usali correttamente. Un 404 quando la risorsa non esiste, un 422 quando i dati non sono validi, un 401 quando l'autenticazione fallisce, un 429 quando il rate limit è stato superato. Ogni risposta di errore deve includere un messaggio leggibile per l'umano e un codice strutturato per la macchina:</p> <ul> <li> <strong>Codici di stato HTTP corretti</strong>: non restituire sempre 200 con un campo "success: false" — è un anti-pattern che complica ogni integrazione</li> <li> <strong>Messaggi di errore utili</strong>: "Il campo email è obbligatorio" è meglio di "Errore di validazione"</li> <li> <strong>Codici di errore macchina</strong>: un codice come "VALIDATION_ERROR" o "RESOURCE_NOT_FOUND" permette al client di gestire l'errore programmaticamente</li> <li> <strong>Dettagli per il debugging</strong>: in sviluppo, includi stack trace e contesto; in produzione, solo il necessario</li> </ul> <h3> Autenticazione e sicurezza </h3> <p>L'<strong>autenticazione API</strong> è un'area dove i compromessi costano caro. Token JWT con scadenza breve e refresh token sono lo standard per la maggior parte dei casi. Le chiavi API statiche vanno bene per integrazioni server-to-server a basso rischio, ma non per accessi da client. Mai trasmettere credenziali nel query string — finiscono nei log del server, nella cronologia del browser e in ogni proxy intermedio.</p> <p>Oltre all'autenticazione, considera l'autorizzazione: non basta verificare chi sei, serve verificare cosa puoi fare. Un'API ben progettata implementa controlli granulari: questo token può leggere gli ordini ma non cancellarli, quest'altro può creare clienti ma solo nel proprio account.</p> <h2> Versionamento: proteggere le integrazioni esistenti </h2> <p>Quando l'API cambia, le integrazioni vecchie non devono rompersi. Il <strong>versionamento</strong> è il meccanismo che lo garantisce. L'approccio più comune è includere la versione nell'URL (<code>/api/v1/</code>, <code>/api/v2/</code>), ma ci sono alternative valide come il versionamento via header.</p> <p>La regola pratica: mantieni la versione precedente funzionante per almeno 6-12 mesi dopo il rilascio della nuova. Comunica le deprecation in anticipo, fornisci guide di migrazione e dai tempo ai consumer di adeguarsi. Rompere un'integrazione senza preavviso è il modo più veloce per perdere la fiducia dei partner.</p> <h2> Performance e rate limiting </h2> <p>Un'API in produzione deve gestire il carico in modo prevedibile. Il <strong>rate limiting</strong> protegge il server da uso improprio — intenzionale o accidentale — senza penalizzare l'uso normale. Implementalo con header standard (<code>X-RateLimit-Limit</code>, <code>X-RateLimit-Remaining</code>, <code>X-RateLimit-Reset</code>) così i client possono regolarsi autonomamente.</p> <p>Per le performance, considera:</p> <ul> <li> <strong>Paginazione</strong>: non restituire mai dataset interi — usa cursor-based pagination per dataset grandi</li> <li> <strong>Caching</strong>: usa ETag e Last-Modified per evitare trasferimenti inutili</li> <li> <strong>Compressione</strong>: abilita gzip per risposte JSON grandi</li> <li> <strong>Selezione campi</strong>: permetti al client di richiedere solo i campi necessari (<code>?fields=id,name,email</code>)</li> <li> <strong>Eager loading</strong>: offri la possibilità di includere relazioni nella stessa richiesta per evitare il problema N+1</li> </ul> <h2> Documentazione: il ponte tra chi sviluppa e chi integra </h2> <p>Un'API senza documentazione è un'API inutilizzabile. La <strong>documentazione API</strong> deve includere: endpoint disponibili, parametri accettati, formato delle risposte, codici di errore, esempi concreti. Strumenti come OpenAPI/Swagger generano documentazione interattiva che permette di testare le chiamate direttamente dal browser.</p> <p>Un'API ben progettata in <strong>PHP</strong> diventa un asset a lungo termine. Permette integrazioni future senza riscrivere il backend e apre possibilità che al momento del lancio non erano nemmeno previste. E il costo di farla bene dall'inizio è una frazione del costo di aggiustarla dopo, quando decine di client dipendono da un design sbagliato.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/api-rest-php-integrare-sistemi-senza-complicazioni?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> php backend api integrazione Dev-Iadicola Wed, 28 Oct 2026 18:00:18 +0000 https://dev.to/dev_iadicola/migrazione-sito-web-a-php-moderno-guida-pratica-3h53 https://dev.to/dev_iadicola/migrazione-sito-web-a-php-moderno-guida-pratica-3h53 <h2> Perché migrare a PHP moderno </h2> <p>Un sito PHP fermo a versioni obsolete accumula rischi ogni giorno che passa: <strong>vulnerabilità di sicurezza</strong> non più patchate, incompatibilità con hosting moderni, performance degradate e costi di manutenzione crescenti. PHP 5.6 ha raggiunto l'end-of-life nel 2018. PHP 7.4 nel 2022. Eppure, secondo le statistiche di W3Techs, una percentuale significativa di siti web gira ancora su versioni non supportate.</p> <p>Migrare non significa rifare tutto da zero — significa portare il codice a standard attuali in modo controllato, mantenendo funzionalità, dati e posizionamento SEO intatti. È un'operazione chirurgica, non una demolizione.</p> <h3> Cosa rischi a non migrare? </h3> <p>I rischi concreti di restare su PHP obsoleto sono spesso sottovalutati fino a quando non si manifestano:</p> <ul> <li> <strong>Sicurezza</strong>: vulnerabilità note e pubbliche che non ricevono più patch. Un attaccante può sfruttarle con exploit disponibili online</li> <li> <strong>Hosting</strong>: i provider stanno progressivamente eliminando il supporto per PHP 7.x. Alcuni già non offrono più versioni sotto la 8.1</li> <li> <strong>Dipendenze</strong>: librerie e framework rilasciano nuove versioni solo per PHP 8.x+. Restare indietro significa non poter aggiornare nulla</li> <li> <strong>Sviluppatori</strong>: trovare programmatori disposti a lavorare su codice PHP 5.x è sempre più difficile e costoso</li> <li> <strong>Performance</strong>: PHP 8.x è fino a 3-4 volte più veloce di PHP 5.6 per le stesse operazioni, grazie a OPcache migliorato e JIT compilation</li> </ul> <h2> Cosa offre PHP 8.x: non solo velocità </h2> <p><strong>PHP 8.x</strong> ha trasformato il linguaggio in uno strumento di sviluppo moderno e robusto. Le novità non sono cosmetiche — cambiano il modo di scrivere e mantenere codice:</p> <ul> <li> <strong>Tipizzazione forte</strong>: union types, intersection types, readonly properties, enum nativi. Il codice diventa auto-documentante e meno soggetto a bug</li> <li> <strong>Named arguments</strong>: chiamate di funzione leggibili senza dover ricordare l'ordine dei parametri</li> <li> <strong>Match expression</strong>: sostituto moderno di switch-case con return implicito e confronto strict</li> <li> <strong>Fibers</strong>: primitive di concorrenza per operazioni asincrone senza la complessità dei callback</li> <li> <strong>Attributes</strong>: metadati nativi nel linguaggio, sostituto delle annotation docblock</li> <li> <strong>JIT compilation</strong>: miglioramenti di performance significativi per operazioni CPU-intensive</li> </ul> <p>Strumenti di analisi statica come <strong>PHPStan</strong> e <strong>Rector</strong> sfruttano queste funzionalità per individuare bug a tempo di analisi, non a runtime. Il risultato è codice più sicuro, più leggibile e più facile da mantenere.</p> <h2> Fasi della migrazione: il processo passo passo </h2> <p>Una <strong>migrazione PHP</strong> ben eseguita segue un processo strutturato. Non si aggiorna la versione di PHP e si spera che tutto funzioni — si pianifica, si testa e si procede per step controllati:</p> <h3> Fase 1: Audit del codice esistente </h3> <p>Prima di toccare qualsiasi cosa, si analizza lo stato attuale: versione PHP in uso, dipendenze Composer e loro compatibilità, punti critici nel codice (funzioni deprecate, costrutti obsoleti, uso di feature rimosse). Strumenti come <strong>Rector</strong> possono automatizzare questa analisi e generare un report dettagliato delle modifiche necessarie.</p> <h3> Fase 2: Aggiornamento incrementale </h3> <p>Si procede una versione alla volta: da 7.4 a 8.0, poi 8.1, poi 8.2, e così via. Ogni step include: aggiornamento delle dipendenze compatibili, fix delle deprecation, esecuzione della test suite completa. Saltare versioni aumenta esponenzialmente il rischio di regressioni.</p> <h3> Fase 3: Adeguamento del database </h3> <p>Le nuove versioni di PHP e dei driver database (PDO, MySQLi) possono avere comportamenti diversi su: charset e collation, strict mode, prepared statements. Si verifica e si adegua la configurazione per evitare sorprese in produzione.</p> <h3> Fase 4: Preservazione SEO </h3> <p>La migrazione tecnica non deve impattare il posizionamento. Si verificano e si mantengono: <strong>redirect 301</strong> per eventuali URL cambiate, sitemap XML aggiornata, canonical tag invariati, dati strutturati funzionanti, robots.txt corretto. Un check completo con Google Search Console dopo il deploy conferma che tutto è in ordine.</p> <h3> Fase 5: Deploy e monitoring </h3> <p>Il deploy avviene in ambiente di staging prima della produzione. Si monitora: error log, performance (tempi di risposta, uso memoria), funzionalità critiche. Solo dopo 48-72 ore senza problemi si considera la migrazione completata.</p> <h2> Strumenti essenziali per la migrazione </h2> <ul> <li> <strong>Rector</strong>: refactoring automatizzato del codice PHP — aggiorna sintassi, fix deprecation, applica best practice</li> <li> <strong>PHPStan / Psalm</strong>: analisi statica per individuare bug e incompatibilità prima del runtime</li> <li> <strong>PHPUnit</strong>: test suite per verificare che le funzionalità esistenti non si rompano</li> <li> <strong>Composer</strong>: gestione dipendenze con verifica di compatibilità per ogni versione target</li> <li> <strong>Docker</strong>: ambienti di test isolati per ogni versione PHP, senza toccare il server di produzione</li> </ul> <h2> Cosa si guadagna con la migrazione </h2> <p><strong>Performance migliori</strong> (fino a 3-4x), sicurezza aggiornata con patch attive, compatibilità con librerie e framework moderni, e un codice più facile da mantenere ed estendere grazie alle feature del linguaggio moderno. Il costo della migrazione è quasi sempre inferiore al <strong>costo di convivere con codice obsoleto</strong> — soprattutto quando si sommano i rischi di sicurezza, la difficoltà di trovare sviluppatori e l'impossibilità di usare strumenti moderni.</p> <p>Se il tuo sito gira su PHP 7.x o precedente, non è questione di "se" migrare, ma di "quando". E prima lo fai, meno costa e meno rischi accumuli.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/migrazione-sito-web-a-php-moderno-guida-pratica?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> php migrazione performance Dev-Iadicola Tue, 27 Oct 2026 18:00:16 +0000 https://dev.to/dev_iadicola/perche-un-framework-custom-e-non-laravel-4klo https://dev.to/dev_iadicola/perche-un-framework-custom-e-non-laravel-4klo <h2> Non è una questione di meglio o peggio </h2> <p>Laravel è un framework eccellente con un ecosistema enorme. La scelta di costruire Soft PHP MVC non nasce dal volerlo sostituire, ma da esigenze diverse: capire a fondo ogni componente, avere controllo totale sul codice, e dimostrare competenze architetturali concrete.</p> <p>Un framework custom è anche un laboratorio: ogni decisione di design — dal routing al caching, dall'ORM ai middleware — è una scelta consapevole, non un default ereditato.</p> <h2> Cosa guadagno </h2> <ul> <li>Comprensione profonda di ogni layer: routing, ORM, middleware, view</li> <li>Nessuna dipendenza nascosta o magia che non posso debuggare</li> <li>Codebase leggera: solo ciò che serve, niente di più</li> <li>Portfolio tecnico che dimostra capacità reali, non solo uso di strumenti</li> <li>Libertà di sperimentare senza vincoli di backwards compatibility</li> </ul> <p>Il trade-off è chiaro: meno ecosistema, più controllo. Per un progetto personale e portfolio, questo trade-off ha senso.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/perche-un-framework-custom-e-non-laravel?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> php framework architettura Dev-Iadicola Mon, 26 Oct 2026 18:00:17 +0000 https://dev.to/dev_iadicola/come-scegliere-lhosting-giusto-per-il-tuo-progetto-web-k82 https://dev.to/dev_iadicola/come-scegliere-lhosting-giusto-per-il-tuo-progetto-web-k82 <h2> Non tutti i siti hanno bisogno dello stesso hosting </h2> <p>L'hosting è la fondamenta invisibile di ogni sito web. Quando funziona bene non ci si pensa, quando funziona male il sito è lento, va offline nei momenti peggiori e il supporto non risponde. La scelta giusta dipende dal tipo di progetto, dal traffico previsto e da quanta autonomia tecnica si ha — o si è disposti a delegare.</p> <p>Il problema è che le offerte commerciali sono confuse di proposito: spazio "illimitato", performance "garantite", supporto "24/7". Dietro queste promesse la realtà è spesso diversa. Serve tagliare il marketing e guardare i numeri reali: risorse effettive, uptime verificabile, tempi di risposta del supporto e limitazioni scritte in piccolo.</p> <h2> Le tre categorie principali di hosting </h2> <p>Ogni tipo di hosting ha un suo contesto ideale. Scegliere quello sbagliato significa pagare troppo per quello che serve o pagare troppo poco e scoprirlo nel momento peggiore.</p> <h3> Shared hosting (3-10 euro/mese) </h3> <p>Il sito condivide un server fisico con centinaia di altri siti. Ogni sito ha una fetta delle risorse totali, ma i confini non sono rigidi: se il "vicino" ha un picco di traffico, il tuo sito ne risente. È la soluzione più economica e la più semplice da gestire — non serve nessuna competenza tecnica.</p> <p><strong>Quando funziona bene:</strong></p> <ul> <li>Siti vetrina con meno di 500 visite al giorno</li> <li>Blog personali con contenuti statici o quasi</li> <li>Landing page temporanee</li> <li>Siti in fase iniziale con budget minimo</li> </ul> <p><strong>Quando non va bene:</strong></p> <ul> <li>Siti con aree riservate, gestionali o applicazioni web</li> <li>E-commerce o siti con form che generano traffico costante</li> <li>Progetti che richiedono versioni specifiche di PHP, estensioni particolari o configurazioni server custom</li> <li>Siti dove un downtime di ore è un danno economico</li> </ul> <p>I limiti principali sono: impossibilità di configurare il server, versioni PHP spesso datate, performance variabili e condivise, e supporto che risolve solo problemi standard. Il vicino rumoroso ti rallenta e non puoi farci nulla.</p> <h3> VPS — Virtual Private Server (15-50 euro/mese) </h3> <p>Un server virtuale con risorse dedicate e garantite: CPU, RAM e storage sono tuoi e non condivisi. Hai accesso root completo per configurare tutto come serve. È il <strong>rapporto qualità-prezzo migliore per progetti seri</strong> e la scelta che consiglio alla maggior parte dei clienti con siti professionali.</p> <p><strong>Vantaggi concreti:</strong></p> <ul> <li> <strong>Performance prevedibili:</strong> le risorse sono dedicate, il sito non risente del traffico altrui</li> <li> <strong>Libertà di configurazione:</strong> PHP-FPM con pool dedicati, OPcache ottimizzato, Redis per il caching, configurazione Nginx o Apache su misura</li> <li> <strong>Isolamento:</strong> un problema su un altro sito del server non tocca il tuo</li> <li> <strong>Scalabilità verticale:</strong> più RAM, più CPU con un upgrade del piano, senza migrazioni</li> </ul> <p><strong>Il requisito:</strong> serve sapere configurare e mantenere un server Linux, o avere qualcuno che lo faccia. La gestione include aggiornamenti del sistema operativo, configurazione del firewall, monitoraggio delle risorse e backup. Molti provider offrono VPS "managed" che includono la gestione base a un costo leggermente superiore.</p> <p>Provider affidabili nel mercato europeo: <strong>Hetzner</strong> (ottimo rapporto qualità-prezzo, datacenter in Germania e Finlandia), <strong>DigitalOcean</strong> (interfaccia eccellente, documentazione impeccabile), <strong>Contabo</strong> (risorse generose a prezzi bassi), <strong>OVH</strong> (datacenter in Francia, buona opzione per chi vuole dati in UE).</p> <h3> Cloud gestito (30-200+ euro/mese) </h3> <p>Piattaforme come <strong>AWS</strong>, <strong>Google Cloud</strong> o servizi specifici per PHP come <strong>Laravel Forge</strong>, <strong>Ploi</strong> o <strong>ServerPilot</strong> che gestiscono l'infrastruttura al posto tuo. Scalabilità automatica, deploy semplificato, monitoring integrato e pannelli di controllo intuitivi.</p> <p><strong>Quando ha senso:</strong></p> <ul> <li>Il traffico è variabile con picchi imprevedibili (campagne marketing, stagionalità)</li> <li>Il progetto cresce velocemente e le risorse devono scalare senza downtime</li> <li>Si preferisce investire tempo nello sviluppo piuttosto che nella gestione server</li> <li>Serve alta disponibilità con failover automatico</li> </ul> <p>Il costo è più alto, ma include gestione, monitoraggio e spesso supporto specializzato. Per progetti con fatturato che dipende dall'uptime del sito, il costo extra si ripaga alla prima emergenza evitata.</p> <h2> I requisiti non negoziabili, indipendentemente dalla scelta </h2> <p>Qualunque tipo di hosting si scelga, alcune cose non sono opzionali:</p> <ul> <li> <strong>PHP aggiornato:</strong> almeno PHP 8.2 nel 2026. Le versioni precedenti non ricevono più patch di sicurezza e molte librerie moderne le richiedono come requisito minimo</li> <li> <strong>Certificato SSL incluso:</strong> Let's Encrypt è gratuito e quasi tutti gli hosting lo supportano. Se un provider chiede un supplemento per SSL, è un segnale negativo</li> <li> <strong>Backup automatici giornalieri:</strong> gestiti dal provider o configurabili autonomamente. I backup devono essere conservati su storage separato dal server principale</li> <li> <strong>Supporto con tempi umani:</strong> un ticket che riceve risposta dopo 48 ore non è supporto. Per siti business, il supporto deve rispondere entro poche ore, almeno in orario lavorativo</li> <li> <strong>Uptime garantito per contratto:</strong> almeno 99.9% (circa 8 ore di downtime all'anno). Verificare i dati di uptime reali su servizi indipendenti come UptimeRobot o StatusCake</li> <li> <strong>Datacenter in UE:</strong> per conformità GDPR, se il sito tratta dati personali di utenti europei il server dovrebbe essere localizzato nell'Unione Europea</li> </ul> <h2> Come scegliere: la matrice decisionale </h2> <p>La scelta si riduce a tre variabili: <strong>budget</strong>, <strong>competenza tecnica</strong> e <strong>criticità del progetto</strong>. Un sito vetrina di un artigiano con 100 visite al giorno sta benissimo su uno shared hosting da 5 euro. Un e-commerce con 2000 visite giornaliere ha bisogno di un VPS configurato bene. Un'applicazione SaaS con clienti paganti richiede un cloud gestito con alta disponibilità.</p> <p>Un buon hosting costa qualche euro in più al mese ma evita problemi che costano molto di più da risolvere. Risparmiare 10 euro al mese sull'hosting e poi perdere una giornata intera per un downtime non è economia — è un cattivo investimento.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/come-scegliere-hosting-giusto-progetto-web?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> performance infrastruttura Dev-Iadicola Sun, 25 Oct 2026 18:00:16 +0000 https://dev.to/dev_iadicola/sviluppo-api-rest-in-php-quando-serve-e-come-si-struttura-529k https://dev.to/dev_iadicola/sviluppo-api-rest-in-php-quando-serve-e-come-si-struttura-529k <h2> Quando serve un'API REST </h2> <p>Un'<strong>API REST</strong> diventa necessaria quando il backend deve servire più client: un'app mobile, un frontend separato (SPA React, Vue, Angular), un gestionale di terze parti o un'integrazione con servizi esterni. Invece di duplicare la logica di business in ogni client, un'API centralizza dati e regole in un <strong>unico punto di accesso</strong>, garantendo coerenza e riducendo drasticamente la manutenzione.</p> <p>In <strong>PHP moderno</strong>, costruire un'API REST è un'operazione naturale: controller dedicati con single responsibility, middleware per autenticazione e rate limiting, risposte JSON strutturate con codici HTTP semantici, e validazione degli input con regole chiare e messaggi di errore utili.</p> <h3> Scenari concreti in cui un'API è la scelta giusta </h3> <ul> <li> <strong>App mobile + web</strong>: la stessa logica di business serve sia il sito web che l'app iOS/Android. L'API è il punto comune</li> <li> <strong>Frontend SPA</strong>: un frontend React o Vue che comunica con il backend via JSON, per un'esperienza utente più fluida e reattiva</li> <li> <strong>Integrazioni B2B</strong>: partner commerciali, fornitori o clienti che devono accedere a dati o funzionalità in modo automatizzato</li> <li> <strong>Microservizi</strong>: un'architettura dove servizi indipendenti comunicano tra loro via HTTP/REST</li> <li> <strong>Automazioni interne</strong>: script, cron job, webhook e processi automatizzati che interagiscono con il sistema principale</li> </ul> <h2> Come si struttura un'API REST in PHP </h2> <p>La progettazione di un'API REST solida parte da principi architetturali chiari. Non basta restituire JSON da un controller — serve una <strong>struttura coerente e prevedibile</strong> che i client possano consumare con fiducia.</p> <h3> Endpoint RESTful: la convenzione che semplifica tutto </h3> <p>I verbi HTTP hanno un significato preciso in REST:</p> <ul> <li> <strong>GET /api/articles</strong>: lista delle risorse (con paginazione, filtri, ordinamento)</li> <li> <strong>GET /api/articles/{id}</strong>: dettaglio di una singola risorsa</li> <li> <strong>POST /api/articles</strong>: creazione di una nuova risorsa</li> <li> <strong>PUT /api/articles/{id}</strong>: aggiornamento completo di una risorsa esistente</li> <li> <strong>PATCH /api/articles/{id}</strong>: aggiornamento parziale</li> <li> <strong>DELETE /api/articles/{id}</strong>: eliminazione di una risorsa</li> </ul> <p>Questa convenzione rende l'API <strong>auto-documentante</strong>: un client che conosce REST sa già come interagire con le risorse senza leggere pagine di documentazione.</p> <h3> Autenticazione e sicurezza </h3> <p>Un'API pubblica senza autenticazione è un invito agli abusi. Le strategie più comuni in PHP:</p> <ul> <li> <strong>JWT (JSON Web Token)</strong>: token stateless che il client invia nell'header Authorization. Ideale per SPA e app mobile, perché non richiede sessioni server-side</li> <li> <strong>API Key</strong>: chiave univoca per identificare il client. Semplice da implementare, adatta per integrazioni server-to-server</li> <li> <strong>OAuth 2.0</strong>: per scenari più complessi con delegazione di accesso (es. "Login con Google")</li> </ul> <p>Oltre all'autenticazione, una buona API implementa: <strong>rate limiting</strong> per prevenire abusi, CORS configurato correttamente per i client browser, HTTPS obbligatorio, e input sanitization per prevenire injection.</p> <h3> Validazione input: la prima linea di difesa </h3> <p>Ogni dato in ingresso va validato prima di raggiungere la logica di business. In PHP moderno, la validazione si implementa con regole dichiarative:</p> <ul> <li>Tipi di dato (string, int, email, URL, date)</li> <li>Vincoli (required, max length, min value, regex pattern)</li> <li>Relazioni (exists in database, unique, confirmed)</li> </ul> <p>Le risposte di errore seguono un formato standard con <strong>codice HTTP 422</strong> (Unprocessable Entity) e un body JSON che elenca i campi invalidi con messaggi leggibili.</p> <h3> Risposte JSON strutturate </h3> <p>Una buona API restituisce risposte coerenti con <strong>codici di stato HTTP appropriati</strong>:</p> <ul> <li> <strong>200 OK</strong>: richiesta elaborata con successo</li> <li> <strong>201 Created</strong>: risorsa creata con successo (POST)</li> <li> <strong>204 No Content</strong>: operazione riuscita senza body (DELETE)</li> <li> <strong>400 Bad Request</strong>: richiesta malformata</li> <li> <strong>401 Unauthorized</strong>: autenticazione mancante o invalida</li> <li> <strong>403 Forbidden</strong>: autenticato ma non autorizzato</li> <li> <strong>404 Not Found</strong>: risorsa non trovata</li> <li> <strong>429 Too Many Requests</strong>: rate limit superato</li> <li> <strong>500 Internal Server Error</strong>: errore server non gestito</li> </ul> <h2> Versioning: pianificare l'evoluzione </h2> <p>Un'API evolve nel tempo, e i client esistenti non devono rompersi quando si introducono cambiamenti. Il <strong>versioning</strong> è essenziale:</p> <ul> <li> <strong>URL versioning</strong>: /api/v1/articles — semplice e visibile, la scelta più pragmatica</li> <li> <strong>Header versioning</strong>: Accept: application/vnd.api+json;version=1 — più "puro" ma meno immediato</li> </ul> <p>La regola d'oro: le breaking change vanno in una nuova versione. Le aggiunte retrocompatibili (nuovi campi, nuovi endpoint) si possono rilasciare nella versione corrente.</p> <h2> Documentazione: OpenAPI e Swagger </h2> <p>Un'API senza documentazione è un'API che nessuno userà correttamente. Lo standard <strong>OpenAPI (Swagger)</strong> permette di descrivere endpoint, parametri, risposte ed errori in formato machine-readable (YAML/JSON). Da questa specifica si generano automaticamente: documentazione interattiva, client SDK in qualsiasi linguaggio, test di conformità.</p> <p>In PHP, librerie come <strong>L5-Swagger</strong> o <strong>Scribe</strong> generano la specifica OpenAPI direttamente dal codice e dalle annotation, mantenendo documentazione e implementazione sempre sincronizzate.</p> <h2> Vantaggi concreti di un'API REST ben progettata </h2> <p>Un'API ben progettata separa frontend e backend, rende il sistema testabile in isolamento e apre la porta a integrazioni future senza modificare il core. È un <strong>investimento architetturale</strong> che paga nel medio e lungo termine:</p> <ul> <li> <strong>Riusabilità</strong>: la stessa API serve web, mobile, integrazioni e automazioni</li> <li> <strong>Testabilità</strong>: ogni endpoint si testa indipendentemente con test automatizzati</li> <li> <strong>Scalabilità</strong>: frontend e backend scalano indipendentemente</li> <li> <strong>Manutenibilità</strong>: logica centralizzata, modifiche in un solo punto</li> <li> <strong>Time to market</strong>: nuovi client (app mobile, partner) si collegano senza modificare il backend</li> </ul> <p>Se il tuo progetto prevede più di un'interfaccia utente, integrazioni con terze parti o potrebbe evolversi in quella direzione, progettare un'<strong>API REST fin dall'inizio</strong> è la decisione architetturale più lungimirante che puoi prendere.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/sviluppo-api-rest-in-php-quando-serve-e-come-si-struttura?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> php backend apirest Dev-Iadicola Sat, 24 Oct 2026 17:00:16 +0000 https://dev.to/dev_iadicola/manutenzione-software-dopo-il-lancio-cosa-serve-davvero-41m7 https://dev.to/dev_iadicola/manutenzione-software-dopo-il-lancio-cosa-serve-davvero-41m7 <h2> Il lancio non è il traguardo, è il punto di partenza </h2> <p>Molti progetti vengono trattati come se il lancio fosse la fine del lavoro. In realtà è il momento in cui il software inizia a vivere davvero: utenti reali, dati reali, problemi reali. Senza un piano di <strong>manutenzione software</strong>, anche il codice migliore si degrada. Le dipendenze diventano obsolete, le vulnerabilità si accumulano, le performance peggiorano con l'aumentare dei dati, e piccoli bug ignorati diventano problemi strutturali.</p> <p>La manutenzione non è solo "aggiustare bug". È un'attività continuativa che tiene l'applicazione sicura, performante e allineata alle esigenze che evolvono. È tenere aggiornate le dipendenze, monitorare le performance, garantire che i backup funzionino e intervenire quando qualcosa non va — prima che diventi un'emergenza che costa dieci volte tanto.</p> <h3> Quanto costa non fare manutenzione? </h3> <p>Il costo della non-manutenzione è quasi sempre superiore al costo della manutenzione. Un'applicazione PHP non aggiornata per 12 mesi accumula vulnerabilità note, incompatibilità con le nuove versioni delle librerie e debito tecnico che cresce esponenzialmente. Un intervento di emergenza su un sistema trascurato costa tipicamente <strong>3-5 volte</strong> quello che sarebbe costato un piano di manutenzione ordinaria.</p> <p>Peggio ancora, un breach di sicurezza su un sistema non aggiornato può avere conseguenze legali (GDPR), reputazionali e operative che vanno ben oltre il costo tecnico della riparazione.</p> <h2> Le attività che fanno la differenza </h2> <p>Un piano di <strong>manutenzione post-lancio</strong> efficace include attività preventive e reattive. Le preventive evitano i problemi; le reattive li risolvono rapidamente quando si verificano. Ecco cosa non può mancare:</p> <h3> Aggiornamenti di sicurezza </h3> <p>PHP, librerie, framework, sistema operativo — le <strong>vulnerabilità</strong> non aspettano e non chiedono permesso. Ogni dipendenza del progetto è un potenziale vettore di attacco se non viene aggiornata. Un processo strutturato prevede: monitoraggio delle CVE (Common Vulnerabilities and Exposures) rilevanti, aggiornamento in ambiente di staging, test di regressione, deploy in produzione. Cadenza consigliata: almeno una volta al mese per gli aggiornamenti di sicurezza, ogni trimestre per gli aggiornamenti di versione.</p> <h3> Monitoring attivo </h3> <p>Sapere quando il server rallenta prima che lo noti l'utente è la differenza tra manutenzione proattiva e gestione delle emergenze. Un sistema di <strong>monitoring</strong> base include: uptime check (il sito risponde?), tempi di risposta (quanto velocemente?), utilizzo risorse (CPU, memoria, disco), errori applicativi (log degli errori PHP). Strumenti come Uptime Robot per l'uptime e Sentry per gli errori applicativi sono economici e facili da configurare.</p> <h3> Backup verificati </h3> <p>Un <strong>backup che non è mai stato testato non è un backup</strong> — è una speranza. Il piano di backup deve includere: backup automatici giornalieri del database, backup settimanali dell'intero filesystem, retention di almeno 30 giorni, storage in una location diversa dal server di produzione e — fondamentale — test di ripristino periodico. Almeno una volta al trimestre, prova a ripristinare un backup su un ambiente di test e verifica che tutto funzioni.</p> <ul> <li> <strong>Aggiornamenti di sicurezza</strong>: PHP, librerie, sistema operativo — cadenza almeno mensile</li> <li> <strong>Monitoring attivo</strong>: uptime, tempi di risposta, errori applicativi — allarmi automatici</li> <li> <strong>Backup verificati</strong>: automatici, ridondanti e testati regolarmente — non solo configurati</li> <li> <strong>Log review periodico</strong>: i log raccontano problemi che nessuno ha ancora segnalato — analizzali almeno settimanalmente</li> <li> <strong>Performance check</strong>: le query che andavano bene con 1.000 righe possono soffrire con 100.000 — monitora la crescita dei dati</li> <li> <strong>Documentazione aggiornata</strong>: ogni modifica importante va registrata — tra sei mesi non ricorderai perché hai cambiato quella configurazione</li> <li> <strong>Test di regressione</strong>: prima di ogni aggiornamento, verifica che le funzionalità critiche continuino a funzionare</li> </ul> <h2> Tipologie di manutenzione </h2> <p>Non tutta la manutenzione è uguale. Distinguere le tipologie aiuta a pianificare il budget e le risorse:</p> <h3> Manutenzione correttiva </h3> <p>Fix di bug emersi in produzione. È la manutenzione più visibile e urgente. Un buon codice con test automatici riduce drasticamente la quantità di <strong>bug in produzione</strong>, ma non li elimina del tutto — utenti reali trovano sempre edge case che i test non coprono.</p> <h3> Manutenzione adattiva </h3> <p>Aggiornamenti necessari per mantenere la compatibilità: nuove versioni di PHP, aggiornamenti del sistema operativo, modifiche alle API di servizi esterni. Non aggiunge funzionalità, ma evita che l'applicazione diventi incompatibile con il suo ambiente.</p> <h3> Manutenzione evolutiva </h3> <p>Nuove funzionalità, miglioramenti all'interfaccia, ottimizzazioni. È la manutenzione che risponde all'evoluzione delle esigenze di business. Un'applicazione che non evolve è un'applicazione che sta morendo lentamente.</p> <h3> Manutenzione preventiva </h3> <p>Refactoring, ottimizzazione delle performance, miglioramento della copertura di test. Non risolve problemi visibili, ma previene quelli futuri. È la manutenzione più difficile da giustificare al budget, ma la più importante nel lungo termine.</p> <h2> Quanto costa un piano di manutenzione </h2> <p>Un piano di <strong>manutenzione ordinaria</strong> per un'applicazione web di media complessità richiede tipicamente tra le 4 e le 12 ore al mese: aggiornamenti di sicurezza, monitoring, review dei log, piccoli fix. A tariffa freelance, questo si traduce in un costo mensile tra i 200 e i 600 euro — una frazione del costo di sviluppo iniziale e molto meno di un intervento di emergenza.</p> <p>Un buon contratto di manutenzione non è un costo: è un'assicurazione. Costa molto meno di un intervento di emergenza su un sistema che nessuno ha toccato per un anno. E come tutte le assicurazioni, il momento migliore per attivarla è prima che serva.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/manutenzione-software-dopo-il-lancio-cosa-serve?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> produzione freelance Dev-Iadicola Fri, 23 Oct 2026 17:00:17 +0000 https://dev.to/dev_iadicola/il-sito-e-stato-hackerato-cosa-fare-subito-3gdg https://dev.to/dev_iadicola/il-sito-e-stato-hackerato-cosa-fare-subito-3gdg <h2> Niente panico, ma agisci adesso </h2> <p>Redirect verso siti sconosciuti, pagine in lingue che non c'entrano nulla, avvisi di Google che segnalano malware, clienti che ricevono email strane dal tuo dominio, un banner rosso nel browser che dice "Questo sito potrebbe essere pericoloso". Se stai vedendo uno di questi sintomi, il sito è probabilmente compromesso. Ogni minuto che il sito resta online in questo stato fa danni: ai tuoi visitatori, alla tua reputazione e al tuo posizionamento su Google.</p> <p>Non importa come è successo — quello lo analizzerai dopo. Adesso serve contenere il danno e ripristinare. Ecco cosa fare, nell'ordine giusto, passo dopo passo.</p> <h2> Passo 1: metti il sito offline immediatamente </h2> <p>Sostituisci il sito con una <strong>pagina di manutenzione statica</strong> — un singolo file HTML che dice "Sito in manutenzione, torneremo presto". Questo ferma il danno in tre modi: impedisce che i visitatori vengano infettati o reindirizzati, ferma il peggioramento della reputazione su Google e blocca l'attaccante dall'usare il sito per distribuire malware o spam.</p> <p>Se hai accesso al pannello hosting, puoi attivare una "maintenance page" con un click. Se hai accesso SSH, rinomina la cartella del sito e metti al suo posto una cartella con il solo file <code>index.html</code> di manutenzione. Meglio un sito offline per qualche ora che un sito che distribuisce malware ai tuoi clienti.</p> <h2> Passo 2: cambia tutte le password — tutte </h2> <p>Non solo quella dell'admin del sito. <strong>Tutte le credenziali</strong> associate al progetto:</p> <ul> <li>Pannello di controllo dell'hosting (cPanel, Plesk, pannello del provider)</li> <li>Accesso FTP e SFTP</li> <li>Database MySQL/MariaDB (utente dell'applicazione e utente root)</li> <li>Pannello admin del CMS (WordPress, gestionale, qualsiasi backend)</li> <li>Email associate al dominio</li> <li>Accesso SSH (meglio: disabilita l'accesso con password e usa solo chiavi SSH)</li> <li>Account di servizi terzi collegati (SMTP, CDN, analytics)</li> </ul> <p>Usa password lunghe (almeno 20 caratteri) e uniche, generate da un password manager come Bitwarden o 1Password. Se l'attaccante ha ancora le vecchie credenziali, ogni altra operazione è inutile.</p> <h2> Passo 3: identifica il punto di ingresso </h2> <p>Capire come sono entrati è fondamentale per impedire che succeda di nuovo. Le verifiche da fare:</p> <ul> <li> <strong>File modificati di recente:</strong> <code>find /var/www/sito -type f -mtime -7 -name "*.php"</code> mostra tutti i file PHP modificati negli ultimi 7 giorni. File sospetti nelle cartelle di upload (<code>wp-content/uploads/</code>, <code>public/uploads/</code>) sono un segnale classico</li> <li> <strong>File con nomi sospetti:</strong> cerca file come <code>shell.php</code>, <code>c99.php</code>, <code>wp-config-backup.php</code> o file con nomi casuali nelle cartelle di upload. Usa <code>find . -name "*.php" -path "*/uploads/*"</code> per trovarli</li> <li> <strong>Utenti admin nel database:</strong> controlla la tabella degli utenti del CMS. Utenti admin che non riconosci sono stati creati dall'attaccante</li> <li> <strong>Log del server:</strong> i file di access log e error log contengono tracce dell'attacco. Cerca richieste POST verso file sospetti, accessi a URL anomali, e pattern di richieste automatizzate</li> <li> <strong>Cron job:</strong> verifica che non siano stati aggiunti cron job malevoli che scaricano e rieseguono il malware periodicamente. Controlla con <code>crontab -l</code> e nelle cartelle <code>/etc/cron.*</code> </li> </ul> <h2> Passo 4: ripristina da un backup pulito </h2> <p>Se hai un <strong>backup recente verificato</strong> antecedente alla compromissione, ripristinalo. È il modo più sicuro per eliminare qualsiasi codice malevolo, inclusi eventuali backdoor nascoste che una pulizia manuale potrebbe non individuare.</p> <p>Se non hai backup (o non sai quando è avvenuta la compromissione), dovrai pulire manualmente: analizzare ogni file PHP sospetto, confrontare i file del CMS con la versione originale, controllare il database per contenuti iniettati. È un lavoro lungo, meticoloso e rischioso — se non hai esperienza specifica, è il momento di chiamare un professionista.</p> <h2> Passo 5: aggiorna tutto e chiudi le falle </h2> <p>La vulnerabilità che ha permesso l'accesso è quasi certamente in un componente non aggiornato. Dopo il ripristino:</p> <ul> <li> <strong>Aggiorna PHP</strong> all'ultima versione stabile supportata</li> <li> <strong>Aggiorna il CMS</strong> e tutti i plugin/temi all'ultima versione</li> <li> <strong>Rimuovi plugin e temi inutilizzati:</strong> ogni componente presente è una potenziale superficie di attacco</li> <li> <strong>Verifica i permessi dei file:</strong> cartelle a 755, file a 644, file di configurazione a 600. Mai 777 su nulla</li> <li> <strong>Implementa un WAF</strong> (Web Application Firewall): servizi come Cloudflare (gratuito nel piano base) filtrano il traffico malevolo prima che raggiunga il server</li> </ul> <h2> Passo 6: chiedi la revisione a Google </h2> <p>Se il sito è stato segnalato come pericoloso nei risultati di ricerca o nel browser, usa <strong>Google Search Console</strong> per richiedere una revisione dopo la pulizia. Google verificherà che il malware sia stato rimosso e rimuoverà l'avviso. Il processo richiede di solito 24-72 ore. Nel frattempo il sito funziona ma con il banner di avviso che scoraggia i visitatori — motivo in più per agire rapidamente.</p> <h2> Dopo la crisi: investire nella prevenzione </h2> <p>Una volta risolto il problema immediato, investi nella prevenzione per non trovarti nella stessa situazione:</p> <ul> <li> <strong>Backup automatici giornalieri</strong> conservati su storage esterno al server</li> <li> <strong>Aggiornamenti automatici</strong> almeno per le patch di sicurezza</li> <li> <strong>Monitoring attivo:</strong> servizi come UptimeRobot (gratuito) che ti avvisano se il sito va offline, e file integrity monitoring che segnala modifiche sospette ai file</li> <li> <strong>2FA su tutti gli account admin</strong> per rendere inutili le password rubate</li> <li> <strong>Audit di sicurezza periodico:</strong> una volta ogni 6 mesi, verificare aggiornamenti, permessi, configurazioni e log</li> </ul> <p>Costa molto meno prevenire che ripulire. Un setup di sicurezza base richiede poche ore di configurazione e un costo mensile trascurabile. Ripulire un sito compromesso richiede giorni di lavoro e il danno reputazionale può durare mesi.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/sito-hackerato-cosa-fare-subito?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> diagnosi sicurezza Dev-Iadicola Thu, 22 Oct 2026 17:00:17 +0000 https://dev.to/dev_iadicola/testare-un-mvc-custom-con-phpunit-36gj https://dev.to/dev_iadicola/testare-un-mvc-custom-con-phpunit-36gj <h2> 635 test e counting </h2> <p>La test suite del framework conta oltre 635 test organizzati per area: Unit per helper, modelli e query builder; Integration per il flusso completo con database reale. Tutti girano con <code>php soft test</code> o direttamente con <code>vendor/bin/phpunit</code>.</p> <p>Testare un framework custom è doppiamente importante: non c'è una community che trova i bug per te. Ogni feature nuova arriva con i suoi test, e Rector + PHPStan completano il quadro della qualità del codice.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/testare-un-mvc-custom-con-phpunit?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> php testing codequality Dev-Iadicola Wed, 21 Oct 2026 17:00:17 +0000 https://dev.to/dev_iadicola/quanto-costa-un-sito-web-custom-fattori-reali-2f7b https://dev.to/dev_iadicola/quanto-costa-un-sito-web-custom-fattori-reali-2f7b <h2> Perché non esiste un prezzo fisso per un sito web </h2> <p>La domanda più frequente è anche la più difficile: <strong>quanto costa un sito web custom?</strong> La risposta onesta è che dipende da cosa serve davvero. Un sito vetrina con cinque pagine ha costi molto diversi da un portale con area riservata, gestionale integrato e API per app mobile. Chiunque dia un prezzo senza aver fatto domande sta tirando a indovinare — o peggio, sta vendendo un pacchetto standard spacciandolo per custom.</p> <p>Quello che conta non è il prezzo al chilo, ma capire <strong>cosa influenza il costo</strong> e dove ha senso investire. Un sito web è un asset di business, non una commodity: il suo valore si misura nel ritorno che genera, non solo nel costo di produzione.</p> <h3> La trappola del "sito a 500 euro" </h3> <p>Il mercato è pieno di offerte a basso costo per siti web. È importante capire cosa si ottiene: tipicamente un template WordPress preconfigurato, con contenuti inseriti dal cliente, nessuna ottimizzazione SEO seria, nessun supporto post-lancio. Per alcune esigenze può bastare, ma non è un sito custom — è un prodotto standardizzato venduto come personalizzato.</p> <p>Il <strong>sito web su misura</strong> è un'altra cosa: architettura progettata sulle esigenze specifiche, codice scritto ad hoc, performance ottimizzate, SEO tecnica nativa e un professionista che risponde delle scelte fatte.</p> <h2> I fattori che determinano il costo </h2> <h3> 1. Complessità funzionale </h3> <p>Questo è il fattore principale. Ogni funzionalità richiede progettazione, sviluppo, testing e manutenzione. Ecco come varia il costo in base alle funzionalità:</p> <ul> <li> <strong>Sito vetrina</strong> (5-10 pagine, form contatti, mappa): il livello base. Ore di sviluppo contenute, costo proporzionato</li> <li> <strong>Blog/portfolio dinamico</strong> (CMS custom, categorie, tag, ricerca): aggiunge un pannello admin e la gestione contenuti</li> <li> <strong>Area riservata</strong> (registrazione, login, profilo utente, dashboard): autenticazione, gestione sessioni, sicurezza — complessità significativa</li> <li> <strong>E-commerce</strong> (catalogo, carrello, pagamenti, ordini): il livello più complesso, con integrazioni gateway e logistica</li> <li> <strong>Integrazioni esterne</strong> (API terze parti, CRM, fatturazione, email marketing): ogni integrazione è un progetto nel progetto</li> </ul> <h3> 2. Design e interfaccia utente </h3> <p>Il design impatta significativamente sul costo:</p> <ul> <li> <strong>Template adattato</strong>: si parte da un design esistente e si personalizza. Costo inferiore, risultato meno unico</li> <li> <strong>Design originale su misura</strong>: wireframe, mockup, revisioni, design system. Investimento maggiore, identità visiva unica e coerente</li> <li> <strong>Animazioni e interazioni avanzate</strong>: microinterazioni, scroll animation, transizioni custom. Richiedono competenze specifiche e tempo di sviluppo aggiuntivo</li> </ul> <h3> 3. Contenuti </h3> <p>Un aspetto spesso sottovalutato nei preventivi: <strong>chi produce i contenuti?</strong> Testi, immagini, video, schede prodotto — se il cliente non li ha pronti, qualcuno deve crearli. La copywriting professionale per un sito di 10 pagine può richiedere 20-40 ore di lavoro tra ricerca, scrittura e revisioni. Contenuti SEO-oriented richiedono competenze specifiche di keyword research e content strategy.</p> <h3> 4. SEO tecnica e performance </h3> <p>L'ottimizzazione SEO non è un add-on: è parte integrante dello sviluppo. Ma il livello di profondità varia:</p> <ul> <li> <strong>SEO base</strong>: meta tag, sitemap, robots.txt, URL puliti — incluso nello sviluppo standard</li> <li> <strong>SEO avanzata</strong>: dati strutturati Schema.org, ottimizzazione Core Web Vitals, internal linking strategy, canonical e hreflang — richiede analisi e implementazione dedicate</li> <li> <strong>Content SEO</strong>: keyword research, content plan, ottimizzazione dei testi per le ricerche target — un lavoro continuativo nel tempo</li> </ul> <h3> 5. Infrastruttura e hosting </h3> <p>Il costo dell'hosting è spesso trascurato nel preventivo iniziale, ma impatta sulla performance e sulla manutenzione:</p> <ul> <li> <strong>Shared hosting</strong>: il più economico (50-200 euro/anno), adeguato per siti con traffico contenuto</li> <li> <strong>VPS/Cloud</strong>: più performance e controllo (200-1000 euro/anno), necessario per applicativi con database e traffico medio-alto</li> <li> <strong>Server dedicato/gestito</strong>: per applicazioni mission-critical con requisiti di performance e sicurezza elevati</li> </ul> <h2> Range di costo realistici nel 2026 </h2> <p>Premessa: queste cifre si riferiscono al lavoro di un <strong>freelance PHP specializzato</strong> in Italia. Agenzie e team strutturati hanno costi superiori per i motivi descritti nell'articolo dedicato.</p> <ul> <li> <strong>Sito vetrina professionale</strong> (5-10 pagine, form, responsive, SEO base): 2.000 - 5.000 euro</li> <li> <strong>Sito con blog/CMS custom</strong> (pannello admin, gestione contenuti, categorie): 4.000 - 8.000 euro</li> <li> <strong>Portale con area riservata</strong> (autenticazione, dashboard, ruoli): 6.000 - 15.000 euro</li> <li> <strong>E-commerce custom</strong> (catalogo, carrello, pagamenti, ordini): 10.000 - 25.000+ euro</li> <li> <strong>Gestionale web su misura</strong>: 8.000 - 30.000+ euro a seconda della complessità</li> </ul> <p>Questi range danno un ordine di grandezza, ma ogni progetto ha le sue specificità. Un preventivo serio richiede sempre un'<strong>analisi delle esigenze</strong> — non un listino prezzi.</p> <h2> Come leggere un preventivo per un sito web </h2> <p>Un buon preventivo per un <strong>sito web custom</strong> dovrebbe includere:</p> <ul> <li>Elenco dettagliato delle funzionalità incluse (e di quelle escluse)</li> <li>Numero di revisioni previste per il design</li> <li>Chi si occupa dei contenuti (testi, immagini, video)</li> <li>Cosa include la manutenzione post-lancio e per quanto tempo</li> <li>Costi ricorrenti (hosting, dominio, certificato SSL, eventuali licenze)</li> <li>Tempistiche di consegna con milestones intermedie</li> <li>Condizioni di pagamento (anticipo, stato avanzamento, saldo)</li> </ul> <p>Diffida di preventivi che non specificano cosa è incluso e cosa no. Le sorprese in corso d'opera sono quasi sempre a sfavore del cliente.</p> <h2> Investimento, non costo </h2> <p>Un <strong>sito web custom</strong> non è una spesa: è un investimento che genera valore nel tempo. Un sito che converte visitatori in contatti, che si posiziona bene su Google, che rappresenta il brand in modo professionale — questo ha un ritorno misurabile. Un preventivo serio parte sempre da un'analisi delle esigenze, non da un listino. Diffida di chi dà un prezzo senza aver fatto domande.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/quanto-costa-un-sito-web-custom-fattori-reali?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> webcustom business consulenza Dev-Iadicola Tue, 20 Oct 2026 17:00:15 +0000 https://dev.to/dev_iadicola/quanto-tempo-serve-per-realizzare-un-sito-web-custom-2d47 https://dev.to/dev_iadicola/quanto-tempo-serve-per-realizzare-un-sito-web-custom-2d47 <h2> La risposta breve: dipende, ma ecco i numeri reali </h2> <p>Un sito vetrina custom richiede in media <strong>3-5 settimane</strong> di lavoro effettivo. Un progetto con area admin, gestionale o funzionalità avanzate può richiedere <strong>6-12 settimane</strong>. Un e-commerce custom o una web application complessa possono arrivare a 3-6 mesi. Ma la variabile più importante non è la complessità tecnica — è la <strong>chiarezza dei requisiti</strong> iniziali e la velocità dei feedback durante lo sviluppo.</p> <p>Questi numeri si basano sulla mia esperienza diretta come sviluppatore PHP freelance su decine di progetti custom. Non sono stime teoriche: sono tempistiche reali, misurate su progetti consegnati e funzionanti.</p> <h2> Cosa influenza i tempi di realizzazione di un sito web? </h2> <p>Le tempistiche di sviluppo di un sito web custom dipendono da una combinazione di fattori tecnici e organizzativi. Ecco i principali, in ordine di impatto:</p> <h3> 1. Definizione dei contenuti </h3> <p>Se testi, immagini, loghi e materiali sono pronti prima dell'inizio dello sviluppo, si parte subito con il layout e la struttura. Se invece i contenuti arrivano a pezzi durante il progetto, ogni consegna parziale genera un ciclo di revisione aggiuntivo. Nella mia esperienza, <strong>il ritardo più comune nei progetti web non è tecnico: è legato ai contenuti</strong>. Preparare tutto prima di iniziare può ridurre i tempi del 30-40%.</p> <h3> 2. Numero e qualità delle revisioni </h3> <p>Feedback rapidi, specifici e mirati accorciano drasticamente i tempi. Un commento come "non mi piace il colore del bottone, preferisco un blu più scuro come questo riferimento" si risolve in 5 minuti. Un commento come "non mi convince, rivedi tutto" può costare giorni di lavoro e fraintendimenti. Stabilire un processo di revisione chiaro — con strumenti come annotazioni su screenshot, video Loom o documenti condivisi — fa la differenza.</p> <h3> 3. Funzionalità speciali e integrazioni </h3> <p>Ogni funzionalità aggiuntiva rispetto a un sito vetrina standard aggiunge tempo di sviluppo:</p> <ul> <li> <strong>Form avanzati</strong> con logica condizionale, upload file, validazione complessa: 2-5 giorni</li> <li> <strong>Area riservata</strong> con login, ruoli utente, dashboard: 5-10 giorni</li> <li> <strong>Integrazioni API</strong> con CRM, ERP, sistemi di pagamento: 3-8 giorni per integrazione</li> <li> <strong>Pannello admin custom</strong> per gestione contenuti: 5-15 giorni a seconda della complessità</li> <li> <strong>Multilingua</strong> con gestione traduzioni: 3-7 giorni</li> </ul> <h3> 4. Design: da zero o su base esistente? </h3> <p>Un layout creato da zero a partire da un brief richiede più tempo rispetto all'adattamento di una direzione grafica già definita. Se hai già un brand manual, dei mockup Figma o dei riferimenti visivi chiari, lo sviluppatore può procedere più velocemente. Se invece il design va ideato insieme, aggiungi 1-2 settimane per wireframe, proposte grafiche e approvazioni.</p> <h2> Come velocizzare il progetto senza sacrificare la qualità </h2> <p>Il modo migliore per rispettare i tempi è partire con un <strong>brief chiaro e completo</strong>. Ecco una checklist pratica:</p> <ul> <li>Definisci gli <strong>obiettivi del sito</strong>: cosa deve fare, per chi, quale azione deve compiere il visitatore</li> <li>Prepara i <strong>contenuti</strong> prima di iniziare: testi definitivi, immagini in alta risoluzione, logo in formato vettoriale</li> <li>Elenca le <strong>funzionalità necessarie</strong> in ordine di priorità: distingui tra "must have" e "nice to have"</li> <li>Indica <strong>riferimenti visivi</strong>: siti che ti piacciono e perché, colori del brand, stile desiderato</li> <li>Stabilisci un <strong>referente unico</strong> per le approvazioni: evita il "chiedo al collega che torna lunedì"</li> <li>Concorda <strong>tempistiche di feedback</strong>: rispondere entro 48 ore tiene il progetto in carreggiata</li> </ul> <h2> Tempistiche reali per tipologia di progetto </h2> <p>Ecco una stima basata su progetti reali che ho seguito come freelance PHP:</p> <ul> <li> <strong>Landing page</strong> singola con form di contatto: 1-2 settimane</li> <li> <strong>Sito vetrina</strong> 5-8 pagine con design responsive: 3-5 settimane</li> <li> <strong>Blog o magazine</strong> con pannello admin per gli articoli: 4-6 settimane</li> <li> <strong>Sito con area riservata</strong> e funzionalità custom: 6-10 settimane</li> <li> <strong>Web application</strong> gestionale o e-commerce: 8-16 settimane</li> </ul> <h2> Perché le stime "in 3 giorni ti faccio il sito" sono un red flag </h2> <p>Se qualcuno ti promette un sito custom in pochi giorni, probabilmente sta usando un template preconfezionato con personalizzazioni minime. Non c'è nulla di male nei template, ma <strong>non è la stessa cosa di un sito custom</strong>. Un progetto su misura richiede analisi, progettazione, sviluppo, test e deploy — e ognuna di queste fasi ha bisogno del suo tempo.</p> <p>Un buon sviluppatore ti dà una <strong>timeline realistica</strong>, con milestone chiare e margine per gli imprevisti. Non una promessa irrealizzabile che genera frustrazione a progetto avviato. Meglio un preventivo onesto che un'illusione che si scontra con la realtà dopo due settimane.</p> <h2> Il consiglio pratico </h2> <p>Se stai valutando un progetto web custom, il primo passo non è cercare lo sviluppatore: è <strong>definire cosa ti serve davvero</strong>. Più il brief è chiaro, più il preventivo sarà preciso, i tempi realistici e il risultato allineato alle aspettative. E se non sai da dove partire, un buon freelance ti aiuta anche in quella fase — perché definire i requisiti fa parte del lavoro.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/quanto-tempo-serve-per-realizzare-un-sito-web-custom?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> webcustom business faq Dev-Iadicola Mon, 19 Oct 2026 17:00:15 +0000 https://dev.to/dev_iadicola/cosa-succede-dopo-la-consegna-del-sito-24i9 https://dev.to/dev_iadicola/cosa-succede-dopo-la-consegna-del-sito-24i9 <h2> Il sito non finisce alla consegna: è solo l'inizio </h2> <p>Un sito web non è un prodotto che si consegna e si dimentica. Dopo il lancio servono <strong>aggiornamenti di sicurezza</strong>, piccole correzioni, nuovi contenuti e a volte nuove funzionalità. La domanda giusta non è "cosa succede dopo" ma "chi se ne occupa, come e con quali costi". È una domanda che andrebbe fatta <strong>prima</strong> di iniziare il progetto, non dopo la consegna.</p> <p>Nella mia esperienza come sviluppatore PHP freelance, i clienti che pianificano la fase post-lancio fin dall'inizio ottengono risultati migliori: meno downtime, contenuti sempre aggiornati, nessuna sorpresa sui costi. Chi invece tratta il sito come un progetto "chiavi in mano" si ritrova spesso con un sito obsoleto dopo pochi mesi.</p> <h2> Cosa include la manutenzione di un sito web? </h2> <p>La manutenzione di un sito web comprende attività diverse, con frequenze e priorità differenti. Ecco le principali:</p> <h3> Aggiornamenti di sicurezza </h3> <p>Ogni software ha vulnerabilità che vengono scoperte nel tempo. Le <strong>patch di sicurezza</strong> per PHP, le dipendenze del progetto, i certificati SSL e la configurazione del server vanno aggiornati regolarmente. Un sito non aggiornato è un bersaglio facile per attacchi automatizzati che scandagliano la rete 24/7. Non si tratta di "se" verrà attaccato, ma di "quando".</p> <p>Gli aggiornamenti di sicurezza dovrebbero avvenire almeno <strong>una volta al mese</strong>, con interventi immediati per vulnerabilità critiche (CVE ad alta severità).</p> <h3> Backup regolari e testati </h3> <p>Un backup che non è mai stato testato non è un backup: è una speranza. La strategia corretta prevede:</p> <ul> <li> <strong>Backup automatici</strong> giornalieri del database e settimanali dei file</li> <li> <strong>Retention</strong> di almeno 30 giorni: poter tornare indietro di un giorno non basta se il problema è stato introdotto una settimana fa</li> <li> <strong>Test di ripristino</strong> periodici: almeno ogni 3 mesi, verificare che il backup sia effettivamente utilizzabile</li> <li> <strong>Backup off-site</strong>: su un server diverso da quello di produzione, per proteggersi da guasti hardware</li> </ul> <h3> Monitoraggio uptime e performance </h3> <p>Sapere subito se qualcosa smette di funzionare è fondamentale. Un sito down per ore senza che nessuno se ne accorga significa clienti persi e danni alla reputazione. Strumenti come <strong>UptimeRobot</strong>, <strong>Pingdom</strong> o soluzioni self-hosted permettono di ricevere notifiche immediate via email, SMS o Slack quando il sito non risponde.</p> <p>Oltre all'uptime, è importante monitorare le <strong>performance</strong>: tempi di risposta, errori 500, utilizzo risorse del server. Un rallentamento graduale può indicare problemi che, se non risolti, porteranno a un downtime completo.</p> <h3> Aggiornamento contenuti </h3> <p>Testi, immagini, prodotti, prezzi, orari, informazioni di contatto: tutto ciò che cambia nel tempo va aggiornato. Se il sito ha un <strong>pannello admin</strong>, puoi farlo in autonomia. Se non ce l'ha, ogni modifica richiede l'intervento dello sviluppatore — e questo ha un costo e un tempo di attesa.</p> <h2> Come funziona in pratica la manutenzione? </h2> <p>Esistono diversi modelli di manutenzione, ognuno con vantaggi e svantaggi:</p> <h3> Pacchetto mensile a canone fisso </h3> <p>Paghi un importo fisso ogni mese che include un pacchetto definito di ore e attività. <strong>Vantaggi</strong>: costi prevedibili, priorità sugli interventi, relazione continuativa con lo sviluppatore. <strong>Svantaggi</strong>: paghi anche nei mesi in cui non serve nulla. Ideale per siti business-critical con aggiornamenti frequenti.</p> <h3> Interventi a consuntivo </h3> <p>Chiami lo sviluppatore quando serve e paghi le ore effettive. <strong>Vantaggi</strong>: paghi solo quello che usi. <strong>Svantaggi</strong>: tempi di risposta più lunghi (non sei un cliente prioritario), nessuno monitora proattivamente il sito. Adatto a siti semplici con poche esigenze di aggiornamento.</p> <h3> Manutenzione interna </h3> <p>Se hai un team tecnico interno, puoi gestire tutto in-house. Lo sviluppatore consegna il progetto con <strong>documentazione completa</strong>, accesso a tutti i servizi e formazione per il team. È la soluzione con più autonomia, ma richiede competenze tecniche interne.</p> <h2> Cosa verificare alla consegna del sito </h2> <p>Prima di considerare il progetto chiuso, assicurati di avere:</p> <ul> <li> <strong>Accesso completo</strong> al codice sorgente (repository Git)</li> <li> <strong>Credenziali</strong> di hosting, dominio, database, email, servizi terzi</li> <li> <strong>Documentazione</strong> tecnica: come fare deploy, come funziona il pannello admin, dove sono i backup</li> <li> <strong>Proprietà intellettuale</strong> chiara: il codice è tuo, non dello sviluppatore</li> <li> <strong>Procedura di emergenza</strong>: chi chiamare e cosa fare se il sito va giù alle 3 di notte</li> </ul> <h2> Quanto costa la manutenzione di un sito web? </h2> <p>I costi variano molto in base alla complessità del sito e al livello di servizio richiesto. Come riferimento:</p> <ul> <li> <strong>Sito vetrina semplice</strong>: 50-150 euro/mese per aggiornamenti e monitoraggio base</li> <li> <strong>Sito con CMS e funzionalità custom</strong>: 150-400 euro/mese</li> <li> <strong>Web application o e-commerce</strong>: 400-1000+ euro/mese a seconda della complessità</li> </ul> <p>Questi costi includono hosting, backup, monitoraggio e un monte ore per interventi. Non includono lo sviluppo di nuove funzionalità, che va preventivato a parte.</p> <h2> Il consiglio pratico </h2> <p>Assicurati di avere <strong>autonomia sui contenuti base</strong> e un referente tecnico affidabile per tutto il resto. Un sito ben costruito con codice pulito e architettura solida richiede poca manutenzione, ma non zero. Pianifica la fase post-lancio fin dall'inizio: fa parte del progetto tanto quanto il design e lo sviluppo.</p> <p>E soprattutto: <strong>non rimanere mai in ostaggio di uno sviluppatore</strong>. Devi avere accesso a tutto, dal codice all'hosting. Se qualcuno ti dice "il codice è mio, tu paghi il servizio", cambia fornitore.</p> <p>👉 <strong><a href="https://iadicola.it/articoli/cosa-succede-dopo-la-consegna-del-sito?utm_source=devto&amp;utm_medium=social" rel="noopener noreferrer">Leggi l'articolo completo su iadicola.it</a></strong></p> business consulenza faq