What We Changed After Taking a Hard Look at Our Own Product

What We Changed After Taking a Hard Look at Our Own Product

Earlier this year we went through Daylogue ourselves, feature by feature, looking for the places where our good intentions had quietly turned into bad design. Nobody made us. No regulation demanded it. We did it because we handle people's honest reflections about their inner lives, and that deserves more scrutiny than the law happens to require.

To be clear about what this was: our own team, reviewing our own product, against a rubric we wrote. Nobody outside the company looked at it. There is no certificate, no grade, and no third party standing behind any of this. What there is, is a list of things we found and a list of things we changed.

Here's the list.

Why We Did It

Most wellness apps operate in a regulatory gray zone. They're not medical devices, so they don't need FDA approval. They're not handling health records in the HIPAA sense (unless they want to be). They can collect incredibly intimate data about your emotional life and face very few formal requirements about what they do with it.

That bothers us. Not because we were doing anything wrong, but because "not doing anything wrong" is a low bar. We wanted to know: Are we doing this well? Are there places where our good intentions are getting undermined by design choices we haven't examined? Are we creating risks we haven't considered?

Reviewing your own work has an obvious limit: you're the one with the blind spots. We know that. The fix isn't to pretend otherwise, it's to write down what we found so anyone can check it against what the app actually does.

What We Looked At

Privacy and data handling. Consent and transparency. Engagement design, meaning are we using manipulative patterns. Content safety, meaning what happens when someone is in crisis. Equity and accessibility. Language and framing, meaning are we making clinical claims we shouldn't be making.

We held ourselves to what was shipping, not what was on the roadmap. Planning to build something better doesn't count while the old thing is still in users' hands.

What We Kept

A few things came through the review intact.

Entry text is kept out of Daylogue's application logs and error reports. Your check-in data is protected in transit by TLS and by per-user access controls in the database. This one is checkable: it's a hard return in the logging code, not a policy.

No data selling. We don't sell your data. We don't share it with advertisers. We don't use your entries to train our models without explicit consent. Our business model is subscriptions, not surveillance.

No inference from face or tone of voice. Daylogue does not read how you feel from your expression or from the sound of your voice. It reads the words, including the ones you speak in a voice check-in.

Privacy-first enterprise model. Our enterprise offering uses K-anonymity and anonymous aggregate dashboards. Organizations see trends. They never see individual entries. The individual controls their data completely.

These weren't surprises. They're core to how we think about the product. Saying so isn't proof of anything, which is why we've tried to keep each claim specific enough that you can go check it yourself.

What We Changed

Then there's the part that was uncomfortable.

Removed all streak mechanics. We had some streak-adjacent features. Subtle things like consecutive check-in counts and notifications that referenced consistency. Loss-aversion mechanics are a compulsion risk. Gamification around consistency manufactures guilt for inconsistency, which is the exact feeling a wellness tool exists to not create, and it contradicts a product we built on no guilt and no shame.

We agreed. We removed all of it. Not just the visible UI elements, but the backend tracking. The infrastructure still exists in the database for compatibility, but nothing reads or writes to it anymore. When you come back to Daylogue after a break, there's no counter reminding you how long you were gone. Just "welcome back."

Improved crisis protocol. The worst thing we found was in the voice check-in. If someone said something that suggested they might be in crisis, the AI showed crisis resources and then kept talking. The handoff wasn't immediate, and a voice that keeps going is a voice competing with the number on the screen. We implemented a protocol where the conversation ends within two seconds of triggering crisis resources, and the resources (including 988 Suicide and Crisis Lifeline) are displayed prominently.

We're a wellness tool, not a crisis intervention service. But when someone is in our space and they need help we can't provide, getting them to that help fast is our responsibility.

Reframed clinical-sounding language. Our language had drifted more clinical than it should be. "Therapy prep," "burnout risk," "assess," "intervention" had crept into prompts and into internal labels that were sometimes visible to users. We went through the entire product and reframed.

"Assess" became "notice." "Therapy prep" became "session summary." "Burnout risk" became "sustained elevated stress." "Anxiety" as a tag became "worry." "Mental health" became "self-care." These aren't just word swaps. They reflect a genuine distinction: Daylogue helps you notice patterns. It doesn't diagnose conditions.

Added scope disclaimer. We added clear messaging about what Daylogue is and isn't. It's a wellness tool for self-awareness. It's not therapy. It's not a substitute for professional help. If you're struggling, talk to a human. This disclaimer now appears in onboarding and on key pages throughout the app.

Age verification and minor protections. There was no age gate at all. A thirteen-year-old could open a voice check-in with an AI and we would have had no idea. We added a birthday verification step in onboarding. Users under 13 are blocked entirely. Users between 13 and 17 are flagged internally so we can build age-appropriate guardrails as we develop them.

What We're Still Working On

Transparency means being honest about the gaps, not just the wins.

Minor-specific content guardrails. We flag minor users but we haven't yet built differentiated AI guardrails for them. A 16-year-old's check-in experience should probably differ from an adult's in certain ways, and we're still figuring out exactly how.

AI data handling disclosure. We need to be clearer about exactly how AI processes check-in data. The short version: Daylogue reads your entries to write your narratives and detect patterns, and the summaries and structured text it derives from them are stored unencrypted so the pattern engine can run on them. We should explain that in the product, not only in a blog post.

Our own encryption claims. This is the one we got wrong, and it took us until July to catch it. See the correction at the end of this post.

Dead streak code cleanup. The streak features are disabled, but the dead code still exists in dozens of files. It's not a user-facing issue, but messy code leads to messy thinking. We're cleaning it up over time.

Scope reminder in check-in view. The scope disclaimer appears in onboarding and on narrative pages, but not yet in the check-in chat itself. That's arguably the most important place for it, since that's where users are most actively engaging with the AI.

What This Process Taught Us

Three things stand out.

First, good intentions aren't enough. We built Daylogue with genuine care for our users' wellbeing. But care without examination creates blind spots. The streak mechanics are a perfect example. We didn't add them to manipulate anyone. They just seemed like standard engagement features. It took sitting down and actually asking what a streak does to someone who missed four days to see that "standard" doesn't mean "harmless," especially in a wellness context.

Second, language matters more than you think. The difference between "assess your mood" and "notice your mood" seems small. It's not. One implies clinical evaluation. The other implies gentle attention. In a wellness tool, that distinction shapes how people relate to their own experience. We're not evaluating them. We're helping them pay attention.

Third, the gaps are the useful part. Publishing the list of things we haven't fixed is uncomfortable. The alternative is claiming to be finished, which is obviously false, or saying nothing, which breeds suspicion. A tidy number would have been easier to publish and would have told you less than the four open items above.

The Ongoing Work

This isn't a one-time event and it isn't a credential. It's a checkpoint, and it only means something if the next one finds things too. We'll do this again. The gaps above will hopefully be closed. New ones will emerge as we build new features.

Building wellness software means accepting that you're handling something precious: people's honest reflections about their inner lives. That demands a level of care that goes beyond legal compliance and into genuine ethical responsibility.

We found things we didn't like in our own product and we changed them. That's the whole claim.

Correction, July 25, 2026. The "What We Kept" section of this post listed "optional end-to-end encryption" as something our review confirmed: an opt-in client-side setting you could turn on so entries were encrypted before they left your device and we could not read them. That was wrong. No such setting exists in Daylogue's Settings, most entries are stored unencrypted, and Daylogue reads your entries in order to write your narratives. The section also said "we encrypt everything at rest," which was not accurate either.

This is the worst place in our writing for that claim to have appeared. The premise of this post is that we checked, and on this item we did not check hard enough — we described an architecture we intended rather than the one that shipped, which is exactly the failure mode the post says it exists to catch. The bullets have been rewritten with claims that can be verified against the code. The next self-review starts with the security claims.