My exact case was something like this: I've made a bunch of style libraries for web (my latest is Tamagui). The one before Tamagui was similar, it had variants

My exact case was something like this: I've made a bunch of style libraries for web (my latest is Tamagui). The one before Tamagui was similar, it had variants and a `styled` helper, but it didn't output to "atomic CSS". A full year plus into the development of it it was working alright but was quite slow due to all the crazy CSS is was generating and inserting all the time. Atomic CSS really helps this in many ways. So I dove in, technically I felt I could keep the API surface the same. But after about a full month of refactoring it to work with atomic CSS I found many problems. There are just some fundamental limitations to the API design you must enforce to make it work, and without such you really can't merge things properly. It's hard to explain without writing a mini-book, but needless to say the API surface very much can dictate the performance, and if you stuff your API with a bunch of features before making things fast, you may end up like me having to basically start from scratch. My take: work/right/fast is a loop you must run many times. They also bleed into each other. Sometimes you do work/right and it feels fast, but you haven't deployed it at scale, so you never realize it's not fast. Keep your API as simple as you can, try and hit the fast part somewhat early before you add many features, and don't be afraid to take all your lessons and restart things. If fast is important to your lib, making it right must also be done in tandem with make it fast.