C'è una tentazione ricorrente quando si costruisce uno strumento che deve dare un numero a qualcuno: buttarci dentro un modello linguistico e chiedergli di stimare. Con Ristrutturazioni Preventivi, piattaforma di stima immediata del costo di una ristrutturazione a Roma, abbiamo fatto la scelta opposta.
Prima di scrivere una riga di codice, la ricerca
Un dettaglio che spesso si salta quando si racconta un progetto costruito con l'AI: prima di disegnare il form, abbiamo studiato il settore verificando ogni affermazione contro una fonte reale, non con un prompt generico tipo "fammi un'analisi di mercato". Provvedimenti dell'Autorità Garante della Concorrenza e del Mercato, sentenze del TAR, sanzioni del Garante Privacy, dati CRESME sul mercato delle ristrutturazioni. Chiedi a un modello linguistico senza controllo "quali sono i problemi dei comparatori di preventivi online" e ottieni una risposta plausibile ma spesso generica, a volte inventata nei dettagli. Il nostro percorso è l'opposto: prima la ricerca con fonti verificabili, poi l'AI per organizzare quello che avevamo già trovato, non per inventarlo. Il knowledge graph del VibeCoded Orchestrator conserva proprio questo: non solo la conclusione, ma la fonte dietro ogni affermazione.
Da quella ricerca sono emersi pattern concreti e non teorici. Più di un concorrente nel settore è stato sanzionato per pratiche commerciali scorrette o recensioni non genuine, con provvedimenti confermati anche in ricorso. Un altro caso, documentato dal Garante Privacy, riguardava proprio il consenso unico raccolto per finalità multiple, di cui parliamo più avanti. Precedenti con un'autorità che li ha accertati, che hanno guidato scelte precise nel progetto.
Niente AI per i numeri
Il preventivatore funziona su parametri chiusi: metri quadri, tipo di intervento (ristrutturazione integrale, parziale, bagno, cucina, infissi, tetto), numero di bagni. Nessun campo di testo libero, nessuna domanda aperta. L'utente segue un percorso guidato a risposte predefinite, e alla fine riceve una stima calcolata su prezzi reali di cantieri romani, raccolti con un architetto romano che segue lavori sul territorio.
Un LLM qui avrebbe introdotto un problema specifico: la varianza. Chiedi la stessa ristrutturazione due volte a un modello linguistico, anche con lo stesso prompt, e puoi ottenere due range diversi, perché genera testo plausibile, non esegue un calcolo deterministico su una tabella di prezzi verificata. Per un numero che l'utente porterà con sé in una conversazione reale con un professionista, quella varianza è un difetto. Il percorso a risposte chiuse elimina l'ambiguità all'origine: stessi parametri, stessa stima, sempre. E un preventivo su prezzi reali, raccolti da chi i cantieri li segue davvero, è più facile da spiegare quando l'utente chiede "ma questo numero da dove viene?" rispetto a una stima senza una fonte dichiarata.
Lo stack, pensato per un servizio che si usa una volta
Dietro al form c'è Next.js 16 su Vercel, con Supabase come database e Resend per le notifiche via email. Non c'è un'app da scaricare, e non c'è un'area riservata per chi compila il form: il servizio è pensato per essere usato una volta, lasciare i propri dati, ed essere ricontattati da un architetto. Nessun account, nessuna password, nessuno stato da controllare: la richiesta parte, e la conversazione prosegue altrove.
La conseguenza è diretta sull'architettura: niente autenticazione, niente sessione persistente, meno superficie da mantenere per un caso d'uso che non ha bisogno di uno storico.
Guide pubblicate da sole, una a settimana
Oltre al preventivatore, il sito pubblica guide ai prezzi (ristrutturazione completa, bagno, infissi, tetto, come leggere un preventivo) con cadenza settimanale. La pubblicazione è programmata: un calendario editoriale vive in un file TypeScript nel repository, non in un pannello esterno, e uno script cron su GitHub controlla quali guide sono "mature" (cioè la cui data di pubblicazione programmata è arrivata) e lancia un deploy hook solo per quelle.
Il dettaglio meno ovvio è il fuso orario. Un cron GitHub Actions gira di default in UTC, e una guida programmata per "lunedì mattina" in UTC può pubblicarsi a mezzanotte o all'1 di notte ora italiana, a seconda dell'ora legale. Il fix è convertire esplicitamente a Europe/Rome prima di confrontare la data con quella della guida, invece di confrontare timestamp grezzi: un bug che non si nota in sviluppo, perché in locale si testa di giorno, e salta fuori solo quando una guida esce alle due di notte invece che alle nove.
GDPR: due consensi, non uno
Il form raccoglie dati personali per due scopi distinti: essere ricontattati da un architetto, ed eventualmente essere messi in contatto con un'impresa. Sono due trattamenti diversi, e li teniamo separati: due checkbox di consenso distinte, ciascuna datata al momento della sottomissione, invece di un consenso unico per entrambi gli scopi.
La ragione non è teorica, come visto sopra: un consenso che chiede "sei d'accordo con tutto" per finalità diverse è esattamente il tipo di pratica per cui un'autorità ha già sanzionato un attore del settore. Separarli costa due checkbox in più, e toglie l'ambiguità su cosa l'utente ha effettivamente accettato.
Analytics senza cookie
Niente Google Analytics, niente banner cookie per il tracciamento. Gli eventi che contano (a quale passo del form un utente si ferma, se arriva alla fine) sono eventi Vercel Analytics, senza cookie di profilazione e senza bisogno di consenso. Si perde la profondità di un GA4 configurato a dovere, ma per capire dove il funnel perde persone è sufficiente.
Se ti interessa un approccio simile, la guida ai prezzi aggiornata è su ristrutturazionipreventivi.it/quanto-costa. Un taglio diverso, la SEO per un artigiano locale, è nel case study su un sito di falegnameria.