What the model does
A design system costs a team now and pays back through the teams that adopt it later. Both halves are easy to state and easy to fudge, so the model keeps them apart. Cost is the system team, at full strength while the system is being built and at whatever share you keep afterwards. Benefit is the hours the system saves a product team on one screen, multiplied by the screens those teams ship and by what an hour of that work costs.
There is no discounting, no inflation and no terminal value. A model a finance partner can check in five minutes is worth more than one they have to take on trust, and at this level of input precision a discount rate is decoration.
Why the build period sits on its own
Nothing adopts a system that does not exist yet. For as long as the build runs, the model charges the full team and credits nothing, which is why the line starts by going down. The depth of that trench is what the first funding conversation is about: six months of a five-person team is a figure a steering group recognizes, and it arrives before a single screen is faster to build.
After the build, the cost falls to the share of the team you keep. Keeping none of it is a tempting line in a budget and a reliable way to stop adoption, because a system nobody maintains drifts out of date and teams quietly fork it.
Why adoption is a straight line
Real adoption is an S curve: slow while the first team integrates, fast while the rest follow, flat once the holdouts have declined. A straight line to the same ceiling over the same months sits above an S early and below it late, and the two land in the same place.
Both the ceiling and the ramp are guesses. A curve with more parameters would add precision the inputs cannot carry, and it would shift the payback month by a month or two while looking far more authoritative about it.
The ceiling matters more than the curve does. A system every team adopts is a system nobody has, and the teams that decline tend to be the ones with the most unusual screens, which is to say the ones a shared library would have helped least.
The figure to argue about
Hours saved per screen is the one input nobody measures and everybody guesses. Every number on this page is worth exactly what that guess is worth, so the page also works it backwards. Given your team cost, your maintenance share, your team count and the adoption you expect, it shows the saving per screen at which the system covers its own upkeep.
That figure is the one to take into the room, because it is falsifiable in a way a return percentage never is. If the system has to save six hours a screen and the last three screens your teams built saved one, the model has answered, and it answered in time to change the headcount request.
What this leaves out
Four things, each of which can be larger than the saving the model computes.
Consistency has a value that never appears in hours. A checkout that behaves the same way on every surface converts better than one that behaves differently, and that value appears in revenue, which this model does not count at all.
Accessibility fixed once in a component is fixed everywhere. The alternative is fixing it in forty places or in none of them.
Onboarding gets faster, because a new designer or engineer joins a system instead of a folder of conventions.
A design system also creates a dependency. A team that ships on the system waits on the system, and a component that has to change before a release can go out is a cost this model has no line for.
None of the four are in the arithmetic, and all four belong in the conversation the arithmetic opens.