People sometimes wonder why 'personal projects', while they do have value, aren't always treated as equal to 'on the job' experience when it comes to job searching and creating a resume.
One of the reasons for that is essentially the same as why you can't put 'household' experience on your resume (see here for an example!): no one holding you accountable. Of course I mean mainly individual personal portfolio projects, rather than whole team efforts contributing to open source software.
When working on a personal project it's tempting, when encountering a difficulty or something you find uninteresting or not the main point of the project, to "handwave" that requirement away. You can do that, because in personal projects - you are your own product owner!
These days I try to create projects that are quite full-featured and well-rounded in terms of the technologies used and how they are implemented. Part of how I'll hold myself accountable for that is publishing more code in public repos and other places. Writing up and then sticking to the requirements even when it gets difficult. Seeing it through with proper configuration, writing decent comments, all the usual software development practices. As my own product owner, it's too easy to "delete" requirements I decide I don't like (that I came up with in the first place).
Even security and authentication is vulnerable to this line of thinking. Too many times I've seen (and sometimes put) security tokens etc directly into the source rather than handling this properly (config files, retrieving a token from a key store, etc) out of a desire to get done with that and focus on the 'real' purpose of the personal project. Very few people write unit tests for their personal project, I suspect. (I know I don't!)
Ultimately it depends on what you intend to showcase with the project. If it's a deep dive into some particular aspect of the tech then it's probably pragmatic to handwave "things that don't matter" or just assume them as a given. But if the aim of the project is more broadly to add depth and credibility to you as a developer, it is worth taking the time to deal with the "boring" bits as well as the fun ones. A real-life task is probably 80% stuff you'd consider boring.