Aetha come full-stack AI company: cosa significa costruirne una

Due founder, quattro prodotti, un nucleo condiviso: cosa ho imparato costruendo Aetha come full-stack AI company invece di una software house con l'AI.

In breve. Aetha è la mia società: due founder, quattro prodotti, una tesi: ricostruire categorie di software intorno a ciò che l'AI sa fare oggi. Costruendola ho capito che "full-stack AI company" non significa usare l'AI ovunque: significa progettare azienda e prodotti come un unico stack, dal nucleo condiviso al go-to-market, dove ogni prodotto insegna qualcosa che viene riusato nel successivo. Parlo solo del caso che ho costruito: due prodotti live, non una media di mercato. Pubblicato il 5 ottobre 2026.

La credenza: bastava un buon prodotto AI

Quando ho iniziato a costruire Arvo, il mio coach AI per l'allenamento, pensavo che il lavoro fosse il prodotto: agenti bravi, buona esperienza, utenti contenti. Quella parte ha funzionato, e l'architettura multi-agente l'ho già raccontata qui. Il problema è arrivato con il secondo prodotto, Zeno: mi sono accorto che stavo ricostruendo daccapo quasi tutti gli strati intorno al prodotto: autenticazione, onboarding, supporto, distribuzione e deploy, come se il primo non mi avesse insegnato niente. Non era un problema di bravura degli agenti. Era che stavo costruendo prodotti separati invece di un'azienda.

I layer che ho dovuto costruire davvero

Full-stack, per come lo vivo in Aetha, sono sei strati progettati come un sistema solo. Li elenco con ciò che c'è dentro davvero, non con ciò che suona bene.

1. Nucleo condiviso deterministico. Stato, permessi, policy, verifica e audit: le parti che non si improvvisano mai, uguali per ogni prodotto. È la base dichiarata della nostra tesi, "shared core, tailored edges".

2. Workflow specifici per business. Sopra il nucleo, ciò che cambia: il processo di vendita tradotto in software per Accordo, il nostro framework CRM pre-launch, la programmazione degli allenamenti per Arvo, le micro-sessioni per Zeno.

3. Agenti che svolgono il lavoro. Non solo dentro il prodotto (progressione, scelta degli esercizi, generazione dei workout) ma nel supporto, con tool, interruttori e contabilità delle quote, e nella crescita, dove un agente propone esperimenti con ipotesi, canali e metriche di successo. Come organizzo questi agenti l'ho descritto nella guida dedicata: qui conta il punto, che il lavoro agente non si ferma al prodotto.

4. Distribuzione. Lo stesso Arvo vive nell'app, nella directory delle app di ChatGPT e in un'estensione browser: tre bocche, una sostanza.

5. Go-to-market. Campagne Apple Search Ads per Arvo, listing ottimizzati per gli store di Zeno su iOS e Android. Anche l'acquisizione è uno strato dello stack, non un afterthought del marketing.

6. Loop di apprendimento e verifica. Misurare se il sistema sta facendo il lavoro, trovare i problemi dopo il deploy, far verificare ogni fix da un attore indipendente da chi l'ha scritta. È lo stesso loop che ripara il software di notte, applicato come strato permanente.

Il secondo prodotto costa meno solo se il primo ha insegnato

Arvo e Zeno condividono la forma dello stack e gli stessi strati non-prodotto: Next.js, Supabase, OpenAI e agenti da una parte; supporto e onboarding come agenti, store e campagne, procedure di deploy dall'altra. La regola che ne abbiamo ricavato è quella scritta sul sito di Aetha: costruiamo prima i prodotti, impariamo cosa si generalizza, lo riusiamo nel successivo. Il portfolio non è la strategia: è come impariamo cosa riusare. E Orchestro, il quarto prodotto, è dove il metodo e l'esperienza si accumulano invece di disperdersi nei repo.

Due onestà. Primo: non è un monorepo e non lo racconto come tale: i backend sono diversi, condivisi sono forma, metodo e strati. Secondo: che il prodotto N+1 costi davvero sempre meno è una direzione che osservo su due prodotti live, non una curva misurata.

Cosa non è: usare l'AI dentro l'azienda di prima

La differenza è architetturale, non di quantità di AI. Nel software vecchio il flusso è umano → interfaccia e form → workflow: aggiungere un assistente sopra lascia tutto intatto, il processo aspetta ancora qualcuno che lo guidi click dopo click. Un copilot non è questo cambiamento. Ricostruire la categoria significa invertire il flusso: obiettivo → il software svolge il lavoro → risultato, con le persone nel loop che conta — review, eccezioni, approvazioni con conseguenze.

Il metodo che resta quando i modelli cambiano

Usiamo i migliori modelli disponibili e assumiamo che diventino sempre più economici. I coding agent sono fornitori, non ciò che stiamo costruendo. Ciò che resta è il metodo operativo: come un business diventa software, cosa automatizzare e cosa deve restare deterministico, dove un umano deve approvare, come misurare, come trovare i problemi, come verificare le fix. Ogni prodotto aggiunge qualcosa al metodo, e il successivo parte più avanti. Non ho provato che regga oltre la nostra scala, due founder e quattro prodotti, e lo dico prima che lo chiediate.

Cosa significa per la tua azienda

Se compri software, la domanda è una: il fornitore ha ricostruito la categoria intorno a ciò che l'AI fa oggi, o ha aggiunto un assistente al prodotto di ieri? Nel primo caso la promessa è vestibilità su misura a costi da prodotto; nel secondo paghi il vecchio prezzo più il badge AI. Se costruisci, progetta gli strati una volta sola: il secondo prodotto è il test che il primo non ti ha fatto superare gratis.

Domande frequenti

Cosa significa full-stack AI company?

Un'azienda progettata come un unico stack: nucleo software condiviso e deterministico, workflow specifici per business, agenti che svolgono lavoro in prodotto, supporto e crescita, distribuzione, go-to-market e loop di apprendimento — con ogni prodotto che insegna qualcosa al successivo.

Che differenza c'è tra usare l'AI e ricostruire una categoria software?

Usare l'AI lascia il flusso umano → interfaccia → workflow e ci aggiunge un assistente. Ricostruire la categoria inverte il flusso in obiettivo → il software svolge il lavoro → risultato: è un cambio di architettura, non di funzionalità.

Quanto deve essere grande un'azienda per lavorare così?

Non lo so sopra la nostra scala: Aetha oggi sono due founder e quattro prodotti. Il metodo è nato piccolo e resta da provare su organizzazioni più grandi.