I built a Chrome History replacement with zero AI, on purpose

The easiest pitch for Browser Memory would have been the obvious one:

"AI for your browser history."

It almost writes itself. Summarize your browsing. Ask questions about your past tabs. Let a model name your research sessions. Turn every messy trail into a neat little sentence.

And honestly, I understand why that pitch is tempting.

Browser history is full of context. It has websites, timestamps, page titles, topics, abandoned searches, product comparisons, debugging trails, and all the strange routes people take when they are trying to understand something. If you gave that data to a language model, it could probably produce a decent summary.

But the more I thought about it, the more it felt wrong for this specific product.

Browser Memory is a Chrome history replacement I built because I was tired of losing useful pages inside a flat list of URLs. I wanted sessions, a real timeline, notes, collections, favorites, domains, and fast local search. I wanted my browser to remember the shape of my day, not just the pages I touched.

But I did not want to send that history somewhere else to make it feel smart.

So I built it with zero AI, on purpose.

Browser history is not ordinary data

A lot of app data feels personal. Browser history is different.

It is not only a list of sites. It is a trail of curiosity, uncertainty, private research, work problems, half-formed plans, health questions, finance searches, relationship questions, career moves, and quiet late-night spirals that nobody announces out loud.

Even boring browsing can be sensitive once you see it in sequence.

One page might mean nothing. Ten pages in a row can say a lot.

That is why I did not want Browser Memory to depend on an external AI service. The moment the product needs a model endpoint to explain your history, the privacy story becomes more complicated. Now there are API calls. Now there are logs to think about. Now there is retention policy language. Now the user has to trust not only the extension, but also the path their history takes outside the browser.

For some products, that tradeoff is worth it.

For a history replacement, I wanted a simpler promise:

Your browsing data stays on your device.

No account. No backend. No cloud sync. No analytics. No hidden model request carrying your timeline across the internet.

That promise shaped the whole product.

"Smart" does not have to mean AI

One mistake I kept noticing while building this is how quickly we use the word smart as a synonym for AI.

But a tool can be useful, contextual, and adaptive without calling a language model.

A calendar reminder that fires at the right time is smart. A file search that ranks exact matches first is smart. A code editor that remembers your recent projects is smart. None of those things need to be generative to be helpful.

Browser Memory works the same way.

It uses deterministic local rules to organize history into structures that make sense:

• sessions grouped by inactivity gaps
• timeline entries grouped by day
• domains ranked by activity
• fast search across titles, URLs, domains, and notes
• favorites for pages and sessions
• collections for research that lasts longer than one sitting
• export tools for CSV and JSON
• local settings so the behavior can be tuned

That is not AI. It is product thinking.

The question was never, "How do I make the browser sound intelligent?"

The better question was, "What structure is already hiding in the data, and how can the interface reveal it?"

Why sessions were the first real breakthrough

Chrome's default history page treats every visit like a separate row.

That is technically accurate, but it misses the human pattern.

When I research something, I rarely open one page. I open a cluster. Maybe it starts with a search result, then a docs page, then a GitHub issue, then an example, then a forum thread, then a product page. The individual URLs matter, but the group matters more.

That group is the memory.

So Browser Memory groups browsing into sessions using inactivity gaps. If I stop browsing for a while, the next burst becomes a new session. It is simple, explainable, and surprisingly useful.

The timeline screenshot I used for this post shows the same idea from another angle: instead of one endless stream, pages are placed inside a day view. I can move by date, switch ranges, and see what happened without opening Chrome's default history page and guessing my way through timestamps.

This kind of organization does not require a model.

It requires respecting the way people actually browse.

The benefit of deterministic behavior

There is another reason I avoided AI: I wanted Browser Memory to be predictable.

If the same browsing history is on my device tomorrow, the app should organize it the same way. If a session gets a title, I should be able to understand why. If something is grouped together, I should be able to trace the rule behind it.

AI can be impressive, but it can also be slippery. It may give a slightly different label tomorrow. It may summarize with too much confidence. It may miss the one boring tab that actually mattered. It may turn a private browsing trail into a polished story I never asked for.

I did not want Browser Memory to narrate me.

I wanted it to assist me.

That difference sounds small, but it changes the product.

A deterministic system can be tuned. Thresholds can be adjusted. Rules can be explained. A user can understand what the extension is doing instead of feeling like a black box is judging their activity.

For a browser tool, that matters.

Local-first made the product calmer

Once I committed to zero AI, a lot of decisions became clearer.

The data model had to live in the browser. Favorites, notes, collections, and settings could be stored locally. Search could run locally. Session grouping could happen locally. The app did not need a login screen because there was no server account to create.

That made Browser Memory feel calmer as a product.

No onboarding asking for an email before you can use your own history. No "syncing your workspace" spinner. No vague analytics language. No pretending that browser data is harmless because it is only used to improve the experience.

The tool opens, reads what Chrome already knows locally, organizes it, and gives you a better way to return to it.

That is the whole loop.

I like products where the loop is easy to explain.

What zero AI forced me to design better

Skipping AI did not make the work smaller. In some ways, it made the product harder.

If I had used AI, I could have hidden a lot behind a summary. A model can generate a nice title even when the underlying interface is weak. It can make a rough feature feel more magical than it really is.

Without that layer, the product had to stand on clearer mechanics.

The timeline needed to be readable. Sessions needed to be genuinely useful. Search needed to feel fast. Notes needed to sit where people would actually find them again. Collections needed to make sense as long-running research folders, not just another place to dump links.

The structure had to do the work.

That was good pressure.

It pushed Browser Memory away from novelty and toward usefulness.

The permissions had to be explainable too

A Chrome history replacement needs permissions. There is no honest way around that.

Browser Memory uses the history permission because it needs to read browsing history. It uses storage for saved app data like favorites, notes, collections, and settings. It uses tabs-related capabilities to help reopen pages and continue sessions.

The important part is scope.

The extension is not designed to watch page content in the background. It does not need host permissions for every website. It does not send your history to a server. The activeTab and scripting permissions are used for a specific shortcut-driven settings overlay, not for silently inspecting pages.

That is the standard I kept coming back to: if I cannot explain the permission in plain language, I should question whether the feature deserves it.

Users do not need a dramatic privacy speech. They need a product whose behavior is narrow enough to trust.

What I learned from building it

The biggest lesson is that "no AI" can be a feature, not an apology.

There is a category of product where AI makes the experience better. There is also a category where the user mostly wants speed, privacy, predictability, and control.

Browser history belongs closer to the second category for me.

I do not need my browser to write an essay about what I did yesterday. I need it to help me find the page I almost remember. I need it to show the session around that page. I need it to let me save a note, open the surrounding tabs, export a trail, or move a set of pages into a collection.

That is enough intelligence.

Maybe even the better kind.

Who this is for

Browser Memory is for people who keep too many tabs open because closing them feels like losing progress.

It is for developers who bounce between docs, issues, examples, and Stack Overflow. It is for designers collecting references. It is for founders comparing tools. It is for anyone who has re-searched something they already found because Chrome's history page technically had it, but did not make it easy to recover.

If your browsing happens in bursts, your history should understand bursts.

Not by sending the story of your day to an AI model.

By organizing the local data your browser already has.

The product I wanted

I built Browser Memory because I wanted a history page that felt more like memory than storage.

A timeline for when I remember the day.

Sessions for when I remember the task.

Domains for when I remember the source.

Notes for when I remember why it mattered.

Collections for when the research becomes a project.

And all of it local, deterministic, and quiet.

That was the point from the start.

Not AI-powered history.

User-powered memory.