Healthcare AI to Consumer AI: What Changes When the Stakes Drop

Six weeks ago, I was on a call about a hospital denial code that, if our model misread it, would mean a real person got billed for a procedure their insurance was supposed to cover.

Today, I shipped a feature that helps someone find out whether they should take a job offer based on their birth chart.

The vibes are very different.

I left Mantys Healthcare AI — a Y Combinator W23 company building LLM systems for hospitals — to join Mynaksh as a senior engineer. Mynaksh is a consumer app that connects people with astrologers in real time. We do live calls, AI-powered horoscope readings, and an autonomous support agent that handles user queries.

To people outside engineering, this looks like a strange jump: from "saving lives" to "vibes." From inside the work, the actual difference is more interesting than that — and it's not what I expected.

The Stakes

Healthcare engineering is paranoid engineering. You ship something with 98% accuracy and someone in your standup will ask, "what about the 2%?" — because the 2% is sometimes a person who needed prior authorization for an MRI and didn't get it. You build evaluation frameworks. You build human-in-the-loop systems. You log everything. You assume your AI will fail and design backstops on backstops.

Consumer AI is not paranoid engineering.

I don't mean we ship slop. I mean the failure mode of "our AI told someone the wrong thing about their love life" is genuinely different from "our AI told a hospital the wrong thing about an insurance claim." The user lives. The user laughs at it on Twitter, even.

When the stakes drop, the engineering loosens up — and that's the first thing I had to recalibrate.

What I Carried Over

Here's the thing nobody tells you about leaving a hard-stakes job: the instincts are sticky.

My first PR at Mynaksh had three layers of fallback handling for an LLM call. It was for a feature where, if the AI failed, the user would just... see a slightly less personalized message. The reviewer was kind: "This is great. Also, you can delete most of it."

That was a moment.

Healthcare AI taught me to over-engineer. Consumer AI is teaching me when not to. Both are real skills, and I'd argue the second one is harder, because you have to actually trust your own judgment about where the risk lives.

The instincts that have been useful:

• LLM evaluation as a discipline. Even at consumer stakes, "is this output good?" is a hard question and you can't just vibe-check. We use evals. They look different from healthcare evals, but the muscle memory is identical.
• Human-in-the-loop as a design tool, not a crutch. In healthcare, humans validated the hard cases. In consumer, humans validate the delight cases — what makes a reading feel personal, magical, worth the price. You're still routing based on confidence; you're just measuring different things.
• Cost engineering. When you're processing 120k procedures a day, a 10x model cost difference is real money. When you're running an AI astrologer for tens of thousands of users a day on consultation traffic, it's also real money. Same problem, different domain.

What I Had to Unlearn

The unlearning is harder than the learning.

Latency. In healthcare, batching was fine. Nobody was watching the API call. We could spend three seconds on a Prior Authorization decision because the alternative was a human spending three days. In consumer, three seconds is a lifetime. People close apps. People give up. The Calls feature I'm working on now has to feel as instant as a phone call — because it is one.

Iteration speed. Healthcare ships through a compliance gate. Every change goes through review, audit, sometimes legal. We moved fast, but "fast" was relative. Consumer ships when you ship. There's a brutal honesty to it: if the feature isn't ready, you can't hide behind process.

The user. This is the big one. In healthcare AI, the "user" was usually a billing administrator or a PA expert. They were trained, patient, willing to read documentation. In consumer, the user is your aunt who wants to know if Mercury is in retrograde and why her phone is showing her three different messages and where is her astrologer. You design for that user. It is humbling.

What's Different About the Work Itself

The technical work has shifted in a few specific ways.

I'm building a lot more real-time systems now. Healthcare AI was mostly request/response — submit a claim, get a determination, wait. Calls are different. They're stateful. They have lifecycles. They have failure modes that involve audio packets dropping and connections re-establishing and your AI agent having to remember what was said three turns ago.

I'm doing more product engineering and less systems engineering. At Mantys I'd spend a sprint optimizing a pipeline. At Mynaksh I'll spend a sprint figuring out what makes an astrology reading feel good — what the prompt should know, what the LLM should retrieve, how the cadence of the response should feel. The unit of work is the experience, not the throughput.

I'm working with a different kind of model. We use a lot of LLMs, retrieval, prompt engineering, and increasingly some agentic workflows for the support side. There's less classical ML. The skill that's most valuable is being able to look at a model's output and say, "this is wrong in a subtle way and here's why." It's a literary skill almost.

The Y Combinator Question

People keep asking me if I miss YC.

The honest answer: I miss the people. YC concentrates intensity in a way that's hard to replicate. I don't miss the process. The thing I noticed when I left was that the work was always the work — investors don't make the codebase better. The PMF problem is the PMF problem regardless of whether you're in a batch.

The biggest unlock at Mynaksh has been working with people who deeply, deeply understand consumer behavior. My YC co-workers were brilliant about hospitals. My current co-workers are brilliant about why people open an app at 11pm and want to talk about their relationship. Those are different domains. Both are real.

What I'd Tell Past Me

If you'd told me a year ago that I'd be building consumer AI for an astrology app, I'd have laughed. I had a clear story: AI for high-stakes industries. Healthcare. Maybe legal. Maybe finance. The "serious" stuff.

What I learned is that the seriousness was in my head, not in the work. Building real-time conversational AI that scales to thousands of concurrent sessions is technically harder than most of what I did at Mantys. The product surface is bigger. The user is closer. The feedback loop is faster.

If you're an engineer thinking about a similar pivot, the only thing I'd say is: don't take the "high-stakes" framing at face value. The stakes that matter for you might not be the ones that look most serious from the outside. They might be the ones where you can move fastest, learn most, and ship something that makes people's days a little better.

I miss the patients. I do. But the work I'm doing now is also work, and that turns out to be enough.