Thanks for digging deep. However, this question was not in relation to my previous Show HN post (damn internet :)). Since you did bring it up, I like to think

Thanks for digging deep. However, this question was not in relation to my previous Show HN post (damn internet :)). Since you did bring it up, I like to think that I'm aware of the reason for it not getting any attention. Long version: I got fixated on engineering, while forgetting about the core UX. Case in point: 1. the score you mention begins with a node service scraping a random page from lookbook, which contains a list of photos and their 'hypes' (likes); 2. then all the scores get normalized, where 1000 would be given to the highest hype score, all other being (hype*1000)/max_hype; 3. finally the sign of the score is based on whether you correctly guessed that the looks hype is more ('Fashn') or less ('No Fashn') than the average, non-normalized hype for a given page, and the nominal value of it is the difference between the normalized average and a given photo's score. I guess I didn't bother explaining this to the user, since the initial idea was to compare your taste to that of the lookbook community (read 'objectively fashionable'). However in approach above, the score for a photo is determined relative to the other photos on the page, but not other pages. Since relativity is unavoidable with the set logic, the user must be presented with a design that allows relative comparison. This, in turn, brakes the current minimalist design, which was one of the main features. This Buridan's ass state is where I stopped development, and decided to show it as is. HN wasn't the first place, and all the feedback resolved around a broken (not well explained?) core mechanic. Meanwhile, the restless mind queued up a number of ingenious ideas, and, not being socially pressed for time nor resources, I decided to move on.