Even to do something like a simple library and to publish it professionally will need `high quality`: code, tests, documentation (user/developer/guides), examples at a minimum. Basically the long tail of polishing is that 80% perspiration, 19% perspiration is to get to the stage (MVP may be) where you get on to polish it and that 1% innovation is when you kick your backside to get going!
I don't generally write documentation or tests when I start a library. I'll maybe write a couple tests if I want an indicator of when I'm done. I get it working, and then release.
Then, as I use the library, if a bug comes up that seems like it might come back, I add a test. If I break something accidentally, I add a test for that. And if I can't remember how an interface works, I document it in the readme.
That's it. Over time my documentation and test coverage come to match my use of the library. Anything I don't use gets deleted. And I end up with pretty ok documentation and test coverage.
The philosophy is: your first interface is never right anyway, so don't bother testing or documenting it. Just document the stuff you fix.
Even to do something like a simple library and to publish it professionally will need `high quality`: code, tests, documentation (user/developer/guides), examples at a minimum. Basically the long tail of polishing is that 80% perspiration, 19% perspiration is to get to the stage (MVP may be) where you get on to polish it and that 1% innovation is when you kick your backside to get going!