Domande frequenti

MS WebX è un'azienda informatica. Realizziamo siti e piattaforme web, app native per iOS e Android e vi integriamo l'IA, insieme al lavoro SEO che rende trovabile ciò che costruiamo. Gestiamo inoltre prodotti nostri sulla stessa piattaforma che usiamo per i clienti: la base è già collaudata in produzione prima che qualcun altro ci si appoggi.

Entrambe, per scelta. Quello che proponiamo gira prima nei nostri prodotti: il sistema di pagine multilingua, il livello API, gli strumenti di amministrazione, l'analytics. Nessun progetto cliente parte su una base non collaudata e, se qualcosa si rompe nel nucleo, ce ne accorgiamo prima noi.

In tre modi, tutti indipendenti da ciò che scriviamo qui. La pagina delle note legali riporta i dati societari ufficiali. I nostri prodotti sono pubblici e si possono usare senza contattarci. E la pagina contatti arriva alle stesse persone che scrivono il codice, senza un call center davanti.

Ci descrivi l'obiettivo, non la soluzione tecnica. Facciamo domande finché il perimetro non è davvero chiaro, poi lo mettiamo per iscritto prima di costruire qualsiasi cosa. Se riteniamo che la strada richiesta sia sbagliata, lo diciamo prima che tu paghi: quella conversazione costa meno del rifacimento che evita.

A passi piccoli e visibili. Il lavoro finisce su un ambiente di staging che puoi aprire nel browser quando vuoi e va online solo quando lo dici tu. Nessuno vede il prodotto finito per la prima volta a fine progetto: a quel punto ogni modifica costa cara.

Quello che costruiamo è fatto per essere mantenuto: aggiornamenti delle dipendenze, monitoraggio e modifiche quando cambia il tuo business. Se a farlo siamo noi o il tuo team si concorda dentro il progetto, non si dà per scontato dopo. Niente viene costruito in modo che possiamo metterci mano solo noi.

Prima leggiamo il codice esistente, poi diciamo chiaramente se conviene proseguirlo o sostituirlo sull'intera vita del sistema. Capitano entrambe le risposte: un codice ereditato spesso è più che sano e solo documentato male. Non consigliamo il rifacimento per riflesso, perché è la cosa più costosa che ti si possa vendere.

PHP sul server, TypeScript nel browser, Flutter per iOS e Android, MariaDB per i dati, nginx e FrankenPHP per la distribuzione. Tecnologie attuali e diffuse per scelta, così dopo di noi può mantenerle chiunque. La qualità la tengono le macchine, non le buone intenzioni: l'analisi statica gira al livello più severo senza lista di eccezioni, con oltre duecento regole nostre che scartano il codice appena devia.

Una base di codice con un nucleo condiviso e un sottile strato per marchio sopra. Ogni marchio ha il proprio design, i propri contenuti, il proprio database e il proprio dominio, mentre correzioni di sicurezza, lavoro sulle prestazioni e nuove funzioni del nucleo arrivano ovunque insieme, senza copiature manuali sito per sito. Aggiungere un marchio è configurazione e contenuto, non un fork.

Sì, e in modo più rigoroso di quanto quella frase di solito indichi. L'API è definita una volta in PHP e da quella definizione vengono generati sia il client TypeScript del web sia il client Dart dell'app. Nessuno dei due è scritto a mano: il linter rifiuta un tipo di API scritto manualmente. Così l'app non può sfasarsi in silenzio — una discrepanza rompe la build, non la produzione.

Reali. Ogni pagina esiste come record a sé per lingua, con il suo testo e il suo URL: queste FAQ stanno su /frequently-asked-questions in inglese e su /de/haeufig-gestellte-fragen in tedesco, non dietro un parametro di traduzione. Così ogni lingua si scrive come si cerca davvero in quel mercato e si corregge senza toccare le altre diciassette.

È esattamente ciò per cui è costruita. Ogni marchio ha il proprio database, il proprio dominio e i propri contenuti: un marchio non può leggere i dati di un altro e un errore di contenuto in uno non compare nell'altro. In comune c'è il motore: routing, livello API, strumenti di amministrazione e lavoro sulla sicurezza.

Cannabivo è online: un motore di ricerca per i social club, dove i visitatori trovano e confrontano i club per località e i club curano la propria scheda. Steel è un riferimento sulle equivalenze dei materiali pensato per progettazione e acquisti; è in sviluppo e non ancora aperto al pubblico. Entrambi girano sulla piattaforma descritta in questa sezione.

Tuoi. Li trattiamo per far funzionare il servizio commissionato e per nient'altro. Non finiscono mescolati con quelli di un altro cliente, non vengono venduti e non servono a mostrare pubblicità ai tuoi utenti. Se il rapporto finisce, i dati te li porti via.

Le connessioni usano HTTP/3 e il dominio è nella lista HSTS precaricata dei browser: il browser rifiuta di parlarci in chiaro già alla primissima visita, prima che un redirect possa essere intercettato. Lo scambio di chiavi è post-quantistico, X25519 combinato con ML-KEM-768, scelto perché il traffico catturato oggi resista anche quando un computer quantistico potrà attaccarlo.

Mai nel codice sorgente, e a imporlo è la build, non la buona volontà: il codice con un segreto scritto dentro viene rifiutato prima di poter essere integrato. I segreti stanno cifrati in un archivio di impostazioni e vengono decifrati a runtime solo dove servono davvero, così ruotare una chiave è una modifica in un punto solo invece di una caccia in tutto il codice.

Sì. Eventi applicativi, errori e azioni amministrative finiscono nel database e non in file di testo sparsi sui server, quindi si possono davvero cercare. Le modifiche amministrative registrano chi ha agito, cosa è cambiato e quando. A «chi ha cambiato questo prezzo il mese scorso» c'è una risposta, non un'ipotesi.

I cookie non essenziali vengono impostati solo dopo il consenso del visitatore, la scelta viene registrata e ogni sito che realizziamo ha una pagina dove cambiarla o revocarla in seguito. Rifiutare è un clic, non una caccia dentro un menu di impostazioni — e chi rifiuta ottiene comunque un sito funzionante.

Un modello che svolge un compito preciso dentro il tuo prodotto e batte in modo misurabile l'alternativa: smistare i messaggi in arrivo, scrivere bozze che poi una persona approva, far capire alla ricerca cosa intendeva l'utente invece di cosa ha digitato. Non è una bolla di chat incollata su un sito finito. La domanda utile non è mai «possiamo aggiungere l'IA», ma «quale compito ripetuto ti sta costando tempo».

Nei contenuti. Il nostro materiale multilingua viene prodotto e tenuto aggiornato con l'aiuto dei modelli e poi rivisto lingua per lingua prima di uscire — mai pubblicato direttamente dal modello. È anche per questo che parliamo di IA con prudenza: sappiamo per esperienza dove il risultato regge e dove serve ancora una persona.

Prima di costruire qualsiasi cosa mettiamo per iscritto quale fornitore tratta quali dati e cosa viene conservato. Se quella risposta non ti sta bene, la funzione si progetta diversamente o non si fa. Nessun dato esce dal tuo sistema in un modo che non hai accettato — e «non sapevamo che venisse inviato» non è un esito che siamo disposti a produrre.