3 ms·
hmm, good point. I didn't look at it from that POV. When I'm trying to scratch an itch, I try to get something 'rough' and then try to add the bells and whistl
by nocommandline 6y ago
hmm, good point. I didn't look at it from that POV.
When I'm trying to scratch an itch, I try to get something 'rough' and then try to add the bells and whistles later on. Mentally, I always think of that 'rough' bit as 'my own MVP' i.e. what are the minimum features I need to build for this tool to solve my problem.
For example I needed a self hosted solution to convert svg images to png. I need a way to specify the image to be converted, code to convert it, and a place to store the output. My first build had a text field where I manually enter the path to the svg file I need to convert, and I hardcoded the output folder. I thought of that as my MVP. When I was sure the code was working and much later on when I had the time, I added a file picker to allow me pick the input file and another file picker for me to specify the output location.
- hnarn 6y agoThe "product" part of MVP refers to something you sell (rather, offer) in a market, and the "minimum viable" part refers to it being barebones but functional enough to be "sellable" and provide value, ie someone that isn't you is willing to go through the stated process to install and use it. So writing a tool that you use yourself without "customers" (used loosely) isn't in my mind an MVP, and neither is a product with no thought given to distribution.