I'm designing it. Then I'm building it.

My role

Co-founder — own all design, plus the React and Electron front-end build

The problem

Founders’ notes, docs and decisions scatter across tools; nothing is private, nothing is connected

What I did

Designed the product, then orchestrated the build end-to-end through an AI-augmented pipeline I run myself

Outcome

Concept to shipped MVP in ~2 months, with CI-enforced write-integrity and encrypted BYO-key security

Atelos is a desktop app that turns your scattered notes, docs and decisions into a vault Claude can actually use — without your data ever leaving your machine. I co-founded it with Daniel Foreman; he owns the heavy backend, I own everything you can see and click. I design the front-end, then orchestrate the React and Electron build through an AI-augmented pipeline I run end-to-end. Concept to shipped MVP in about two months — architecture decisions, a CI-enforced write-integrity layer and encrypted bring-your-own-key security all written by the same hand that designed the screens.

The Electron build, now a working MVP in early users' hands. Real inbox, real captures, real skills strip. Two months ago this was a Figma file — now it's shipping, and I'm pushing commits to it.

The bet we made

Most AI knowledge tools — Obsidian, Notion, Mem — use vector search to find what's relevant to your prompt. Vector search is great until it isn't, and when it isn't, you don't know why. We bet on something different: a cascading index. Plain markdown files that act as signposts at each folder level, so the AI walks the structure of your vault instead of guessing at it. Deterministic, explainable, and dead simple to debug.

What I do, in order

I run the research. I write the specs. I prototype in HTML. I test the prototype with real users. I take their feedback and rebuild. Then — this is the new part — I orchestrate the Electron and React build that ships: architecture, prompts, integration, debugging, commits. The boundary between "designer" and "engineer" mostly gets in my way these days, so I stopped pretending it was there.

Persona journey map for Sam — one of three personas I built. The fourth column is "anti-personas," the people we explicitly don't build for. Scope discipline, not gatekeeping.

What testing told us

Four user-test sessions across the target personas — a PM director, two product designers, a senior UX designer who hates terminals on principle. Three things came back the same way every time: skills are the strongest hook, project-level organization fills a real gap, and local-first lands as a feature, not a worry. The friction was where you'd want it to be — first-run orientation and the ChatGPT-to-vault mental shift. Both fixable in onboarding without touching the architecture.

"Chats, files, and tasks. I love how it's all separated out. That's such a smart move to parse out those differences." — James, Senior UX Designer, in testing

Kelli — the PM director — had already built her own DIY version of Atelos inside Claude Projects. When she saw the skills strip, she said pre-built skills "would save somebody a lot of hours in setup." That's the toughest persona to convince, validating the wedge unprompted.

Quick Capture — four entry paths, one principle: see it, click it, done. The kind of design problem you don't get to solve unless you also build the thing.

Why I think this matters

Most product orgs have a wall between "the designer who specs it" and "the engineer who ships it." That wall is where AI-native products go to die. I closed it on this one. The same person ran the research, wrote the specs, tested with users, and orchestrated the build that shipped. That's the profile, in one sentence.