Two weeks ago, I shared the blueprint for the Clareifi Dev Stack. Today, the foundation isn't just poured—the first room is officially built, locked, and verified.

Clareifi Notes started with a simple, somewhat stubborn premise: Why does "cloud-native" usually have to mean "privacy-compromised"? I wanted the seamless experience of a modern web app but with the "lock and key" security of a local-first tool like Obsidian.

One month into building in public, Phase 1—The Secure Bunker—is officially complete. Here’s the story of how it’s coming together and what it’s like to build with everyone watching.

Most platforms promise privacy through a "Privacy Policy." We’re aiming for something better: Privacy by Architecture. The goal for Clareifi Notes is to create a space where it is structurally impossible for your sensitive work to be leaked or scraped for LLM training without your consent. We’re not just saying "we won't look at your data"; we’re building a system where we can't look at it even if we wanted to.

In this first month, the focus was entirely on the local-first encryption engine. If you poked around the GitHub repository today, you’d see a functional prototype that handles:

• PBKDF2 Key Derivation: Your password never leaves your head. We use 310,000 iterations to derive a non-extractable key right in your browser.

• AES-GCM 256-bit Encryption: Before a single note hits the storage layer, it’s wrapped in military-grade encryption using the native Web Crypto API.

• The "Zero-Knowledge" Proof: If you open DevTools and look at IndexedDB, you won't find a single readable word. Just encrypted blobs. No keys, no plaintext, nothing.

The tech stack—Svelte 5, Tailwind CSS 4, and the Web Crypto API—has proven to be a powerhouse for this kind of performance-heavy reactivity.

Building in public (follow the journey on Bluesky) is a double-edged sword. There’s no "big reveal" or "perfect launch." Instead, there’s the raw reality of commit messages, architectural pivots, and the occasional bug found by a sharp-eyed observer.

But that’s exactly why it works. When you're building a security-focused product, transparency isn't just a marketing tactic; it’s the only way to earn trust. Every line of code for the initial CI pipeline and every README update serves as a public ledger of the project's integrity.

With the "Bunker" secured, we’re moving into Phase 2: The Sync & Relay Layer. The challenge for Month 2 is making these encrypted notes move between your devices without compromising that zero-knowledge promise. We’ll be diving into CRDTs (Conflict-free Replicated Data Types) via Yjs or Automerge and setting up a Supabase "blind relay" that stores your encrypted data without ever having the keys to read it.

It’s an ambitious roadmap, but the foundation is solid. If you want to see the code behind the curtain, check out the Roadmap or dive into the Security Documentation.

The bunker is built. Now, it's time to bridge it to the world.

Two weeks ago, I shared the blueprint for the Clareifi Dev Stack. Today, the foundation isn't just poured—the first room is officially built, locked, and verified.

Clareifi Notes started with a simple, somewhat stubborn premise: Why does "cloud-native" usually have to mean "privacy-compromised"? I wanted the seamless experience of a modern web app but with the "lock and key" security of a local-first tool like Obsidian.

One month into building in public, Phase 1—The Secure Bunker—is officially complete. Here’s the story of how it’s coming together and what it’s like to build with everyone watching.

Most platforms promise privacy through a "Privacy Policy." We’re aiming for something better: Privacy by Architecture. The goal for Clareifi Notes is to create a space where it is structurally impossible for your sensitive work to be leaked or scraped for LLM training without your consent. We’re not just saying "we won't look at your data"; we’re building a system where we can't look at it even if we wanted to.

In this first month, the focus was entirely on the local-first encryption engine. If you poked around the GitHub repository today, you’d see a functional prototype that handles:

• PBKDF2 Key Derivation: Your password never leaves your head. We use 310,000 iterations to derive a non-extractable key right in your browser.

• AES-GCM 256-bit Encryption: Before a single note hits the storage layer, it’s wrapped in military-grade encryption using the native Web Crypto API.

• The "Zero-Knowledge" Proof: If you open DevTools and look at IndexedDB, you won't find a single readable word. Just encrypted blobs. No keys, no plaintext, nothing.

The tech stack—Svelte 5, Tailwind CSS 4, and the Web Crypto API—has proven to be a powerhouse for this kind of performance-heavy reactivity.

Building in public (follow the journey on Bluesky) is a double-edged sword. There’s no "big reveal" or "perfect launch." Instead, there’s the raw reality of commit messages, architectural pivots, and the occasional bug found by a sharp-eyed observer.

But that’s exactly why it works. When you're building a security-focused product, transparency isn't just a marketing tactic; it’s the only way to earn trust. Every line of code for the initial CI pipeline and every README update serves as a public ledger of the project's integrity.

With the "Bunker" secured, we’re moving into Phase 2: The Sync & Relay Layer. The challenge for Month 2 is making these encrypted notes move between your devices without compromising that zero-knowledge promise. We’ll be diving into CRDTs (Conflict-free Replicated Data Types) via Yjs or Automerge and setting up a Supabase "blind relay" that stores your encrypted data without ever having the keys to read it.

It’s an ambitious roadmap, but the foundation is solid. If you want to see the code behind the curtain, check out the Roadmap or dive into the Security Documentation.

The bunker is built. Now, it's time to bridge it to the world.