How I Organize My Plant-Based Recipes in Notion

I used to keep recipes in five places at once: screenshots in my camera roll, bookmarks in three browsers, a couple of cookbooks, and a notes app that I never opened. The result was predictable. I'd stand in the kitchen at 7pm with no idea what to make, scroll for fifteen minutes, and give up on pasta. Again.

Moving everything into a single Notion database fixed that. Not because Notion is magic, but because it forced me to make a few decisions once instead of every night. Here's the system I actually use.

One database, not ten pages

The core mistake people make is treating Notion like a folder of documents. A recipe isn't a document you read once. It's a record you filter, sort, and pull up under specific conditions: "vegan, under 30 minutes, uses the chickpeas I already have." That's a database query, not a bookmark.

So everything lives in one database called Recipes. Every recipe is a row. The page body holds the ingredients and method; the properties hold everything I filter on.

The properties that actually earn their place

I've trimmed this list over a year of use. Properties that I never filtered by got deleted. These are the ones that survived:

• Meal type (Select): breakfast, lunch, dinner, snack, dessert. The single most-used filter.
• Cook time (Number, in minutes): lets me sort ascending when I'm tired.
• Effort (Select): low / medium / project. "Project" recipes only happen on weekends.
• Main ingredient (Multi-select): tofu, lentils, chickpeas, mushrooms, etc. This is how I cook from what's in the fridge.
• Cuisine (Select): keeps variety up so I'm not eating the same three dinners on rotation.
• Status (Select): want to try / tried / favorite / nope. Brutally honest. The "nope" tag saves me from re-cooking disappointments.
• Source (URL or Text): where it came from, so I can credit it or check the original.

That's it. Seven properties. Resist the urge to add a star rating and a thumbs system and a tag cloud. Every extra field is a field you have to fill in, and the ones you don't fill in make the whole thing feel broken.

Views do the real work

The database is one table, but I almost never look at the raw table. I look at views, each one answering a question I actually have:

Weeknight (filtered + sorted)

Filter: Cook time ≤ 30 AND Effort is low. Sort by Cook time ascending. This is my default view. When I open the database, I see fast, easy options first, not a wall of 400 rows.

By main ingredient (board)

A board view grouped by Main ingredient. I open the fridge, see I have mushrooms and spinach, and jump straight to those columns. This single view killed my food waste more than any meal-plan app did.

Favorites (filtered gallery)

Filter: Status is favorite. A gallery view with the recipe photo as the cover. This is my "I can't decide" view — proven winners only.

To try (filtered)

Filter: Status is want to try. My backlog. When I save a recipe, it lands here, and I pull from it whenever I want to break routine.

How I capture a new recipe in under a minute

The system only works if adding to it is frictionless. My capture flow:

1. See a recipe anywhere (Instagram, a blog, a friend's text).
2. Use the Notion web clipper or the mobile share sheet to send it to the Recipes database.
3. Set three properties only: Meal type, Main ingredient, Status = want to try.
4. Done. I fill in cook time and effort later, when I actually decide to make it.

The trick is not trying to fully process a recipe at capture time. Capture is cheap; processing is what kills systems. Get it in the door with three tags, refine on use.

What I deliberately left out

• No nutrition tracking. It's a different job. Bolting it onto a recipe library makes both worse.
• No auto-generated shopping lists inside this database. I keep a separate grocery list and copy ingredients over. Trying to make one database do meal planning and recipes and groceries is how you end up with a beautiful system you never use.
• No relation to a calendar at first. I added a light meal-plan relation only after the recipe library proved itself. Build the part you'll use daily before the part you might use weekly.

The honest result

A year in, the win isn't aesthetic. It's that "what's for dinner" is now a fifteen-second filter instead of a fifteen-minute scroll-and-give-up. The board-by-ingredient view alone changed how I shop and how much produce I throw out.

If you're starting from scratch: build the single database, add the seven properties, make the Weeknight and By-ingredient views, and use it for two weeks before you add anything. The constraint is the feature.