A design system for one person is mostly an exercise in not building a design system.
The published wisdom about design systems is written for organisations solving a coordination problem — many designers, many developers, drift between them. Alone, you do not have that problem. You have a different one: everything you build, you also maintain, forever.
Tokens earn their keep immediately
Colour, type scale and spacing as named values is the one piece that pays back on day one. It is what makes a second theme a configuration rather than a rewrite, and it is what makes a client's “can we warm it up slightly” a ten-minute change.
This site runs on about a hundred and fifty custom properties and two theme blocks. Switching themes is a single attribute on the document root.
Components earn their keep on the third use
Not the first, and usually not the second. Abstracting on first use is how you end up with a component that has seven props and one caller, and you will still be maintaining it two years later.
Duplicate it twice. The third time you have enough information to know what the abstraction actually is.
Documentation is for the client, not for you
You do not need a component catalogue to remind yourself what you built last month. The client's team does need to know how to add a case study without calling you, and that is where the writing time should go.
Know when to stop
A dozen components and a token set covers a marketing site completely. The urge to keep going — a playground, visual regression, a published package — is real and is almost always the least valuable work available to you that week.
Want this run on your site?
A fixed-fee performance audit, delivered in a week.