Crisis Detection, Context Infrastructure, and the Trade-Offs of Shipping an AI Journaling App

Today I shipped the core journaling loop for my AI companion app, passed adversarial testing, and rebuilt my entire operational workflow from scratch. Here is what I learned about the strategic trade-offs that define early-stage AI product development.

Ship What Works. Hide What Doesn't.

One of the fastest ways to erode user trust is showing features that look interactive but do nothing. I had UI elements for tags and AI-generated summaries stubbed out in the interface, waiting on a Gemini integration that was not ready. I pulled them entirely. The principle is simple: an absent feature is neutral, but a broken-looking feature is negative. This applies doubly to AI products, where users are already calibrating how much to trust the system.

On the backend, I wired journal entry persistence to Supabase with streak tracking, a completion screen, and an unsaved-conversation navigation guard. The guard exposed an early race condition during testing where state was clearing before the check could fire, a reminder that async UI state and user-facing safety checks need deliberate sequencing.

Safety as Architecture, Not Afterthought

The highest-leverage decision this week was implementing a pre-model crisis detection layer. Before any user message reaches Gemini, it passes through a hardcoded keyword interceptor checking over 30 crisis phrases. If triggered, the system delivers safe harbor resources directly, bypassing the LLM entirely.

Why bypass the model? Two reasons:

• Determinism. A hardcoded response is guaranteed. An LLM response is probabilistic. For crisis intervention, you need the guarantee.
• Regulatory exposure. California's SB 243 and New York's AI Companion Law create real liability for AI products that handle emotional distress poorly. A solo founder cannot afford to discover a safety gap in production.

During adversarial testing, figurative language like "I'm dying of laughter" triggered false positives. I accepted that trade-off explicitly. For a product in this category, a false positive is an inconvenience. A false negative is a lawsuit or, worse, a real harm. That asymmetry should drive every safety decision.

I formalized this into a four-tier prioritization framework: safety, legal, and privacy requirements override everything. Feature work only advances when those tiers are clear.

The AI Personality Problem

AI journaling sits in a psychologically tricky space. Users want to feel heard, but pure validation is documented to be harmful over time. I implemented a three-tone personality framework: Reflective Listener, Warm Companion, and Gentle Coach. The goal is to meet users where they are emotionally while preserving the ability to gently challenge patterns, not just mirror them.

This is a product design decision as much as a prompt engineering one. The personalities are not cosmetic skins. They represent distinct interaction models with different risk profiles, and getting this wrong has real consequences in a mental wellness product.

Prompt Engineering as Operational Infrastructure

The single biggest productivity unlock this week had nothing to do with code. It was treating prompt engineering as an infrastructure problem.

I consolidated all project context into a single "golden master file" maintained through diff-only patching. Every new chat session starts from the same canonical source of truth. This eliminated the most persistent failure mode I was hitting: the AI losing critical context across sessions because conversation search could not reliably retrieve earlier work products.

A few other workflow changes that compounded:

• Batching related frontend changes into single prompts saved daily credits on Lovable's free tier and, unexpectedly, produced more coherent code than splitting changes across multiple prompts. The model benefits from seeing related mutations together.
• Structuring the AI advisory layer into seven auto-detecting specialist roles with explicit disagreement resolution protocols immediately improved response quality. Giving the model a defined role and a defined process for handling ambiguity outperforms generic instructions.
• Enforcing a strict "one major deliverable per chat" rule kept context windows manageable and handoffs clean. Scope creep inside a conversation is just as dangerous as scope creep inside a sprint.
• Attaching full requirement specs to a queued work tracker eliminated the need to search past chats when drafting future prompts, closing another context fragility loop.

Where the AI Broke Down

Transparency about failure modes matters, so here is where the tools fell short:

• Context loss across sessions. The AI repeatedly could not find its own earlier outputs. Conversation search proved unreliable for retrieving verbatim content like system prompts and structured specs.
• Inaccurate self-reporting. The AI's percentage-based context window warnings were completely wrong during heavy artifact generation. When the model tells you it is at 60% capacity and then hits a wall, you lose trust in all its other self-assessments.
• Hallucinated constraints. The AI instructed me to manually edit code files, failing to account for the fact that Lovable's free tier is strictly read-only. This is a subtle but important class of hallucination: not fabricating facts, but fabricating capabilities.
• Token limit tuning. I had to set explicit token limits (maxOutputTokens: 1024, thinkingBudget: 400) to resolve truncation issues. The defaults were not viable for my use case.

The meta-lesson is that AI tooling requires the same observability mindset as any production system. You need to know when it is lying to you, and you need to design workflows that are resilient to that failure mode.

Mental Models That Held Up

Looking back at the week, a few principles proved consistently useful:

• Asymmetric risk analysis. When the cost of a false negative vastly exceeds the cost of a false positive, bias toward triggering. This applies to crisis detection, navigation guards, and compliance checks alike.
• Context is infrastructure. Treat your project's canonical context the same way you would treat a database schema: version it, patch it carefully, and never let it drift.
• Hide, don't ship, incomplete work. Incomplete features in AI products do not just look unpolished. They actively train users to distrust the system.
• Regulatory requirements are product requirements. In the AI companion space, compliance is not a legal team's problem. It is a design constraint that shapes architecture.

What is Next

The Gemini integration is the next major milestone, which will bring AI-generated summaries and the full personality framework online. The crisis detection layer and the compliance-first prioritization framework give me confidence that I can ship that integration without introducing unacceptable risk.

The operational workflow is finally stable enough that I am spending more time building product and less time fighting my tools. That ratio is the real metric for whether vibe coding is working.