What a beautiful quip.
What if I'm building driving theory testing software? That's a very on the nose example. What about ticketing systems? Reminder app? TODO app? Wishlist functionality?
—
Write clear error messages that provide a way forward. Accept your system will have bugs, and ensure the system state is communicated to the user so they know if their TODO/Test/Reminder/Wish was stored/updated/deleted. Do your utmost to prevent data loss - even when that data hasn’t been formally introduced to your data storage of choice.
Developers should not worry about their sprints being blown because they have to use your APIs. Teams trying to pass off tasks or getting special commendations for dealing with your software should be embarrassing. If developers are wrapping your API in their API, are they doing it because they need the abstraction or because abstracting it once and tracking changes is easier than using it?
Ensure there are logs in place to assist debugging and documentation catered towards end-users, operations, support, and developers. Track relevant metrics to allow for automated fixes and manual intervention so users aren’t the ones having to remind you your software is broken.
Every piece of software has a user - a person, an organization, other code - and software that doesn’t make the user’s life easier increases the chance they’ll stop using it.
Or worse, start using it incorrectly!