What I Learned Building a Meal Planner Nobody Asked Me to Build
I didn't set out to build a meal planner. I set out to solve a thing that kept bugging me — the gap between someone having a good idea for Sunday dinner and that dinner actually happening. That gap is wider than it looks.
The problem I thought I was solving
My starting assumption was wrong, which is probably the most useful thing I can tell you.
I thought the problem was recipe discovery. People don't know what to make. Give them AI-generated ideas, personalized to their household, and the problem goes away. Clean thesis. Wrong thesis.
Discovery is easy. You can get recipe ideas from Google, from TikTok, from your mother-in-law, from the side of a box of pasta. The world is not short on recipe suggestions.
The actual problem is execution collapse. You get a great idea on Thursday. By Saturday you've half-forgotten it. Sunday morning arrives and someone is missing an ingredient, or one person in the house doesn't eat that thing, or nobody wrote it down anywhere, and you order pizza. Not because pizza is better. Because the plan dissolved.
Once I reframed it that way, the product got clearer.
What the AI actually does (and doesn't do)
I'm using OpenAI's API to generate the weekly menus. The generation prompt does more work than the model — I spent more time engineering the prompt structure than I spent on most of the frontend code.
Here's what surprised me: the hardest constraint to satisfy isn't dietary restrictions, it's occasion. Sunday dinner isn't Tuesday leftovers. It wants a main event. It wants something that photographs well even if nobody's taking a photo. It wants a little effort that signals this meal is intentional.
The model doesn't know this instinctively. I had to encode it. I had to say: a Sunday dinner suggestion that includes "sheet pan chicken thighs" is failing the brief. Not because sheet pan chicken is bad — it's great — but because it doesn't carry a Sunday. Give me braised short ribs. Give me a whole roasted chicken. Give me Sunday.
The other thing I got wrong early: I thought per-person preferences would be a nice-to-have. Turns out it's the whole product for households with kids, allergies, or anyone who has a strong opinion about cilantro. If your system generates a menu with shrimp and one person in the house can't eat shellfish, the whole menu is dead. I moved per-person preferences into the Pro tier because that's where most of the engineering lives too — it's not gatekeeping, it's where the real work happens.
The technical decision I made that I'd make again
Next.js on Vercel, Supabase for the database and auth, OpenAI for generation. Nothing novel. I could write a defense of each choice but the honest reason is: I've worked with these tools, I knew how they'd fail, and I could move fast without fighting infrastructure.
The one decision that saved me a month of future pain: I built the auto-generation pipeline as a Supabase Edge Function triggered by pg_cron, not as a Next.js API route. Generation runs on a schedule, server-side, completely independent of any user session. Users get their Sunday plan without having to trigger it manually. It just appears.
If I'd built it the obvious way — user hits a button, API route fires, OpenAI responds — I'd have had to deal with timeout issues, loading states, retry logic, and every variation of "what if the user closes the tab." The Edge Function approach made all of that go away.
What I got wrong
I underestimated how much households vary. I built the first version assuming a household of two adults with no strong restrictions. The first ten people I showed it to included: a family of five with a vegetarian teenager, a couple where one person is avoiding gluten (not celiac, just avoiding), a household of three where two people hate the same thing but for different reasons, and a single person cooking for herself who wanted "something that scales to four if people show up."
The product I shipped handles this. The product I designed didn't. There were two months between those two things.
I also underestimated how much the name matters at the start. Five Sharp is a good name. It has some grip. But it doesn't immediately tell you what it is, which means the first sentence on the landing page has to do a lot of work. I rewrote that first sentence eleven times. I'm not sure I'm done.
What I'm still figuring out
Pricing. I locked tiers (Free, Middle at $12.99, Pro at $19.99) based on gut feel and competitive research. I don't know yet if those numbers are right. I'll know in sixty days.
The swap feature — Pro users can swap out a single dish without regenerating the full week — is one of those things I thought would be a footnote and turned out to be something people mention first. That's telling me something I haven't fully unpacked yet.
Building in public feels like a reasonable bet for something in this space. Households have this problem every week. The audience is enormous and diffuse. The best way to find early users is probably to just be honest about what I'm building and let people self-select.
That's what I'm doing here.