Choosing an LLM for a Health AI Coach: Production Lessons

Most health apps are built to look backward. A user logs a meal, the app scores it, and the advice arrives after the damage is done. For someone newly diagnosed with type 2 diabetes, that timing is the whole problem.

One self-funded founder ran into it firsthand. After his diagnosis in early 2025, his doctor sent him home with medication, a few pamphlets, and instructions to change his diet before the next visit in three months. Every app he tried told him what he should have eaten. None would tell him what to order while he was still holding the menu.

He mapped out the product he wanted in a slide deck and brought it to AppMakers USA, a custom software development agency with offices in Los Angeles, New York, San Diego, and Santa Monica. The result is an AI diabetes coach, live on iOS and Android since January 2026, that answers questions before a meal instead of after it.

The build offers a useful look at the decisions that matter when a small team puts a large language model into a health product: which model to trust, what the AI should never be allowed to say, and how to get through app store review.

The product: a coach you ask before you eat

At the center of the app is a conversational AI coach. Users ask it questions in the moment, such as whether a dish fits their goals or what to swap on a menu, and get short, actionable answers.

Around the coach, the team built the pieces a daily health tool needs:

• Glucose tracking, with readings tagged as in range, high, or low and a weekly average
• Personalized onboarding that captures sleep, habits, and history so the coach’s guidance fits the person
• Fast reading entry, tagged by meal, bedtime, or other context
• A cuisine-aware meal planner on iPad, with macros and a glucose-friendly tag on every meal
• Photo analysis of dishes, menus, and nutrition labels
• Notifications and a subscription paywall

“The founder wasn’t asking for another tracker,” said Dan Haiem, CEO of AppMakers USA. “He wanted something that helps at the exact moment a decision gets made. That shaped every technical choice after it.”

Benchmarking the models instead of picking the default

The team’s most important decision was which model would power the coach. A health assistant has to be accurate and fast, and it can’t become expensive as users grow. So instead of defaulting to the most familiar option, AppMakers USA’s engineers benchmarked several large language models side by side, including OpenAI, Anthropic’s Claude, and DeepSeek.

Each model was scored on five criteria:

Criterion	Why it mattered for a health coach
Response quality	Answers had to be accurate and aligned with what the user actually asked
Speed	Users ask in the moment, often at a restaurant table
Reliability	A coach that fails mid-conversation loses trust fast
Developer experience	A small team needed to iterate quickly
Cost	A self-funded app has to stay affordable as usage grows

OpenAI came out ahead on the measure that mattered most for this product: the most accurate, user-aligned answers. It also offered the performance and scalability to iterate quickly without extra infrastructure to maintain.

“We choose the model for the product, not for the logo,” Haiem said. “The right answer for a health coach might be different from the right answer for a coding tool or a support bot. You only find out by testing on your own use case.”

The lesson for other teams is less about which vendor won and more about the process. Model choice is a product decision, and it’s worth benchmarking against the criteria your users will actually feel. For how the leading models compare today, see our ChatGPT vs Claude vs Gemini comparison.

Vision: the feature that hooks users

The feature users latch onto first is the camera. Point it at a dish, a menu, or a nutrition label, and the coach reads it back: estimated macros, what to order, and what to swap out.

During testing, the founder aimed the camera at a bowl of Halloween candy. The coach listed every item, including small candy bars buried so deep they couldn’t be seen by eye. It had identified them from a thin sliver of wrapper.

For a person managing blood sugar, that kind of detail is the difference between a useful answer and a misleading one. It also shows why multimodal input matters for consumer health tools. People don’t want to type out what’s on their plate. They want to point and ask.

Guardrails: what the AI can and can’t say

In a health product, trust breaks the moment the AI oversteps. The team drew firm boundaries early, splitting the product into two layers:

• AI-driven: conversational guidance, meal suggestions, and photo analysis
• Deterministic and rule-based: the parts where a wrong or creative answer would be risky

Those boundaries did double duty. Beyond keeping the coach safe, they kept it useful. A tightly scoped AI gives short, clear guidance instead of a long, hedged essay, which matters when someone is standing at a restaurant counter.

“The biggest mistake we see in health AI is letting the model do everything,” Haiem said. “Decide up front what the AI owns and what stays in fixed logic. It makes the product safer, and it makes the answers better.”

Getting a health AI app through app review

Shipping the app turned out to be its own challenge. Both Apple and Google classified it as a health app and required clear language that it doesn’t replace advice from a physician. The team added the requested disclaimers.

Apple rejected the app again anyway. The project manager and lead engineer went back to the reviewer, pointed to the exact screens where the disclaimer language had been added, and asked for a second look. The app was approved a couple of days later.

For teams building in health, the takeaway is practical: plan for review friction, put disclaimers where reviewers will find them, and be ready to point to them directly.

Building AI on a self-funded budget

The founder had no investors. Every dollar came from his savings, and he had a hard budget line. That forced a discipline many funded teams skip.

• Prioritization: the team walked him through what mattered for launch versus what could wait, and cut the rest
• Communication: daily updates on Slack with the engineer and PM, plus weekly release reviews
• Realistic scheduling: hours were scoped against a real calendar, holidays included, targeting a November to December finish

The team hit that window, and the app launched on the App Store and Google Play in January 2026.

“Founders want everything in version one,” Haiem said. “Our job is to be honest about what moves the product forward now. With AI features especially, a focused first release teaches you more than a bloated one.”

What other teams can take from the build

The app is still early, growing as an independent, self-funded product. The founder reports that users, especially people who were newly diagnosed and felt lost, are telling him it helps. That’s exactly who he built it for.

For teams putting AI into a health product, the build points to four lessons:

1. Benchmark models on your own use case. Score them on what your users will feel: accuracy, speed, reliability, and cost.
2. Lean into multimodal input. In consumer health, a camera often beats a text box.
3. Draw the AI’s boundaries early. Decide what the model owns and what stays rule-based.
4. Plan for app review. Health apps face extra scrutiny, so make disclaimers easy for reviewers to find.

“AI makes it possible for a single founder to ship something that would’ve needed a much bigger team a few years ago,” Haiem said. “But the model is only one part. The decisions around it are what make the product trustworthy.”

Dan Haiem is the CEO of AppMakers USA, a custom software development agency that builds mobile and web apps for founders and enterprise clients.

Related articles

• Perplexity vs ChatGPT vs Google AI Mode: 37% vs 67% [2026]
• SGLang Setup: 22% Faster LLM Serving in 13 Steps [2026]
• GLM-5.3 Reasons About Training in 10 of 6,452 Runs [2026]
• Reflection Ships Beam: 501B Params, 23B Active [2026]