Proof an AI Consultant Can Ship: My Family Apps

The Problem: You Can't Tell a Builder From a Deck

Every AI consultant says they ship. The word is in their LinkedIn headline. It's in their pitch deck, usually right next to a stock photo of a glowing brain.

Deck vs Working Software as proof

The problem is you can't verify it until you've already paid them. And the proof an AI consultant can ship usually doesn't arrive until 60 days and a five-figure invoice in, when the "production-ready solution" turns out to be a Notion doc and a Zapier flow held together with hope.

I've watched this happen to people. A CEO gets burned once, then spends the next year suspicious of anyone who mentions AI. I don't blame them.

Here's the uncomfortable truth: a polished deck costs nothing to produce and proves nothing. I can generate a beautiful 40-slide AI strategy in an afternoon. So can you, now. So can the next vendor who walks through your door. The deck is not the work.

Even client case studies are weaker proof than people think. They get cherry-picked. They get ghostwritten. The numbers get rounded up until they stop meaning anything. A case study tells you what the consultant wants you to believe, not what they actually built.

So what's the convincing proof? For my money, it's working software built for people you can't afford to disappoint.

Not a client who signed an NDA and moved on. Not a logo on a slide. Software you can open, click around in, and break, built for someone who will be hurt if it fails.

That's the thesis of this whole article. I'm going to walk you through the apps I've built for my own family and friends, and I'm going to explain why those projects are better evidence of a builder than any case study I could write. If you're pragmatic, time-starved, and tired of hype, this is the kind of vetting that actually saves you.

Why I Build for My Own Family (And Why It Matters to You)

Client work has an escape hatch.

The four family/personal projects and their forcing constraints

When a feature is a little flaky, you ship it anyway and patch it next sprint. The client doesn't notice, or they file a ticket, or it gets buried in the backlog. There's always a deadline and a budget and a polite way to say "good enough for now."

That escape hatch disappears when you build something for your own family.

When I built a private AI health dashboard for a family member that touches real medical records, there was no "patch it later." If it leaked data, that's a person I love exposed. If it gave bad information, that's a real decision made on bad information. The stakes force production-grade decisions you can skip when it's someone else's money and someone else's risk.

I've built four projects like this:

• A private AI health dashboard for a family member, built on real medical records
• A development tracker for a baby in my family
• A nutrition app for a friend who actually uses it every day
• A trainer for my own hobby that nobody but me will ever touch

"People you can't disappoint" is a higher bar than most paid engagements. A client can fire you. A family member who trusted you with their health data and got burned is a different kind of consequence entirely.

This is the same reason I tell clients I don't just advise on AI, I build it. Advice is cheap and safe. Building is where you find out whether someone actually knows what they're doing, because the software either works or it doesn't.

When I sit across from a CEO, I want them to see this. Not because it's charming. Because it's the most honest evidence I have that I finish things, and that I make the unglamorous decisions that keep software from blowing up in someone's face.

The Health Dashboard: When the Data Is Real Medical Records

What real stakes forced me to build

The health dashboard touches actual medical records for someone in my family. The moment I started, the whole project changed shape.

Health dashboard architecture with human checkpoint

Encryption at rest stopped being a "nice to have" and became the first thing I built. Access controls weren't a feature request from a compliance officer, they were the difference between protecting someone and exposing them.

I built it as a multi-agent setup that cites its sources instead of guessing. When the system surfaces something, it points to where that came from. No confident hallucinations about someone's health. That rule is non-negotiable when the user is family.

And there's a hard line I coded in deliberately: the AI never diagnoses. It summarizes, it organizes, and it prepares better questions to bring to a real doctor. That's the whole job. The medicine stays with the medical professionals.

The patterns a paying client needs

Here's why this matters to you, even though you're not in my family.

A healthcare client needs exactly these patterns. So does a financial advisory firm managing $500M+, or any professional-services business handling sensitive client data. Encryption, access controls, source citation, and a system that knows the boundary of its own authority. These aren't exotic. They're the baseline for any serious deployment.

The difference is where I learned them. I didn't learn them on a client's dime, fumbling through compliance for the first time while they paid me to figure it out. I learned them the hard way on something that mattered to me, where getting it wrong wasn't an invoice problem.

That's also why every serious system I build has a human checkpoint, which I wrote about in every system I ship stops for a human. The health dashboard taught me that lesson before any client did. The AI prepares, the human decides.

The Baby App and the Nutrition Logger: Privacy When It's Personal

A development tracker built around a real child

I built a development tracker for a baby in my family. The user is a real child, which immediately raised questions most demos never ask.

Child-data safety came first. Consent logging, so there's a record of what was captured and why. And a discipline I take seriously: never overstating what AI can infer from a short video clip of a baby.

It's tempting to make the AI sound impressive. "Your child is hitting these milestones early." But a 15-second video can't responsibly support that claim, so the system doesn't make it. It observes, it organizes, and it stays honest about the limits of what it actually knows.

A food logger with a friend's real data

The nutrition app I built for a friend is the kind of thing that lives or dies on boring reliability.

It does barcode and label scanning. It handles real customer-style data, entered by a real person who is not technical and will not forgive a crash. That meant doing the unglamorous work: handling bad inputs, dealing with offline cases, recovering gracefully when a scan fails or a label is half-readable.

That reliability work is exactly what separates a demo from something a person uses daily. A demo scans one clean barcode in good lighting and everyone claps. Daily use means the lighting is bad, the label is wrinkled, and the phone has no signal in the grocery store.

When the user is a friend who'll text you the moment it breaks, you don't ship vaporware. You build the error handling first. These are the same instincts a DTC brand or a services client is paying for, whether they know it or not.

The Hobby Trainer: Reliability Nobody Pays You For

The trainer I built for my own hobby is the purest test of the bunch.

No client. No deadline. No money on the line. Nobody waiting on a deliverable. Just my own standards, with nobody watching to make sure I held them.

That's the test, because there's nothing to hide behind. It forced things like voice input that actually works, not voice input that works in the demo and fails when you have a slightly hoarse voice or a fan running in the background. It forced accurate scoring and grading, because I'd immediately notice if the numbers were wrong, and a wrong score is worse than no score.

Most of all, it forced the discipline of finishing instead of abandoning the project at the demo stage.

Here's a thing most people who "build with AI" won't tell you: they have a graveyard. A folder full of half-finished prototypes that worked once, looked promising, and got abandoned the moment the fun part was over and the boring part began.

Finishing software with zero external pressure is the rarest signal of a real builder. Anyone can start. The trainer proves I finish, maintain, and live with my own work, even when literally nobody is paying me to.

If a consultant can't point to one thing they built and kept running purely for themselves, ask yourself how they'll treat your project once the invoice clears.

What a Personal-Project Portfolio Proves That a Case Study Can't

Let me turn this into something you can actually use. Here's the checklist a personal-projects portfolio reveals, and a curated case study hides.

Personal portfolio checklist a case study hides

Can they ship to production, not just prototype? A demo and a deployed system are different sports. Personal projects that real people use every day are deployed, not demoed.

Do they handle security, encryption, and consent when no compliance officer is forcing them? The health dashboard and the baby app forced these on me with nobody auditing the work. That instinct either exists or it doesn't.

Do they build human-in-the-loop safeguards by default? When the data is your family's, you don't let an AI make the final call. You build the checkpoint because you'd never forgive yourself otherwise.

Do they finish? The hobby trainer answers this one cleanly.

I've built 15+ AI systems across health, nutrition, development tracking, and my own businesses, on top of 22,000+ lines of custom Python in my own toolkit. I'm not going to tell you every one is perfect, because they aren't. Some features I'd rebuild today. But they're real, they run, and people use them.

That's the antidote to the vaporware problem. Most AI projects die in the slide-deck phase, which is a big part of why most AI projects fail. They never reach the part where reliability, security, and finishing actually matter.

A personal portfolio can't be ghostwritten. The software either opens and works, or it doesn't. That's the kind of proof an AI consultant can ship that you can verify with your own eyes.

How to Vet the Builder You're About to Hire

Before you sign anything, ask these three questions. They'll tell you more than any deck.

Three vetting questions to ask a builder

"Show me something live you built that you don't get paid for." This separates the builders from the deck assemblers instantly. If the only things they can show you are behind a client NDA, you have no way to verify anything. If they can open an app on their phone and hand it to you, that's real.

"Walk me through how you handled the worst-case failure." Real builders have scar tissue. They'll tell you about the data input that crashed everything, the offline case they missed, the hallucination they had to engineer around. People who only made slides will give you a vague answer about "robust error handling."

"Who breaks if this software goes down?" Ask who actually depends on the things they've built. If the honest answer is "nobody, it was a demo," you've learned something important.

This is exactly how I'd want to be evaluated. It's why I show working software before I show a proposal, and why my family apps matter more to me as proof than any logo I could put on a slide. The real difference here is what actually separates a builder from a consultant, and it comes down to whether there's something running at the other end of the conversation.

You don't need to trust my pitch. You need to see the software and ask the hard questions. That's the whole point.

Thinking about AI for your business?

If this resonated, let's have a conversation. I do free 30-minute discovery calls where we look at your operations and find where AI could actually move the needle, not where it makes a nice slide.

No deck. We'll talk about your real problems, and I'll show you working software if it's relevant.

Book a Discovery Call