An API you have to live with

Write the call sites first. Not the implementation, not the types: the three or four lines you want somebody to be able to write, including the awkward case. Design the surface that makes those lines read well, and only then work out what has to be true underneath. Every good small library was designed in this order, and every library that feels like a chore to use was designed in the other.

Defaults are the most consequential decision you will make, because most users never change them. A default should be the safe choice, not the fast one, and it should be the one that is correct for the reader who has not read the documentation. Anything that could lose data or leak information should require an explicit argument, because an explicit argument is a decision someone made.

Everything exported is a commitment. Prefer a small surface with an escape hatch to a large one that anticipates every need. Take an options object rather than four positional booleans, since named arguments survive additions and positions do not. And resist the configuration flag that exists because you could not decide: a library with fifteen flags has offloaded your design work onto every one of its users.