P.S. If you want more privacy-first AI and indie-builder workflows like this one delivered to your inbox every week, join 1,000+ readers getting them free: wuki.beehiiv.com/subscribe.
Every AI assistant I tried wanted my data more than it wanted to help me.
Sign in with your whole identity. Grant access to everything. "We may use your conversations to improve our models." Somewhere in the settings there's a toggle that turns the creepy stuff off — if you can find it.
So when I decided to build an AI assistant that lives in the browser, I made one decision before writing a line of code: zero data retention is the default, not a setting. No prompt storage. No browsing profiles. No training on conversations. The prompts and page content you send are used to generate your answer, then discarded.
That one constraint shaped every architectural decision that followed. Here's what building it taught me.
The product: an assistant that understands the page you're on
The idea is simple. You know how ChatGPT is a tab you switch to, and copying text between your browser and the tab is the actual work? The assistant should live where you already are.
So SideKik does three things:
- Chat with any page — summarize articles, docs, dashboards, and PDFs, ask questions, pull out key details. No copying anything anywhere.
- Act on the page — "fill this form with my details", "find the cheapest option", "click through to the invoice". It reads the DOM, performs the actions, always with your approval.
- Write anywhere — a sparkle button appears next to every text box. Generate a reply, improve your wording, translate, shorten — right where you type.
The "write anywhere" part is the one that feels like magic to people, and it was the hardest to build well. Injecting into every input on every site means dealing with contenteditable divs, shadow DOM, iframes, React-controlled inputs that reject programmatic values, and sites that re-render the DOM under you mid-keystroke.
Why "zero data retention" is an engineering decision, not a marketing line
Anyone can say they don't store prompts. Actually building it means:
No prompt database, period. There is no table to query, no log to grep, no cold-storage bucket sitting on a shelf. If the feature doesn't exist, the trust question answers itself.
Stateless requests. Each prompt goes to the model provider and the response comes back. The configuration is the only thing that persists (your account, your token balance). Conversations live for the duration of the request and not a millisecond longer.
No training, contractually and technically. The provider agreements prohibit training on your conversations, and because there's nothing retained server-side, there's nothing to train on in the first place. The second guarantee is stronger than the first.
Delete = actually deleted. Account deletion is one click and removes your personal data. No dark patterns, no "we may retain backups for compliance" fine print.
The honest takeaway: building a zero-retention product means giving up a lot of product surface. You can't offer "sync your chat history across devices". You can't show "your most asked questions". You can't mine prompts for feature ideas. I think that trade is worth it — privacy is the default position of someone who has nothing to hide, and for an assistant that reads everything you read, it's the only position that scales.
The economics: token metering done right
Retention-free products still have bills. The model calls cost real money, and usage varies wildly — someone summarizing two articles a week costs pennies; someone drafting replies in every text box all day costs dollars.
The answer was token metering with a generous free tier:
- Free: 50,000 tokens/month. No credit card. Enough for real, daily casual use.
- Pro: $9/month for 5 million tokens — roughly 100x the free tier — plus priority responses.
The design lesson here: measure usage in the unit that actually maps to your cost (tokens), not in the unit that's easy to count (requests). A 200-token summary and a 2,000-token reply are not the same request, and metering by request punishes the people who use you most.
What the Chrome Web Store review actually taught me
You can't ship a Chrome extension without surviving the CWS review, and it's a real process: privacy disclosures, justification for every permission, and a wait that takes days even when everything is in order. The activeTab-style permission model is your friend — request access when the user invokes you, not in the background. SideKik reads a page only when you open it. No background scanning, no browsing history, no keystroke logging. That posture isn't just good for the review — it's the whole product thesis.
What I'd tell someone building the same thing
- Make privacy the constraint, not the feature. When it's a constraint, it generates architecture. When it's a feature, it generates a settings page.
- The "every text box" experience is the differentiator. Chat panels are a commodity now. Intercepting the place where the user already types is where an assistant becomes native.
- Your cost unit is your pricing unit. Meter tokens, not requests.
If you want to try it: SideKik is free — add it to Chrome with no credit card, and yes, your prompts are never stored.
What's the one AI assistant behavior that would make you switch tools permanently?
Top comments (0)