Yeah, I am struggling a bit with this analogy of a car. I am building a what I can only describe as "Supplement discovery based on science and not marketing".

Yeah, I am struggling a bit with this analogy of a car. I am building a what I can only describe as "Supplement discovery based on science and not marketing". It requires that I create a database of supplements available on the market, then allow to compare them at a ingredient level to understand which is the best one to buy. I started building this out of frustration of trying to figure out which supplement I should buy myself. It took a ton of time to build a comparison table ( Here is one example https://docs.google.com/spreadsheets/d/1vQcLEAPk5lcg-4YR_dwDMO1HwrulBimjNfH4vra2e80/edit#gid=0 https://docs.google.com/spreadsheets/d/1vQcLEAPk5lcg-4YR_dwD... ). So I validated with a spreadsheet that people find it useful. And then I started building the data model for representing this across all supplements. And this is where things have gone a bit south. Somehow now I have most ingredient data at a molecular level. I tell myself that I needed to go this deep to ensure data quality (def don't want to accidentally misrepresent ingredients). I am over this hump now, i.e. I have indexed and categorized every ingredient of over 10k+ supplements. Now I am just building the UI to compare them, but it feels like dug myself into a whole for a good part of the week. Will see what happens once I make this public; if people use it would be hugely rewarding. But going to the car analogy... my mind is telling me that doors, a windscreen, or bike rack are all nice to have things that translate to various compromises in the UI. Just keeping that extremely simple. But that data integrity is not something I can compromise on (it is like letting car for a ride with an engine that may break). Don't know how this way of looking at things is true for others. Sometimes I feel like I just have an OCD specific to designing the underlying data architecture.