WhatWeOrdered: How a Family Dinner Frustration Turned Into My First App
A family dinner fail sparked a crash course in AI, product building, and letting go of perfection.
There are a couple of days every week when cooking dinner - even if everything’s prepped - just doesn’t make the priority list.
I’ve had a long day, the kids want something entirely different from what I’d planned, and all I want is to sit under the evening sky, quiet my mind, maybe sip something warm (or cold), and not cook.
So, we do what every family does: order in. Because sometimes that’s the only sane option after a long day.
The churn of new restaurants on delivery apps keeps things interesting, but that’s also the problem. There’s too much choice, and no memory. We’ll try something, love it (or hate it), and three months later - when the same craving hits - we forget whether it was a hit or a flop.
One evening, we ordered Mediterranean from a place that looked vaguely familiar. I checked the order history; it showed we’d ordered before, so it must’ve been good.
Spoiler: it wasn’t.
Dinner arrived, and as we sat down, everyone remembered: Oh right, this was the one we didn’t like.
Cue hangry kids and mild marital eye-rolls.
That’s when I realized - this needed to be logged somewhere.
But a running Google Doc of “family food reviews”? Absolutely not.
The Spark That Turned Into a Build
It wasn’t a “save the world” kind of problem, but it was our problem.
We order often. We love trying new restaurants. We just needed a way to keep track of what worked (and what didn’t) for each family member.
My partner, ever the instigator, started saying after every new dish:
“Note it in your app. This is why we need that app.”
Eventually, I caved. Given that I’m in a phase of re-entering the workforce and upskilling, it felt like the perfect sandbox experiment.
But I had no idea where to start.
Curious and a little lost on where to begin, I turned to ChatGPT for help. After a few exchanges, I learned that for any product to move beyond the idea stage, it needs a document called a PRD (Product Requirement Document). I didn’t know what that was, so I asked my partner, an entrepreneur and product expert. We brainstormed the idea together, I mentioned it to a few friends (who nodded that it was nice-to-have, not must-have), and then finally opened a blank doc to start writing.
With some clarity on what was needed, I started typing out a prompt to help write a PRD:
“Idea: An app that helps you review & rate the restaurants that you have ordered from using food delivery apps. This is household-specific to take note of the various restaurants ordered from (whether takeout or delivery), reviewing it - whether you liked or didn’t like the food and to take note of a particular dish that might have been preferred over the other. The app also also gives the option to select which dish was like by which household member. The goal is to ensure that you have a directory (and history) of food ordered from restaurants and to prevent ordering from the same restaurant where you didn’t like the food. The value of this app is to make sure that every food experience is a great one and can be repeated. Same with a negative experience.
Use case: We are a family of 4 with kids 7 & 3.5. There are many days when we don’t want to cook and would rather order in. There are specific cuisines we like and are always open to exploring new cuisines as well as trying out new restaurants. We have had experiences where we want to eat a particular cuisine, and the food delivery app shows the top-reviewed & previously ordered from restaurants. But it was only after we ordered the meal again that we realized we didn’t like their food. This has happened with other restaurants where we remembered a dish but didn’t know which restaurant it was ordered from.
Product: I visualize this to be a mobile app that allows you to add your meal details - restaurant name, dishes ordered, and rating/review of it. integrates the food delivery apps to allow for me to review the dishes that I ordered & make a note of any dishes that were like or would not order again. Person’s preference would also help (For example: If my 7 year old liked the lamb roll from XYZ restaurant, I want to take note of that so I can order it again). This would be a good product to share amongst friends to say “Hey! Your friend just ordered from XYZ and really liked the food. Would you like to try as well?” I don’t know how I can monetize it but restaurant referrals within the app could be one way.
I want to write a Product Requirement Document for an idea that I have. Help me write a detailed one. Be my strategic coach and thought partner in creating this document. Ask me any clarifying questions to help create a crisp, thorough document that can then be shared to design and build the product.”
That was it - the start of my build.
Research and strategy are my comfort zones, and this felt like the natural bridge between idea and execution.
From Blank Page to PRD
Two hours and many clarifying questions later, I had my first PRD.
It wasn’t perfect, but it was enough to hand off for prototyping or, in my case, vibe coding.
Building It Without Knowing How to Code
For anyone new to the term, vibe coding allows non-engineers to use natural language to describe what they want, and the AI builds the code.
After some research, I shortlisted Lovable, Bubble, and Base44.
Lovable was my partner’s pick - he’d used it to build a health app.
Bubble was interesting, but still in beta for mobile.
Base44 was the most user-friendly, so I went with it.
Naming and branding came next.
I used Namelix for ideas (because, of course, everything is taken) and Brandmark for a quick logo and color palette.
The designer in me wanted to perfect everything, but this project was also about learning to let go. The goal wasn’t beauty… it was shipping something real.
What Came Easily and What Didn’t
My background in design strategy made user flow thinking easy.
I’m the target user, after all, so I could imagine what onboarding and daily use would feel like.
But integrations? Completely new territory.
The Google Places API almost broke me.
Thankfully, Base44’s documentation helped me figure out how to autocomplete restaurant names in the form.
Small wins.
Where It’s At Now
The project is live as a basic MVP web app with 10 registrations but no active users yet, no feedback loops, and no scaling plans.
And that’s okay.
This was an experiment in:
Learning how to build something from 0 → 1
Understanding user onboarding and feedback loops
Getting curious about conversion, engagement, and growth
And more than anything, it proved that curiosity is the best re-entry skill.
What’s Next
I’m not sure if I’ll keep building this one. It’s a nice-to-have, not a must-have.
But now that I’ve figured out how to go from PRD to MVP, I’m ready to explore other ideas - like building something for beginner gardeners (my next obsession).
For now, I’m just celebrating that I built something - without knowing how to code.
If there’s one piece of advice I’d give to anyone itching to “start something” but unsure how:
Take one non-zero step.
Before wrapping up, I found myself reflecting on how small steps add up… how progress doesn’t always have to be monumental to matter. I came across a Reddit post about Non-Zero Days, which did it for me.
It’s a philosophy that doing even one small thing toward your goal each day keeps momentum alive. Read it here.
Try.
Build.
Tinker.
Even if it’s imperfect. Even if it’s just an idea in a doc.
Because sometimes, one small action is enough to change everything.
What’s your small experiment, and how are your non-zero days going?
Love this! What a fantastic experimental project!!