Manifesto · v2026.05

Come pensiamo.
Cosa promettiamo.

Un piccolo gruppo di senior engineer ha bisogno di poche regole ma molto strette. Questo è il documento che le tiene insieme — il nostro contratto interno, pubblico perché chiunque lavori con noi deve poterlo leggere prima.

Document · kytheron / manifestoLast updated · 2026.05Status · v1 (living)
/01 · Perché esistiamo

La maggior parte delle aziende non ha bisogno di più strategia.

Crediamo che la maggior parte delle aziende non abbia bisogno di più framework, più decks, o più consulenti che spiegano cosa fare. Ha bisogno di un piccolo gruppo di persone tecniche che entrino, guardino il codice, e facciano funzionare le cose.

KytheronLabs nasce nel 2026 a Napoli come gruppo indipendente di software engineer senior. Lavoriamo dove l'engineering smette di essere un'opzione e diventa l'unica leva che muove davvero il business: nelle migrazioni cloud, nelle architetture event-driven, nei sistemi AI-native che servono produzione vera.

Non siamo un'agenzia. Non siamo una software house. Siamo un collettivo indipendente di engineer senior — chi vende un progetto è la stessa persona che poi lo esegue.

/02 · I principi

Sei regole che non negoziamo.

Sono i criteri con cui decidiamo se accettare un cliente, come ingaggiarci, quando dire di no, e cosa lasciare alla fine di un'engagement.

/01 · ship

Ship, don't pitch.

Il deliverable di ogni sprint è codice in produzione — non un PDF, non una slide, non un Notion. Se a fine settimana niente è andato live, abbiamo perso il tempo del cliente.

/02 · senior

Solo persone di livello.

Niente piramidi. Ogni persona che vedi al kickoff è quella che scrive il codice. Non vendiamo il profilo senior per poi farti lavorare con qualcun altro — è una pratica che disprezziamo apertamente.

/03 · boring

Boring tech, smart application.

Postgres prima di Cassandra. Predicibile prima di novel. La novità tecnologica costa — il cliente paga per il risultato, non per il tuo entusiasmo verso l'ultimo framework.

/04 · document

Document the why.

Per ogni decisione non triviale scriviamo un ADR — Architecture Decision Record. Il "perché" sopravvive a noi. Il prossimo maintainer non deve fare archeologia per capire le scelte.

/05 · transfer

Leave it better.

Quando usciamo, il sistema è più semplice di quando siamo entrati. Documentato, testato, manutenibile. Se il team interno non riesce a tenerlo in piedi senza di noi, abbiamo fallito.

/06 · honest

Brutally honest, never cruel.

Diciamo "non lo so" quando non lo sappiamo. Diciamo "questa scelta è sbagliata" quando lo è. Diciamo "non siamo il fornitore giusto" quando non lo siamo. Cortesia + verità, mai una al posto dell'altra.

/03 · AI consapevole

La AI è una primitiva, non una soluzione.

Trattiamo i Large Language Model come trattiamo qualsiasi altro componente di sistema: misurabile, riproducibile, osservabile, debuggabile. Niente magia. Niente hype. Niente prompt scritti in fretta che diventano infrastruttura critica per sbaglio.

/regola operativa

Se un agente AI in produzione non può essere monitorato come un microservizio — con tracing, log strutturati, alert, SLO e rollback — allora non è in produzione. È una demo che vive su un server.

/ai · 01

AI-native, non AI-washed.

Costruiamo come se LLM, embeddings e agent fossero primitive di default. Ma non aggiungiamo "AI" a un problema che non ne ha bisogno solo per appeasare uno stakeholder.

/ai · 02

Il prompt è codice.

Versionato in git, testato con eval, soggetto a code review. Un prompt non scritto è un bug che aspetta — un prompt non testato è un incidente che aspetta.

/ai · 03

Quando la AI non è la risposta, lo diciamo.

A volte una query SQL ben scritta batte un RAG. A volte un cron job risolve quello che un agente complica. Il rigore tecnico viene prima dell'allineamento alla narrativa di mercato.

/ai · 04

Dati del cliente, sovranità del cliente.

Niente fine-tuning silenzioso. Niente dati che escono dal perimetro senza autorizzazione esplicita. GDPR e privacy non sono adempimenti — sono software engineering.

/04 · Agile come mezzo

Agile è un mezzo, non un'identità.

Abbiamo letto il Manifesto Agile originale del 2001 — quello da 68 parole, prima che diventasse un'industria di certificazioni. Quello, sì. Tutto ciò che ci sta sopra è opzionale: framework, rituali, ceremonie, scaling models. Strumenti, non religione.

/lean · 01

Cicli brevi, decisioni reversibili.

Spediamo piccolo e spesso. Le decisioni grandi le prendiamo solo quando hanno effetto reale sul sistema — non in anticipo, non in ritardo, non "per sicurezza".

/lean · 02

Feedback dal sistema, non dai meeting.

La verità sta in produzione: metriche, log, errori reali, utenti reali. Stand-up = sync point veloce, non rituale. Retro = momento per cambiare qualcosa, non per riempire un template.

/lean · 03

Roadmap pubblica, retro brutalmente onesta.

Il cliente vede dove stiamo andando, sempre. Quando sbagliamo, lo scriviamo nero su bianco insieme alla causa e al fix. Il postmortem è una pratica di software engineering, non un esercizio di blame.

/lean · 04

Niente process per il process.

Se un rituale non produce decisioni o codice, lo cancelliamo. Se uno strumento crea più overhead di valore, via. La burocrazia è il modo in cui muoiono i team tecnici.

/05 · La promessa

Quello che ti garantiamo quando firmi.

/contract

Niente account manager. Niente intermediari. Nessun "team che ti diremo dopo". Quando firmi un'engagement, sai i nomi delle persone che lavoreranno sul tuo sistema. Sono i nomi che hai visto al primo incontro.

/promise · 01

Pricing trasparente.

Nessun listino segreto, nessun discount theater. Quello che paghi è scritto, e copre il lavoro — non i layer organizzativi.

/promise · 02

Codice di proprietà del cliente.

Repository, infrastruttura, conoscenza: tutto del cliente, dal giorno uno. Niente lock-in nascosto, niente "consulting tax" sull'uscita.

/promise · 03

Diciamo di no.

Se il progetto non è per noi — per scope, stack, tempo, o etica — lo diciamo subito. Tre engagement giusti valgono dieci sbagliati.

/promise · 04

Successo = autonomia del cliente.

Il nostro obiettivo è il momento in cui non serviremo più. Non vendiamo dipendenza. Vendiamo capability che resta dentro l'azienda.

KytheronLabs Collective
Napoli, Maggio 2026 · v1 · living document
/start

Tutto chiaro? Parliamone.

Prenota una discovery call