Keshav

Posted on May 26

The Hardest Part of Building an Encrypted Journaling App Wasn’t Encryption

#flutter #security #privacy #programming

Lessons learned building client-side AES-256 encryption, secure sync, and emotionally safe UX in Flutter.

Most apps treat privacy as a feature.

We treated it as infrastructure.

When we started building RozVibe — a privacy-first encrypted journaling app built with Flutter — we quickly realized something uncomfortable:

A journaling app without real privacy creates emotional hesitation.

People write differently when they think someone else might read their thoughts.

And that changes everything.

Because journaling is not just data storage.

It’s cognitive decompression.

It’s emotional honesty.

And honesty requires trust.

The Problem With Most “Private” Apps

A surprising number of apps marketed as “private” still process user data server-side.

Yes, they may use HTTPS.

Yes, databases may be encrypted at rest.

But in many systems:

the company can still access user content
administrators theoretically retain visibility
journal entries may be processed in plaintext
personal reflections become behavioral analytics data

Technically, the data may be secured.

Psychologically, it still doesn’t feel safe.

That distinction became incredibly important while designing RozVibe.

Because emotional safety is not only a UX problem.

It’s an architectural problem.

Our Decision: Encrypt Before Data Leaves the Device

From the beginning, we adopted a strict engineering principle:

User journal content should never be readable by our servers.

That decision immediately shaped the entire system architecture.

Instead of relying on traditional server-side encryption, we implemented client-side AES-256-GCM encryption directly on the device.

Before any journal entry is synced:

Content is encrypted locally
A unique nonce/IV is generated for every encryption operation
Authentication tags are attached
Only ciphertext is transmitted to the backend
The server stores encrypted blobs only

The backend never sees plaintext journal entries.

Even if storage infrastructure were compromised, the stored data would remain unreadable without user-controlled encryption keys.

That trust model mattered deeply to us.

Why We Didn’t Use Server-Side Encryption

Server-side encryption solves infrastructure security problems.

But it does not fully solve trust problems.

With server-side encryption:

the backend still controls decryption
plaintext may exist during processing
administrators can theoretically access content
users must trust infrastructure they cannot verify

We wanted a different model.

In RozVibe, encryption happens before data leaves the device.

The server stores ciphertext — not journal entries.

That architectural distinction fundamentally changes the relationship between the product and the user.

Why AES-256-GCM?

We evaluated multiple encryption approaches before choosing AES-256-GCM.

For a mobile journaling application, we needed:

authenticated encryption
strong security guarantees
tamper detection
low performance overhead
reliable mobile compatibility

AES-GCM offered all of those advantages.

Performance mattered more than we initially expected.

People open journaling apps during emotionally important moments:

late-night reflection
anxiety spikes
emotional overwhelm
quick memory capture

Encryption cannot introduce noticeable friction.

Otherwise people stop writing.

One of the most overlooked parts of privacy engineering is this:

Security that feels heavy often becomes abandoned security.

AES-GCM gave us both security and responsiveness.

The Hardest Engineering Problem Wasn’t Encryption

Surprisingly, implementing encryption itself was not the hardest challenge.

Key management was.

Because encryption strength becomes meaningless if key handling is weak.

Mobile apps constantly deal with unstable environments:

devices restart
sessions expire
users reinstall apps
cloud sync introduces edge cases
operating systems aggressively manage memory

We explored multiple approaches:

Secure Enclave / Keystore integration
OS-protected secret storage
session-derived keys
encrypted persistence layers
recovery edge cases

Balancing usability with strong security became one of the most difficult architectural tradeoffs in the entire project.

Privacy-First Architecture Changes Everything

One of the surprising realizations during development was how quickly privacy-first architecture complicates otherwise normal product decisions.

Even simple features become harder when the backend is intentionally blind.

For example:

Search

Traditional search systems index plaintext content server-side.

Encrypted journaling systems cannot safely do that.

That forces difficult tradeoffs:

local indexing
encrypted search models
limited search capabilities
offline-first constraints

Syncing

Traditional sync systems assume the backend understands the data structure.

Encrypted sync changes that completely.

The server becomes intentionally unaware of:

journal content
emotional metadata
search context
user meaning

That affected:

conflict resolution
sync optimization
storage debugging
recovery flows
consistency handling

Privacy-first engineering forces you to rethink standard SaaS assumptions from the ground up.

Security UX Is Emotional UX

One lesson became increasingly clear while building RozVibe:

Security UX is emotional UX.

If privacy tools feel intimidating, users disengage.

Many secure products accidentally create anxiety through:

aggressive warnings
technical overload
complicated onboarding
“cybersecurity dashboard” aesthetics

We wanted the opposite.

So we intentionally designed RozVibe with:

minimal visual noise
calm writing spaces
quiet onboarding
simple privacy explanations
reduced cognitive overload

We didn’t want users to constantly think about encryption.

We wanted them to feel psychologically safe enough to write honestly.

That distinction matters more than many engineers realize.

Privacy Is Also a Psychological Design Problem

Building RozVibe changed how we think about software itself.

Modern apps are often optimized for:

engagement
retention
extraction
behavioral profiling
surveillance-driven personalization

Over time, users subconsciously learn this.

And they become less honest online.

Especially in personal spaces.

People begin self-censoring.

Even privately.

That realization fundamentally changed how we approached product design.

Instead of asking:

“How much data can we collect?”

We started asking:

“How little data do we actually need?”

Instead of:

“How do we maximize engagement?”

We ask:

“How do we reduce emotional friction?”

Instead of:

“How do we maximize retention?”

We ask:

“How do we create trust?”

Those questions lead to very different software.

What Building RozVibe Taught Us

Before building RozVibe, we viewed encryption mostly as a technical system.

Now we see it differently.

For deeply personal software, encryption becomes emotional infrastructure.

It gives people space to think honestly without feeling observed.

And honestly, building privacy-first software changed the way we think about engineering entirely.

Not just technically.

Philosophically.

Final Thoughts

The internet has trained people to expect surveillance by default.

That expectation quietly changes human behavior.

Especially in emotionally vulnerable spaces.

Maybe privacy-first software is ultimately about restoring something much simpler:

The ability to be honest with yourself.

If you’re building privacy-first products, secure systems, or thoughtful software architecture, I’d genuinely love to hear how you think about trust, encryption, and emotional safety in modern apps.