Ask HN: Is week a too long of time to build an MVP?
I am working to validate an idea. I've seen many threads that suggest it should take a few hours. I am pretty confident that I won't have workable prototype for at least a week, and I am wondering if I am overcomplicating.
Stop reading message boards telling you what to do and focus on building your MVP.
Go over every requirement and decision and defer or remove any that an MVP won’t require. For example, an MVP car (which took more than a couple of weeks to build) needs an engine and wheels. It does not need doors, a windscreen, or bike rack.
If your MVP has a good foundation and communicates the business proposition well people interested in it can fill in the blanks and imagine the next iteration.
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.
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.
Nah, you're not over-complicating it. Stick to it though, and use the priority of shipping to help you ruthlessly defer things that can wait until later. Look for a minimum valuable experience that you can clearly deliver (or communicate) to the potential customer. Good luck!
Asking people for money before starting to build is the best way to validate an idea.
When people will give you money in hopes you will solve their problem, you will have a problem worth solving. Not an imaginary problem. Not an excuse to avoid the rejection that comes with asking people for money.
My idea is build a supplement store that allows discovery based on science, rather than marketing. You can search supplements based on their ingredients and see them in the context of research papers about it.
I am curious how this translates to what you are suggesting.
MVP stands for minimum viable product. The supplements are the product. You could be selling supplements today instead of planning a website.
And maybe you have solved all the real problems of inventory and cash flow and shipping and buying already.
Because you don’t need a different approach to sell supplements. Doing what everyone else does is a known solution. But it is harder than building a website.
Go over every requirement and decision and defer or remove any that an MVP won’t require. For example, an MVP car (which took more than a couple of weeks to build) needs an engine and wheels. It does not need doors, a windscreen, or bike rack.
If your MVP has a good foundation and communicates the business proposition well people interested in it can fill in the blanks and imagine the next iteration.
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_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.
Maybe the car analogy doesn’t apply. But consider Henry Ford went to market with just one model and color of car.
When people will give you money in hopes you will solve their problem, you will have a problem worth solving. Not an imaginary problem. Not an excuse to avoid the rejection that comes with asking people for money.
Good luck.
My idea is build a supplement store that allows discovery based on science, rather than marketing. You can search supplements based on their ingredients and see them in the context of research papers about it.
I am curious how this translates to what you are suggesting.
And maybe you have solved all the real problems of inventory and cash flow and shipping and buying already.
Because you don’t need a different approach to sell supplements. Doing what everyone else does is a known solution. But it is harder than building a website.
https://en.wikipedia.org/wiki/Hofstadter%27s_law