Industry and personal projects have much more requirements ambiguity than CS homework and projects. You will need a way to "handle" this ambiguity. For example, what does "search" mean? By keyword? By ingredient? Can I restrict a search to only a specific set of ingredients? Can I specify measurements in metric and it can auto-convert for me? You don't need to answer these questions specifically, but have some way of capturing these requirements as you go along so you both get what you want and don't forget anything along the way. How you capture these are up to you. A couple methods I've seen are formal SRS (overkill for you), user stories, and scribbles on post-it notes. Use whatever you're comfortable with.

It seems like the "db" and "gui" are your biggest technology unknowns and have the greatest impact on your project. It would kinda stink to build out all your core logic and find out 3/4 in that you can't hook up to a db or gui in the way you expect. After you have a decent idea of what your requirements look like, prototype with technologies to figure out what their assumptions are and how you can integrate it with your product.

Once you reasonably figure out what you're trying to build and how you're going to build it, it becomes going through the motions and building the thing.

Don't feel like you need to figure everything out before executing - no real world project is like that; we all deal with some level of ambiguity. You'll clear up your own ambiguities as you go along.

Welcome to software engineering.