A few other thoughts: 1. Instead of hosting the images yourself, you're linking directly to Meredith Corp's image servers. They probably won't appreciate that;

A few other thoughts: 1. Instead of hosting the images yourself, you're linking directly to Meredith Corp's image servers. They probably won't appreciate that; if you scaled this out enough they'd likely ban your referrer (and that's if copyright doesn't turn out to be a bigger issue first). 2. 199 recipes is too few. I'd say you don't really have anything to demo, or a good dataset to experiment with on your side, until you have tens of thousands. 3. Your search-by-ingredient and search-by-name both do the same thing; they just make a words list and set it as the query for MeiliSearch. Meaning it just fuzzy matches against all the attributes of every document in the database. That's not any more helpful than a generic search engine. I expect a purpose-specific search engine to take advantage of its domain knowledge; e.g. it should: i. Know ingredient synonyms ii. Recognize when an ingredient a trivial product of another ingredient (e.g. egg whites are trivial from eggs, but rice vinegar is not trivial from rice). iii. Other than those two cases, ingredients matches should not be fuzzy. It's no good if baking power matches when all I have is baking soda, or if buttermilk matches when I have butter. 4. The documents in your database are not well curated (which will make #3 more difficult). You're actually leaning pretty heavily on fuzzy matching. For example, in the DB "vegetarian" is misspelled as "vegatarian". And many ingredients have leading whitespace, including newline characters. Keep your DB clean and you'll be able to take advantage of fuzzy matching when appropriate but still retain the ability to do exact matching.