Per molto tempo ho costruito tutto da zero. Era una questione di controllo: sapevo esattamente cosa c'era nel codice, come funzionava ogni componente, e non dipendevo da nessun maintainer esterno. Poi ho iniziato a fare conti reali sui tempi e ho capito che su progetti medio-piccoli stavo bruciando decine di ore su problemi già risolti — accessibilità dei modal, gestione del focus, animazioni di stato.
Oggi il mio approccio è ibrido. Per progetti con una brand identity forte e un lungo ciclo di vita, costruisco un design system interno partendo da primitive come Radix UI — prendo la logica comportamentale e costruisco sopra lo stile. Per progetti con timeline più strette o team piccoli, uso Shadcn come punto di partenza e lo adatto. Non c'è vergogna in questo.
Il problema con 'comprare' un design system completo — tipo Material UI o Chakra — è che arrivi con opinioni forti sullo stile che sono difficili da sovrascrivere senza guerre contro la specificità CSS. Ho visto troppi progetti dove la metà del codice di styling era `!important` per combattere la libreria. A quel punto stai pagando due volte: la complessità della libreria più quella del tuo override.
La mia regola pratica: se il progetto dura più di un anno e ha un'identità visiva ben definita, costruisco. Se è un progetto con deadline serrata o un MVP, prendo Shadcn o Radix, lo stilo con Tailwind, e vado avanti. L'importante è sapere perché stai scegliendo, non seguire la moda del momento.