Meallo: AI as a Build and Thought Partner

Solving human needs has always been my obsession. Early in my design career, that pull led me to teach myself engineering practices,  merging core design principles with code so I could not just envision solutions but actually build them. As I grew into design and product leadership, my focus evolved to framing problems, shaping vision, and empowering skilled teams to turn intent into something real. It’s work I value deeply. But the instinct to build things myself never quite went away.

Then I built Meallo.

Meallo is a personal, calendar-aware meal-planning app I built for my own household, a place to hold our recipes, plan the week around our actual schedule, and take the daily “what’s for dinner” decision off the table. I built it with AI as my engineering partner: tools like Claude and Claude Code that closed the gap between what I could envision and what I could ship. And in the process, the distance I’d made peace with for years quietly collapsed and reignited a passion for building.

Starting With the Problem

It started with something every family knows. Planning meals and coordinating them around a busy schedule is a small, constant weight, the kind of daily friction everyone can relate to. That was the starting point. The question was simply whether our AI-empowered landscape could provide real, clear value to a hectic life, and take a little of that weight off.

From there, the evolution of the tools made the rest possible. AI lowered the friction enough that skills I’d set aside became useful again, and the instinct to solve a real problem found a direct path to building the solution.

I worked with AI in two roles. The first was a kind of tech leader coach, a partner that translated my product intent into precise steps, sequenced the work, and explained the tradeoffs in plain language. The second was the hands on the keyboard, turning those steps into a real frontend, a real database, and working backend functions.

The result was energizing. My leadership judgment, the work of framing problems, making product calls, and holding the vision, now had a direct path to working software. There was no translation loss and no handoff gap. The distance between “I think it should work like this” and “it works like this” shrank to a single conversation. And the human need I started with stayed at the center the whole way through, which is exactly where it belongs.

The Minimum “Family-Approved” Product (MFAP)

To serve our family, Meallo had to do real things and forced the same discipline: what’s the real user need, what’s the simplest thing that serves it, and what can wait.

Lesson #1: Sequencing Is Key

When the cost of building drops and the speed of building rises, the scarce resource isn’t execution anymore. It’s judgment about order.

With AI able to build almost anything I described, I could have built everything at once and made a mess. The work that actually mattered was deciding what to build first, what depended on what, and what to deliberately defer. Structural UI before features, so features wouldn’t be built and then redone. Tagging before smarter planning, because clean data made everything downstream better. Cooking mode before a home screen, because the home screen’s value depended on it.

This is the same strategic muscle I’ve spent twenty years building with teams, just applied to a backlog of one. The tools changed. The discipline didn’t. If anything, AI made the discipline more important, because it removed the natural friction that used to slow a team down and force prioritization by necessity. When you can build anything quickly, choosing well is the entire job.

Lesson #2: When It’s Get Hard, Adjust To What’s Possible

Wins are only credible when coupled with the lessons.

Not everything was buildable. I had visions of automatic coupon optimization and grocery ordering tied to the stores we actually use. I spent real time investigating the paths: store APIs, coupon platforms, third-party services, and learned that most of that ecosystem is locked to commercial partners at a scale a personal app will never reach. The honest outcome was knowing when to stop. One integration path turned out to be genuinely viable; the rest I parked, and named clearly as parked. Killing your own good ideas with clear eyes is a leadership skill, not a failure.

Real systems carry real risk. Midway through, I tightened the app’s security, and in doing so temporarily broke key features. A calendar token expired and silently stopped pulling our schedule. These weren’t AI failures; they were the ordinary realities of running a real system. What mattered was staying calm, diagnosing methodically, and fixing the root cause rather than the symptom. The same composure I’d want from any team under pressure.

The build reveals the product. Designing for my own household surfaced truths no requirements doc would have. Our week doesn’t start on Sunday; it starts Saturday, the way our life actually runs. Some nights we eat late after our kids’ activities and need something fast and familiar, which became its own planning category. A step-by-step cooking mode is far more useful when it weaves the ingredient amounts directly into each instruction, so you’re not flipping back and forth with messy hands. You only learn these things by living inside the product you’re shaping.

What This Means for Design and Product Leaders

I don’t think my experience is a novelty. I think it’s a preview.

The barrier between conceiving a product and shipping one is dissolving. For those of us who’ve spent careers shaping vision and strategy, that’s a profound shift. We can now prototype our own thinking, not in slides, but in working software our users can touch. We can test a product instinct in a day instead of a quarter. We can feel the consequences of our decisions directly, with no translation layer in between.

That doesn’t make engineering teams obsolete. Real scale, security, and reliability still demand deep expertise, as my own stumbles made plain. But it does change what’s possible for a leader working alone or early. A few principles I’d offer to peers stepping into this:

• Lead the work, don’t just describe it. Bring the same problem-framing, sequencing, and judgment you’d bring to a team. The AI executes; you still decide.
• Treat order as your highest-value decision. When building is cheap, prioritization is everything. Build foundations before features.
• Stay close to the real use. Build for a real person, ideally one whose life you understand deeply. The product will tell you what it needs.
• Know when to stop. Not every vision is buildable. Investigating honestly and parking ideas with clarity is part of the craft.
• Respect the system. Working software carries real risk. Composure and methodical diagnosis matter more than speed when something breaks.

In closing…

Meallo will probably never be a company. It’s a meal planner for my own family, with a standing pizza night on Fridays. But building it changed how I understand my own role in the AI-embedded world we will live in.

For twenty years, I’ve helped teams turn vision into reality. What I learned building Meallo is that the gap between those two words is narrowing fast, and that the skills that matter most on the other side of it are the ones we’ve been practicing all along. Clarity. Judgment. Empathy for the person you’re building for. The discipline to do the right things in the right order.

There’s a more personal lesson underneath the professional one. The tools have evolved to the point where the instinct that’s always driven me, solving a real human need, can now run all the way through to working software. Building Meallo was a reminder that the craft and the leadership were never separate things. They’re the same obsession, finally with a shorter path between them.

The tools will keep getting more capable. The leaders who thrive will be the ones who remember that capability was never the point. Intention was. And the quiet gift in all this is how directly we can now act on it.