Frontend, backend software, pipeline AI, architettura SaaS. Dentro a fondo in ognuna di queste discipline, non a grattare la superficie ovunque. Quale ti serve, si chiarisce nella conversazione. Quattro settimane di hypercare dopo ogni launch sono standard.
Quattro discipline — cliccabili direttamente sulla forma orb o sulla lista.
Cambia le props a sinistra, codice a destra e preview sopra si aggiornano in tempo reale.
INFO
Sviluppo web in method64 significa: ogni sito è costruito a mano. Niente page builder, niente tema WordPress con 80 plugin. Frontend con React, Next.js, GSAP e WebGL. Un sito marketing resta sotto lo standard di 1,5s LCP, una web app complessa performa come software nativo. Three.js, WebGPU o librerie 3D specializzate entrano su richiesta, non come default. Performance, accessibilità e SEO sono standard integrati. Ogni componente ha una ragione. Durante la fase di build ricevi ogni due settimane uno status update con screenshot dello stato attuale; per web app complesse, in più un link di staging live. La demo qui sopra è un button davvero cablato: cambia variante, dimensione e flag, il codice JSX si aggiorna live, nessuna immagine.
COME VIENE COSTRUITO
01
Comprendere
Obiettivo, audience e constraint si chiariscono nel colloquio. Conversazioni mirate, non una lunga fase di discovery.
02
Architettura
Stack, hosting e build pipeline vengono decisi. Capisci ogni decisione e perché è stata presa così.
03
Costruire
Iterativamente in slice da 2 settimane. Ogni due settimane uno status update con screenshot della build reale, non da Figma.
04
Launch + iterazione
Production deploy con monitoring, performance budget, audit SEO.
Frontend Climactra (live). Anche questo sito è un riferimento, volutamente esagerato, ma ogni dettaglio qui potrebbe essere eseguito anche in modo più conservativo se il tuo progetto lo richiede.
passa il mouse su un nodo, header / body / latency appaiono qui
0
Clientt = 0ms
POST /api/orders
{ "items": [...], "currency": "EUR" }
1
Gateway+8ms
JWT verify · rate-limit · route
auth=ok · tenant=hotel-42 · forwarded
status: 200
2
Order Service+34ms
fastify @ node 20
validate(payload) · enqueue(stripe-charge)
status: 200
3
Postgres+11ms
INSERT INTO orders RETURNING *
tenant_id filter via RLS · 1 row · 2.3ms
status: 200
4
Client53ms total
201 Created
{ "id": "ord_8a2f...", "status": "pending" }
status: 201
INFO
Servizi backend nascono così: API che integrano altri sistemi, pipeline di dati che girano in modo affidabile, microservizi con responsabilità chiare. Node.js e Python a seconda del caso d'uso, PostgreSQL come database di default, Docker per deploy puliti, observability dal giorno uno. La scelta cade su tecnologia ancora manutenibile tra due anni, invece dell'ultimo framework di tendenza. Durante la fase di build: ogni due settimane un endpoint deployable in live staging più status update. Puoi testare l'API direttamente con Postman o curl. La demo qui sopra manda un request lungo il suo percorso: Client → Gateway → Service → Postgres → Response, ogni hop con header, body e latenza.
COME VIENE COSTRUITO
01
Contratto API
Spec OpenAPI o typed-RPC per primi. L'interfaccia esiste prima che si scriva codice.
02
Confini dei servizi
Bounded context, servizi piccoli, regole chiare di ownership dei dati. Niente teatro dei microservizi quando basta un monolite.
03
Dati & caching
Migration di schema versionate, indici espliciti, layer di caching con un percorso di invalidazione chiaro.
04
Observability
Log strutturati, metriche correlate, trace attraverso ogni layer. Vedi i problemi prima che gli utenti li segnalino.
API backend Climactra: API multi-tenant per dati CO₂ con isolamento per-hotel, subscription Stripe, e un motore di reporting custom che genera report di emissioni auditabili a partire da dati di energia, acqua, rifiuti e occupazione. Un prodotto di method64.
Modalità demo: match per parole chiave su 7 chunk curati a mano, risposta scriptata. La pipeline reale con embeddings e LLM nasce nei progetti clienti.
INFO
Qui l'AI non è un termine di marketing. method64 costruisce pipeline RAG che danno risposte davvero rilevanti, agent con tool-use che si occupano di compiti reali, ricerca basata su embeddings che batte la full-text. Quando GPT basta, quando Claude è meglio, quando il fine-tuning ha senso e quando un semplice prompt template risolve il problema: si decide caso per caso. La demo qui sopra mostra il flusso RAG basato su questo sito, match per parole chiave su 7 chunk curati a mano, nessun LLM live. Le pipeline reali con embeddings + rerank + LLM nascono nei progetti clienti. Durante la fase di build: ogni due settimane sample output e uno snapshot di eval nello status update, niente UI live, perché le pipeline pure di solito non ne hanno una.
COME VIENE COSTRUITO
01
Validare il caso d'uso
Ti serve davvero AI? Spesso una full-text search, un decision tree o un if-else risolve il problema più in fretta, più a buon mercato, in modo più prevedibile.
02
Dati + eval
Un dataset di eval viene costruito PRIMA del primo prompt. Altrimenti non sai mai se il sistema sta migliorando.
03
Pipeline
Embedding → vector search → rerank → chiamata LLM. Ogni passo testabile e sostituibile in modo isolato.
04
Production hardening
Rate limit, cost cap, validazione degli output, fallback in caso di outage del provider. Sistemi AI che non cadono se OpenAI è giù.
Questa demo è costruita a sé per mostrare la capability. Climactra al momento non usa una pipeline LLM, e lo si dice in modo onesto. Pipeline RAG finora sono nate in prototipi interni; il primo progetto cliente produttivo è ancora davanti. Il calcolo è di conseguenza prudente: dataset di eval, cost cap, iterazione prima di scalare.
Costruire SaaS non è "web app con login". È isolamento dati multi-tenant, ciclo di vita delle subscription, auth con magic link e OAuth, observability tra tenant, e flussi di onboarding che non spaventano. Viene costruito dal giorno uno con l'architettura giusta, non aggiunto dopo. Climactra è la prova: una piattaforma completa, costruita interamente in casa, con tutto quello che una piattaforma SaaS seria deve avere. Durante la fase di build: live staging dal giorno uno, puoi entrare quando vuoi e usare lo stato attuale con tenant di test. La demo qui sopra impila i quattro strati SaaS — Auth, Billing, Tenancy e Observability — come piani, su schermi più grandi come stack 3D che si separa scorrendo.
COME VIENE COSTRUITO
01
Modello di tenant
Row-level security, schema-per-tenant, o database-per-tenant, a seconda dei tuoi requisiti di compliance e scala.
02
Auth + billing
Auth.js per le sessioni, Stripe per le subscription, webhook elaborati in modo idempotente. Edge case (pagamento fallito, rimborso, cambio di piano) pensati a fondo.
03
Observability
Log + metriche + trace, ogni voce taggata con tenantId. Vedi per cliente chi ha quale problema e perché.
04
Onboarding + retention
Hint in-app, sequenze email, tracciamento dell'health score. La disciplina poco sexy che rende profittevole una SaaS.
Cosa chiedono i clienti prima del primo colloquio.
01 · Sviluppo web
Per i siti marketing: Next.js con static generation o Vite + prerendering. Veloce, forte sulla SEO, manutenzione bassa. Per web app complesse: Next.js App Router o una SPA Vite con React Query, a seconda che la SSR abbia senso o che l'app sia comunque interamente client-rendered dopo il login. Uno strumento viene consigliato perché si adatta al caso d'uso, non per preferenza personale.
Entrambi sono possibili. Spesso il design nasce internamente, perché è un mestiere integrato, un sito che sta bene su Figma ma cade a pezzi nel browser non è design. Se hai già un design system o dei mockup, lo sviluppo viene volentieri preso in carico e il design viene verificato prima su implementabilità + performance.
Obiettivo standard: LCP sotto 1,5s su mid-range mobile, Lighthouse score 95+ in tutte le categorie. Questo sito ha attualmente LCP ≈ 1,2s e Lighthouse 100/98/100/100 (Performance / Accessibility / Best Practices / SEO), come esempio in corso. Si costruisce con performance budget rigidi come build-gate: se una modifica spinge il bundle oltre il limite, la build fallisce.
Una fase di hypercare di 4 settimane è inclusa nell'offerta standard: stesso tempo di risposta di sempre (di solito nello stesso giorno lavorativo), i log vengono letti e ciò che salta fuori viene sistemato. Dopo pay-per-use o opzionalmente un monte ore fisso, niente retainer minimo. Nessun pacchetto di "security update" per strumenti che non sono stati nemmeno integrati.
02 · Software & API
Prima di "scalare" viene "misurare". I servizi vengono costruiti così che sia esattamente visibile quando cosa diventa costoso: log strutturati, istogrammi di latenza, profiling delle query DB. La scalabilità arriva poi a tappe: vertical scale → read replica → caching → service sharding. Nessuna architettura "10x scale" per un prodotto che non ha ancora product-market fit.
Node.js per backend web, API con alta quota di I/O, feature real-time, tutto ciò che è vicino al frontend. Python per pipeline di dati, workload ML/AI, script con calcolo numerico, tutto dove l'ecosistema (NumPy, Pandas, scikit-learn, Hugging Face) fa la differenza. Mischiare va bene finché ogni servizio ha una scelta di linguaggio chiara, non codice JS in un servizio Python.
Le migration sono versionate (Prisma, Alembic, o SQL scritto a mano a seconda dello stack), girano in CI contro uno snapshot del DB di produzione, e si lanciano prima in staging. Per schema grandi: prima si aggiunge una nuova colonna (nullable), poi il codice si commuta su read-both, poi backfill, poi codice su read-new, poi si fa drop della vecchia colonna. Quattro release invece di una, ma niente downtime e niente deploy del weekend con rollback d'emergenza.
Entrambi possibili. Il servizio viene tipicamente costruito così che possa essere distribuito su Hetzner, Fly.io, Railway, AWS o sul tuo Kubernetes, l'hosting resta una tua scelta. Se vuoi un setup completo: Hetzner + Docker + nginx o Fly.io end-to-end, inclusi backup, monitoring, alerting.
Unit test per logica pura, integration test contro un database vero (Docker Compose in CI), contract test ai bordi delle API, end-to-end occasionale quando il workflow lo giustifica. La coverage non è un obiettivo, i percorsi critici hanno 100%, il glue code spesso 0%. Nessun DB mockato nei test che dovrebbero verificare il comportamento del DB.
03 · Integrazioni AI
Il RAG è la risposta giusta nella maggior parte dei casi: i tuoi dati cambiano, non hai bisogno di uno stile di scrittura proprio, vuoi risposte con riferimenti alle fonti. Il fine-tuning vale quando: i dati sono statici, hai bisogno di uno stile o formato di output specifico, oppure latenza/costi del long context diventano insostenibili. Spesso la risposta è: RAG per la conoscenza + fine-tuning leggero per il formato.
Default: Claude Opus o Sonnet per task con molto reasoning (codice, agent, tool-use complesso), GPT quando la performance del function-calling è critica, GPT-mini o Haiku per task ad alto volume. Embeddings: OpenAI text-embedding-3-large come default per domini generali, Voyage AI (voyage-3-large o modelli di dominio come voyage-finance-2 / voyage-code-2) quando il dominio è specializzato e la qualità di retrieval migliora misurabilmente. La scelta è per caso d'uso in base a qualità e costi, non per fedeltà al vendor.
Tre layer: (1) Retrieval con rerank, solo i top chunk per rilevanza semantica + per parole chiave entrano nell'LLM. (2) Il prompt istruisce il modello a rispondere "non lo so" quando i chunk non dicono nulla a riguardo. (3) Validazione dell'output: le risposte vengono verificate rispetto ai chunk sorgente (anche via LLM-as-judge in domini critici). Tasso di allucinazione a 0 non è raggiungibile, a livelli accettabili sì.
Entrambi. Q&A RAG è il caso d'uso più frequente e per molti problemi è esattamente giusto. Gli agent (tool-use, pianificazione multi-step, azioni esterne) sono 5x più complessi nello sviluppo + eval e 10x più complessi in production hardening. Gli agent nascono quando il caso d'uso lo richiede davvero, es. un bot di prenotazione che fa chiamate API reali, non un FAQ bot che cita materiale di marketing.
04 · Sviluppo SaaS
Default: row-level security con una colonna tenantId e policy RLS di PostgreSQL. Veloce, semplice, ben indicizzabile. Quando la compliance lo richiede (es. healthcare): schema-per-tenant. Database-per-tenant quasi mai, l'overhead operativo cresce linearmente senza un vantaggio chiaro. Trucco di performance: tutte le query passano per un middleware che inietta tenantId, così nessun codice può "dimenticarsi" di filtrare.
Auth.js (NextAuth) come default, provider OAuth pronti, setup veloce, niente vendor lock-in, self-hosted. Clerk o WorkOS quando ti servono feature B2B (SAML, SCIM) e il pricing è ragionevole. Supabase Auth viene consigliato più raramente, funziona, ma la migrazione altrove è dolorosa quando in seguito vuoi Postgres self-hosted.
Dipende molto dalla profondità delle feature e dalle integrazioni, tipicamente 2-4 mesi per una SaaS focalizzata con auth, billing, dati multi-tenant, una core feature e una dashboard semplice. Pipeline AI o integrazioni di dati complesse spostano il piano in avanti di conseguenza. La consegna avviene in slice da 2 settimane, vedi i progressi in continuo, niente "tutto alla fine". La timeline concreta si definisce dopo il primo colloquio quando scope e constraint sono chiari.
Una SaaS GDPR-compliant viene costruita di default: data processing agreement, implementazione del right-to-delete, hosting EU (Hetzner Falkenstein come default), audit log, backup criptati, export dati per l'utente. Climactra è sviluppata come SaaS italiana sotto diritto UE, i requisiti sono noti dalla costruzione stessa, non solo dai libri di testo.
Quando la SaaS gira su tech standard (Postgres + Node/Python + storage S3-compatibile + Docker), un cambio di hosting è un progetto di due settimane, non un dramma esistenziale. Il vendor lock-in viene apposta evitato: niente servizi solo-AWS dove esistono alternative standard. Se vuoi AWS RDS, bene, ma la costruzione è fatta in modo che Postgres-su-Hetzner sia uno switch, non un rewrite.