ABOUT US
Una <software house> fondata su un'idea precisa: il modo in cui si ragiona sulla soluzione conta più del codice.
Aziende che ci hanno scelto
ICIB non nasce da un'idea rivoluzionaria ma da una convinzione precisa su come si lavora: che il problema tecnico è quasi sempre il più semplice da risolvere, e che quello che fa la differenza è tutto quello che viene prima e dopo il codice.
Scope definito prima di aprire un editor. Decisioni prese insieme al cliente, non consegnate. Demo ogni due settimane con qualcosa che funziona, non con slide. Continuità dopo il lancio, non un handoff e un saluto.
Quel modo di lavorare, ad oggi, non è ancora cambiato.
APP
*
SAAS
*
WEBAPP
*
GESTIONALI
*
APP
*
SAAS
*
WEBAPP
*
GESTIONALI
*
.jpg)
"Abbiamo fondato ICIB perché eravamo stanchi di vedere aziende spendere budget su software che non risolveva il problema reale. Il problema reale è quasi sempre nelle domande che nessuno aveva fatto prima di scrivere la prima riga di codice."
Vittorio Napoli
Founder & Developer
Le cose in cui
crediamo fermamente.
Non una lista di valori da sito istituzionale. Sono le convinzioni operative che determinano come lavoriamo, cosa accettiamo e cosa no, e perché certi progetti vanno bene e altri no.
Il codice è l'ultima cosa da scrivere.
Sviluppare in fretta il prodotto sbagliato costa caro. Prima capiamo problema, contesto, vincoli e priorità. Poi costruiamo.
La trasparenza non è un valore. È un prerequisito.
Un progetto opaco è una scommessa. Con sprint bi-settimanali e demo continue sai sempre dove va il budget, cosa è stato fatto e cosa viene dopo.
Il fornitore freelance sparisce dopo il lancio. Il partner no.
Un software non finisce al go-live. Da lì inizia a lavorare davvero. Per questo seguiamo continuità tecnica, manutenzione ed evoluzioni dopo la prima release.
Scalare senza un piano tecnico non è scalare. È rimandare il problema.
Crescere su basi tecniche fragili crea debito. Noi prendiamo le decisioni di architettura prima che diventino costose. Non dopo.
Un team tecnico coinvolto
in ogni fase del progetto.
Nessuna catena di subappalti, nessun account manager che fa da filtro. Il team che lavora al tuo progetto è lo stesso con cui parli dall'inizio.
Founder & Developer
Vittorio Napoli
.jpg)
CTO & DevOps
Leonardo Mussato
.jpg)
Backend Developer & Project Manager
Andrea Prisciantelli
.jpg)
Frontend Developer
Cristian Scaratti
.jpg)
Frontend Developer
Gabriele Bagno
.jpg)
UX/UI Designer
Martina Albanese
.jpg)
Partner
Andrea Carlone
Partner
Jeck Scardy
La differenza si vede prima del go-live.
Un buon partner tecnico non si riconosce solo dal codice finale, ma da come gestisce scope, costi, aggiornamenti, demo e passaggio di consegne durante tutto il progetto.
Scope
Costi
Aggiornamenti
Demo
Codice
Problemi tecnici
Ogni variazione viene discussa, approvata e documentata.
Costi chiari fin dall’inizio.
Demo ogni 14 giorni, avanzamenti, planning e prossimi step.
Demo reali, non screenshot o slide.
Il codice è vostro, documentato, portabile e di vostra proprietà.
I nodi tecnici si affrontano durante gli sprint.
Freelancer
Le richieste aumentano senza decisioni chiare.
La stima cambia mentre il progetto avanza.
Aggiornamenti da chiedere.
Sai cosa succede solo se insegui.
Demo poco concrete.
Slide, screenshot o versioni parziali.
Codice difficile da passare.
Il progetto resta legato al fornitore.
I nodi tecnici emergono vicino al rilascio.
Scope
Costi
Aggiornamenti
Demo
Codice
Problemi tecnici
Ogni variazione viene discussa, approvata e documentata.
Costi chiari fin dall’inizio.
Demo ogni 14 giorni, avanzamenti, planning e prossimi step.
Demo reali, non screenshot o slide.
Il codice è vostro, documentato, portabile e di vostra proprietà.
I nodi tecnici si affrontano durante gli sprint.
Scope
Costi
Aggiornamenti
Demo
Codice
Problemi tecnici
Le richieste aumentano senza decisioni chiare.
La stima cambia mentre il progetto avanza.
Aggiornamenti da chiedere.
Sai cosa succede solo se insegui.
Demo poco concrete.
Slide, screenshot o versioni parziali.
Codice difficile da passare.
Il progetto resta legato al fornitore.
I nodi tecnici emergono vicino al rilascio.
ICIB fa parte di un gruppo più ampio con competenze di prodotto, design e contenuto
quando il progetto lo richiede, attiviamo le altre realtà del gruppo mantenendo un unico punto di coordinamento tecnico.
Siamo tutti nel grattacielo di V.le Sabotino, 19/2, 20135 Milano MI
Prima della call,
qualche risposta utile.
qualche risposta utile.
Lavorate anche con aziende che non hanno un CTO interno?
Sì, è anzi il caso più frequente. Quando manca una figura tecnica interna, ci occupiamo noi delle decisioni di architettura, tecnologia e priorità, spiegandole in modo comprensibile. Tu resti sempre il decisore sul prodotto; noi mettiamo la direzione tecnica.
Potete partire da un prodotto già esistente?
Sì. Analizziamo il codice e l'infrastruttura attuali, individuiamo cosa tenere e cosa rifare, e interveniamo senza dover ricominciare da zero. Che si tratti di evolvere, stabilizzare o riscrivere una parte, partiamo da dove sei già arrivato.
Come gestite l'avanzamento del progetto?
Per sprint bi-settimanali, con una regola fissa: ogni due settimane vedi una demo funzionante, non un report. All'inizio dello sprint decidiamo insieme cosa entra, alla fine lo provi e stabilisci le priorità del ciclo successivo. La cadenza non cambia mai; le priorità sì, sempre in accordo con te.
Vi occupate anche di manutenzione dopo il rilascio?
Sì. Il rilascio non è la fine del lavoro, ma il punto in cui il software inizia a dimostrare il suo valore. Dopo il go-live continuiamo con manutenzione, evoluzione e supporto, con lo stesso team e le stesse regole di sempre.
Capiamo insieme se siamo il partner giusto per il tuo progetto.
Mezz'ora di call, nessuna vendita. Capiamo che cosa devi costruire, qual è la prima decisione tecnica da prendere e se ha senso lavorare insieme.
Parlaci del tuo progetto