Prodotti che puoi comprendere. Sistemi su cui possiamo costruire.

Cosa c’era da risolvere

Un centro medico con un nomenclatore di centinaia di servizi tariffati aveva bisogno che ogni servizio fosse una propria pagina, reperibile nella ricerca, con prezzo e unità di misura — non un PDF con l’elenco dei prezzi. Inoltre, i prezzi e il personale cambiano, quindi la clinica doveva poterli modificare autonomamente, e le prenotazioni dovevano arrivare subito alla reception, non in una casella e-mail.

Cosa abbiamo costruito

Next.js 14.2.35 (App Router) con React 18, TypeScript e Tailwind. Ogni voce del nomenclatore medico è diventata una propria route statica: 521 file `page.tsx` in `src/app`, di cui 481 sotto `/servicii` — 184 fisioterapia, 122 servizi consultivi, 61 esami medici periodici, 27 ginecologia, 26 ozonoterapia, 23 pacchetti di trattamento, 18 medicina alternativa, 12 diagnostica, il resto per sezioni. La sitemap in produzione elenca 890 indirizzi. Il sito è bilingue ro/ru. I contenuti modificabili (medici, pacchetti, trattamenti, articoli, impostazioni, immagini) sono in un database SQLite locale tramite `better-sqlite3`, con journal WAL e chiavi esterne attive, gestito da `/admin` tramite 20 route API; l’autenticazione usa `jose` per la sessione e `bcryptjs` per la password, e la modifica della password invalida le sessioni esistenti. I moduli di prenotazione e contatto sono validati con `zod` + `react-hook-form` e inviano il messaggio formattato direttamente su Telegram, tramite Bot API. Esiste anche un calcolatore di prezzo su `calculator`.

Cosa c’era da risolvere

Il menu di un club cambia spesso, ha prezzi e volumi che devono essere esatti, ed è letto da un telefono, al buio, da persone che parlano tre lingue. Un PDF scansionato su un codice QR non risolve nulla di tutto questo: non si può cercare, non si traduce, non si aggiorna senza ristampare il codice.

Cosa abbiamo costruito

Un menu digitale senza framework e senza pacchetti: le fonti reali sono quattro file JSON, e un generatore Python di 402 righe ne scrive un unico `index.html`. 119 prodotti in 21 categorie, ognuno con prezzo, volume, composizione e fotografia; 119 testi brevi di presentazione, uno per prodotto; 119 set di raccomandazioni di abbinamento («con cosa va»), che il visitatore vede su ogni scheda. Il menu ha tre lingue: il romeno è la base, e il russo e l’inglese coprono non solo l’interfaccia, ma anche le categorie, i volumi, le composizioni, le 82 etichette di gusto e tutti i 119 testi di presentazione. Carrello, lista dei preferiti e divisione del conto funzionano nel browser, senza account e senza server. I font sono ospitati sullo stesso dominio, non su Google. Prima di ogni pubblicazione, uno script di 233 righe esegue 16 verifiche — che non si sia introdotto alcun tracker, che non si richieda nulla da un dominio terzo, che il JSON sia valido e che ogni immagine esista, che il menu sia completo in tutte e tre le lingue, che i prezzi siano ordinati in ogni categoria e che i dati strutturati della pagina siano validi. La pubblicazione avviene automaticamente da GitHub Actions alla fusione in `main`, dopo che il workflow crea una copia completa della produzione e la conserva per 30 giorni.

Cosa c’era da risolvere

Un municipio di comune deve avere un sito web ufficiale conforme alla HG 728/2023 — con sezioni fisse (trasparenza decisionale, progetti e decisioni, annunci, documenti, contatti, bilancio) — e deve poterlo aggiornare autonomamente, senza uno sviluppatore per ogni annuncio. Senza questo, l’informazione di interesse pubblico resta su carta o in un gruppo Facebook.

Cosa abbiamo costruito

Applicazione Laravel 12 su PHP 8.2 con MySQL 8, front-end Vite + Tailwind, impacchettata in due container Docker (`japca_app` = nginx + PHP-FPM, `japca_db` = MySQL). L’architettura separa intenzionalmente due tipi di contenuto: quello editoriale che cambia raramente (geografia, storia, istituzioni, contatti, bilancio) sta in un unico file di configurazione PHP di 1613 righe che i template Blade leggono direttamente, mentre quello che cambia spesso (annunci, galleria foto, progetti e decisioni, documenti, impostazioni di trasparenza) sta in MySQL ed è modificato dal pannello `/admin`. 40 template Blade, 32 route, 10 migrazioni di database. L’autenticazione dal pannello è limitata a 5 richieste al minuto dallo stesso indirizzo — la sesta riceve 429 — e ogni azione di amministrazione entra in una tabella di audit. Le intestazioni di sicurezza e la sitemap sono coperte da test automatici che girano in CI.

Cosa c’era da risolvere

La stessa cosa di qualsiasi menu con codice QR: deve essere veloce sul telefono, corretto nel prezzo, leggibile in tre lingue e modificabile in cinque minuti quando la cucina toglie un piatto. Inoltre, il ristorante non ha bisogno di alcun tipo di tracciamento dei clienti — e allora la vera domanda è se qualcuno costruisca davvero un sito che non raccolga nulla, o se lo scriva soltanto nella politica sulla riservatezza.

Cosa abbiamo costruito

Un solo `index.html` generato da uno script Python di 377 righe a partire da file JSON: 146 prodotti in 31 categorie, 143 testi brevi di presentazione, oltre alle traduzioni in russo e inglese per categorie, nomi, volumi, composizioni, etichette e testi. Carrello, lista dei preferiti e divisione del conto funzionano nel browser. Il sito è servito direttamente da Caddy 2, con HTTPS automatico. La parte interessante è che la non individuazione dell’utente non è una promessa, ma una regola imposta dall’integrazione continua: a ogni richiesta di fusione, CI rigenera `index.html` dalle sorgenti e respinge la PR se il risultato differisce dal file nel repo (quindi la pagina pubblicata corrisponde sempre alle sorgenti), poi esegue 14 controlli — nessun tracciatore, nessuna risorsa caricata automaticamente da un dominio terzo, font ospitati localmente, nessun file di backup finito nel repo, politica sulla riservatezza presente e collegata dal piè di pagina, menu completo in tre lingue, prezzi in ordine decrescente in ogni categoria, dati strutturati validi — e verifica anche che dalla configurazione del server non siano scomparse le intestazioni di sicurezza e il mascheramento dell’indirizzo IP nei log. Tutte le azioni GitHub usate sono fissate sull’hash di commit, e il workflow parte con `permissions: {}`.

Cosa c’era da risolvere

non verificato — non abbiamo le sorgenti, quindi non posso descrivere il problema di lavoro senza inventarlo.

Cosa abbiamo costruito

Applicazione React compilata con Vite, servita staticamente da nginx, con versione in russo su `/ru/`. 181 indirizzi nella sitemap di produzione. Questo è quanto si può affermare dall’esterno: le sorgenti non sono su questa macchina, quindi non posso nominare le librerie, la struttura o le integrazioni.

Cosa c’era da risolvere

Un centro stomatologico distrettuale aveva bisogno di un elenco pubblico di servizi con i prezzi, marcatura chiara di quelli coperti dall’assicurazione obbligatoria, team, orario delle urgenze e pagine di trasparenza — modificabili dal personale, non dal programmatore. Quando abbiamo preso in carico il progetto, il pannello di amministrazione aveva un problema grave: la password admin veniva confrontata nel browser e finiva nel pacchetto JavaScript pubblico, mentre le richieste di scrittura sull’API potevano essere fatte da chiunque su internet.

Cosa abbiamo costruito

Applicazione React 18 + TypeScript su Vite 6, con routing `react-router-dom` — 22 schermate, dai servizi e prezzi fino a urgenze, ortodonzia, impianti, pedodonzia, trasparenza e feedback. Sul backend, un API Express 4 avviato sotto PM2; nginx serve i file compilati e inoltra solo `/api`. I dati pubblici (servizi, team) stanno in file JSON letti sia dall’API, sia direttamente dal front-end. La parte che abbiamo portato noi è la sicurezza: la password non lascia più il server — `POST `login` la verifica lì e restituisce un token firmato HMAC-SHA256 valido 12 ore, con limite di 8 tentativi ogni 15 minuti per indirizzo IP e confronti in tempo costante; le scritture su `services` e `team` richiedono ora il token; il segreto di firma viene generato autonomamente in un file con permessi 0600, tenuto fuori dal repo; l’API ascolta solo su 127.0.0.1, quindi nginx è l’unica via pubblica; CORS è limitato ai domini propri, e il corpo JSON è limitato a 1 MB. Sopra questo abbiamo aggiunto CI che compila, verifica i tipi e rifiuta il pacchetto se vi trova un segreto, più Dependabot con ritmo settimanale per npm.

Cosa c’era da risolvere

Un’azienda di credito ha bisogno di più di un sito: la richiesta deve entrare online, passare attraverso un flusso di decisione, produrre un contratto PDF, generare un piano di pagamenti e lasciare traccia nell’audit — e tutto deve reggere alle domande che pone un cliente che chiede indietro i propri dati personali. La parte pubblica (calcolatori, articoli, pagine per tipo di credito) deve allo stesso tempo portare persone dalla ricerca.

Cosa abbiamo costruito

Due metà nello stesso repository. La parte pubblica è un’app Vite + React Router compilata staticamente — 50 schermate, tra cui quattro calcolatori (credito, idoneità, rifinanziamento, piano di pagamenti), pagine separate per tipo di credito, blog, pagine di informazione precontrattuale e di conformità. Le route rumene restano senza prefisso, mentre quelle russe vanno su `/ru/…`, con etichette canoniche e alternative generate dalla lingua della route attiva. La parte business è un backend Express modulare in TypeScript, con Prisma sopra PostgreSQL: 16 moduli — autenticazione, diritti per ruolo, flusso delle richieste, documenti, pagamenti, notifiche, attività pianificate, blog, SEO, GDPR, clienti, lead, contatti, calcolatore, Google Ads, salute — e 18 tabelle nello schema Prisma, tra cui `Contract`, `Payment`, `AuditLog`, `GdprRequest`, `UploadedDocument`, `DailyKpiSnapshot` e `CronJobRun`. Gira sotto PM2, con script separati per migrazioni in produzione, controlli prima del rilascio, generazione dei segreti, backup e ripristino del database.

Cosa c’era da risolvere

Un service auto è cercato in combinazioni molto specifiche — marca più operazione più quartiere („reparație cutie automată BMW Botanica”). Una sola pagina „Servicii” non può rispondere a nulla di tutto questo. Il problema tecnico è che il sito è un'app React a pagina singola, quindi ciò che vede il motore di ricerca è un `<div>` vuoto se non si fa qualcosa di specifico.

Cosa abbiamo costruito

Applicazione React 19 + TypeScript su Vite 6, con React Router, ma prerenderizzata alla compilazione: ogni route esce dal build come file HTML proprio, quindi il motore di ricerca riceve contenuto, non una pagina vuota. La struttura degli indirizzi è stata estesa in fasi verificabili nella cronologia — da 206 pagine indicizzabili, a 316 tramite l'aggiunta delle combinazioni marca × categoria di lavoro, degli articoli e delle pagine per settore di Chișinău. Le route hanno versioni per lingua, una sitemap delle immagini separata, immagini Open Graph e il pacchetto JavaScript suddiviso per un caricamento più rapido. L'ultimo commit ha corretto un dettaglio che rovina silenziosamente l'indicizzazione: l'indirizzo canonico, `hreflang` e gli indirizzi nella sitemap emettono ora tutti la stessa forma con barra finale.