"Then, it struck me: what if ingredient parsing was the business? If this was a problem for me, then surely other developers struggled with it as well. Hopefully, some of them made money and would give some of said money to me if I solved their problem. Thus, the idea was born for Zestful, my ingredient-parsing service."
Before starting to write a single line of code, you need to do market research and understand the opportunity size. Building a business takes several years of personal investment and you are betting a lot of potential missed opportunity on the "ingredient business" market. This is a common mistake that, again, I have made myself, too.
And really, one can learn so much about what people want without having them use anything. User context interviews are hugely helpful. But my favorite thing is real-world tests even before there's a product. If most of your sales will come via people clicking on an ad and looking at a landing page, test that first! If people won't sign up, there's no point in building anything after that.
A good example comes from my cofounder at a startup we did in 2010. At the time, we had theories about an app that people would mostly discover through their Facebook feed. We used Greasemonkey to do user tests and found out that although some liked our idea, most people hated it. So we threw that out and did something else. But two other startups went on to build the same idea and fail with it. We estimate we saved $2m in learning what they learned. Ignite talk here: https://vimeo.com/24749599
I suppose that this is still entering an existing market since the people who comprise the market exist already exist, but it's new in the sense that this group of people collectively have a need that isn't being met. And sometimes the goal of market research is just to find one of those unserved (or underserved) markets.
I think the market is not in parsing, but extracting nutrition information.
The project kind of came out of me needing ingredient parsing for a different product and existing solutions being a poor match.
Edamam requires you to display their logo in your app if you use their API, which I found inappropriately intrusive.
There's a similar service called Spoonacular, but they don't allow you to store results for more than an hour, which is crazy. I wanted to build a search index that let users search by ingredient, so it made no sense for me to reprocess my entire corpus of data every hourly.
But they succeeded and I didn't, so maybe the weird API terms are what they need to survive.