Design systems fail in a specific and repeatable way. They get built, they get demoed, they get praised, and then eighteen months later there are two of them and everyone builds new screens by copying an old file.
The failure is never technical.
What you are actually buying
Three things, in ascending order of difficulty and descending order of how much of the budget they usually get.
The components. Tokens, primitives, patterns, documentation. Genuinely the easy part, and the part every proposal is priced against.
The migration. The existing screens that have to move onto the new system. Almost always underestimated, because the estimate is made by counting components rather than counting screens.
The adoption. The teams who have to use it, the reviews that catch drift, and the person whose job it is to say no to a fourteenth button variant. This is the part that decides whether the first two were worth buying.
A proposal that prices the first and mentions the other two in a paragraph is a proposal for a folder.
Scope adoption explicitly
Put it in the engagement as deliverables with dates. Paired sessions with each consuming team. A contribution process written down and tested by someone actually contributing. A named owner inside the company, identified before the engagement starts, with time allocated.
If no such person can be named, that is important information and it is better to have it in week zero. A system with no internal owner does not survive the freelancer leaving, and the honest answer may be to build something smaller.
Measure the right number
Not component count. Not coverage. The number that matters is: what fraction of new screens shipped this month without needing a new component?
It starts low, it should climb, and if it stops climbing something is wrong that more components will not fix.
A realistic shape
For a mid-sized product: four to six weeks of audit and consolidation, six to ten weeks building and documenting, and then — the part that gets cut — three to six months of part-time support at one or two days a week while the teams migrate.
That tail is not padding. It is where the thing either takes root or quietly dies, and it costs a fraction of doing the whole exercise again in two years.