That's roughly what I did. I often do side projects with two goals: there's something I want to exist, and something I want to learn. And I'll learn that thing by using it to build something I want.
At one point, the thing I wanted to learn was "call something done". So I did that, and because it was a side project with learning as an explicit goal, I was able to actually do that - it was literally impossible to ship something imperfect, as shipping would already mean I'd perfectly reached my goal.
But that turned out to be enough faking it to make it - the feeling of shipping it felt good, and gave me the confidence to spend a small amount of time to polish my side projects up enough for shipping, rather than a large amount of time to do everything I want. And it's way more fun now to be able to occasionally pull up an old side project of mine that's still usable, because I got it to a usable state in the first place.
The best I’ve been able to do is: if perfection == high quality, then shipping smaller iterations faster is the most cost-effective means of improving quality.
I did that too :) I learned that sometimes, I'd ship the perfect wrong thing. And to avoid that I'd ship earlier versions faster and get back to it after feedback.
Basically I want TDD(make it run!). I want something runs and everyone can see it. Ship faster, get it run faster, get feedback faster, improve faster, iterate faster.
So.. Can you trick yourself into directing the perfectionism into shipping fastest?