A design system is not a deliverable. It is capital expenditure with a payback period, and almost nobody treats it that way. You spend six to ten weeks up front to make every subsequent feature cheaper. If you never measure whether features actually got cheaper, you have no idea whether it worked.
The adoption cliff
Most systems die at roughly sixty percent adoption. The common components land, the awkward ones do not, and engineers keep a parallel set of one-off styles for the cases the library never covered. Now you maintain two systems, which is worse than the one you started with.
Three numbers worth tracking
Time from design handoff to merged pull request. Percentage of shipped screens built only from library components. Number of one-off colour and spacing values in the codebase. Take a baseline before you start. Without one you are arguing from taste six months later.
On a recent HR platform, handoff-to-merge went from nine days to three and one-off colour values dropped from over two hundred to eleven. That is a defensible return. Nobody had to be talked into the second phase.
Build it from what you already ship
The systems that stick are inventoried from the live product, not designed in the abstract. Audit every screen you actually ship, count how many variants of a button really exist, and consolidate. A library built from real usage covers the awkward cases, because the awkward cases are already in it.
If your engineers are still writing one-off styles, the system is not finished. It is abandoned.
Budget for adoption, not just creation. Pairing sessions, migration of the worst offenders, and someone who owns the thing after launch. That last part is what separates a system that pays for itself from a Figma file nobody opens.