I Just Wanted to Know Where My Browsing Time Went. Five Years Later, Firefox Recommended It.

victor zhang — Fri, 15 May 2026 12:45:36 +0000

I didn't start this project because I wanted to build a productivity app.

It began with a smaller, almost embarrassing question.

Where did my time go?

Not in the philosophical sense. I just wanted to know why a browser tab opened “for a minute” could quietly take an hour with it. At the end of the day, the feeling was always blurry: I knew some time had disappeared, but I could not point to where, when, or how much.

So I built a browser extension for myself.

It recorded how long I stayed on each website, counted visits, and showed a simple chart. That was the whole product: a small mirror for my browser.

Five years after the first commit, that small tool has become Time Tracker - Web Habit Builder: an open-source browser extension for Chrome, Edge, Firefox, and Firefox for Android. Across browser stores, it has maintained a 4.9+ rating, and on Firefox it has earned Mozilla's rare Recommended badge.

I don't really think of this as a growth story.

It's more about what happens when a private little mirror keeps running into real users, real data, real browsers, and real habits.

1. The first version answered the wrong question

The first version answered a simple question:

How much time did I spend on each website?

It was useful, in a narrow way.

The project started in 2021. After I shared it on a small tech forum in 2022, I noticed something awkward. People installed it, opened the numbers for a few days, and then some of them drifted away.

The extension was working. The data was correct.

But correctness was not enough.

A number can be honest and still feel empty. “You spent 3 hours on YouTube today” doesn't automatically make anyone more aware. Sometimes it only adds guilt. Sometimes it fades into background noise. A number alone doesn't explain a pattern.

That was the first time I realized:

Tracking is not the value. Recognition is the value.

So the product slowly moved away from raw records and toward something users could actually recognize.

Compared with the version I wrote about in 2022, the biggest change is not more charts. The product now has two surfaces with different jobs.

The popup became a small daily cockpit: quick enough to answer what is happening right now. The dashboard became slower and more reflective: top sites, long-term trends, calendar heatmaps, and recent activity timelines.

The point is not to make the data look impressive. It is to make a messy browsing day recognizable.

Your day is not just “too much browsing.” It has a shape.

You open it and notice: this month was heavier than last month. The busiest time is not when you thought it was. One site is harmless on weekdays, then quietly takes over the weekend.

2. Users did not ask for more charts. They asked for help.

Once people could see their behavior, the next request became obvious.

Can it stop me?

That was when the product stopped being easy.

A time tracker is mostly passive. It observes. It records. It shows things.

A site blocker is different. It interrupts the user.

And the strange thing about this type of blocker is that the user is on both sides of the system. The calm version of the user creates a rule. The tired version of the user tries to bypass it.

At first, the limit feature was simple: set a daily limit for a website, and show a blocking page when the time is used up.

Then the edge cases started arriving.

Some users wanted weekly limits. Some wanted per-session limits. Some wanted weekday rules, URL-level blocking, strict mode, delayed unlocks, or a “five more minutes” option that was helpful but not too easy.

The rule system grew from a small condition into a real engine.

The change that helped most was much smaller: a warning.

In early versions, when time ran out, the block page appeared suddenly. It was technically correct, but emotionally rough. Users were interrupted at the worst possible moment.

Now the extension can notify the user before the limit is reached.

A few minutes of warning changes the relationship. The blocker no longer feels like a trap. It feels more like a reminder from the earlier version of yourself — the version that made the rule before the impulse arrived.

That small detail taught me more than some much larger rewrites.

For behavior-related products, friction matters. But the timing of friction matters even more.

3. A good default is quieter than onboarding

Over the next few years, the extension accumulated many features: categories, virtual sites, timelines, side panels, dark mode, import, sync, mobile support, and localization.

At that point, an onboarding flow would have been easy to justify.

I still didn't add one.

My rule is simple: if a feature must be explained before it can be used, the interaction probably needs more work.

I ended up designing the extension in layers. After installation, tracking starts automatically. Click the icon, and you get today's overview. Open the dashboard, and you see longer-term patterns. Go into options, and you can customize a lot.

Power users can configure a lot, but configuration doesn't stand at the entrance. That is one of the most important product decisions in the project.

4. Privacy was not a feature checkbox. It shaped the architecture.

The extension sits close to sensitive data.

Browsing history is personal. Even if the product doesn't care about the content of pages, the pattern itself says a lot about a person.

So from the beginning, I avoided accounts, servers, and analytics collection. The data stays local by default.

Later, users asked for cross-device backup and remote query. Instead of building my own cloud service, I added user-controlled sync options:

GitHub Gist
Obsidian local REST API
WebDAV

That means users bring their own storage. The extension provides the integration, but doesn't become the data owner.

This decision made some things harder. There is no central backend to debug. Different WebDAV servers behave differently. Obsidian users have different local setups. Gist has its own API limits and edge cases.

But it fits the product.

A tool about personal habits shouldn't quietly become another place where personal history is collected.

5. Long-term users and real browsers changed the engineering priorities

The product looked simple when the data was small and the browser target was mostly Chrome.

Then the history started doing what history does: it piled up.

After two or three years of daily tracking, browsing history was no longer a small settings object. It had become time-series data: large, structured, and constantly queried. Reports became slower. Popup loading became heavier. The product was starting to punish the users who had trusted it the longest.

So in v4.0, I moved tracking data to IndexedDB. The goal was not to show off a new architecture. The goal was quieter: heavy users should update, keep their history, and simply feel that the product had become lighter.

Firefox brought a similar reminder from another direction. Browser extensions only look standardized from a distance. Background behavior, sidebar APIs, Android support, and Manifest V3 details all differ enough to matter.

Supporting Firefox well meant making the cross-browser design more explicit: separate platform behavior where needed, fewer assumptions from one browser, and more testing around the places where users actually feel the difference.

The Mozilla Recommended badge came much later. I didn't build the product for that badge. But looking back, these boring engineering decisions probably mattered: safer data migration, faster reports, fewer platform assumptions, and a product experience that feels native instead of merely compatible.

6. Community changed the product more than metrics did

The product has no growth team, no ads, and no onboarding funnel.

Most improvements came from users saying very specific things.

A user wants to merge several domains because one service uses many subdomains. Another user wants to import data from another extension. Someone wants to track local files. Someone wants WebDAV. Someone wants Firefox Android. Someone wants the interface to feel native in their own language.

Those requests were not abstract “user needs.” They were real situations.

Translation is the clearest example. The project now has a Crowdin-based workflow, with English as the required source locale and partial translations allowed to fall back safely.

Today it has locale targets for 14 languages.

That detail matters because internationalization is not just uploading strings. The extension still has to map browser language codes, validate placeholders, generate extension metadata, and handle layout direction for RTL languages.

This changed how I think about feedback.

A public review is nice. But a detailed issue, a screenshot, or a carefully described routine is often more valuable. It tells you where the product is meeting real life.

7. Today, it is no longer just a tracker

This is the part that changed the most since the early days.

The tool started as a way to answer one narrow question: where did my browsing time go?

Now, that answer is only the beginning. The project has become less about measuring time itself, and more about helping users notice the patterns around it.

It's a small shift in wording, but it changed how I think about the product.

A tracker records what happened. A habit system helps users recognize what keeps happening, and gives them a few ways to respond without handing their browsing history to someone else's backend.

That is the current shape of the project: still simple enough to install and understand in a minute, but mature enough for people who want to work with their browsing behavior over time.

8. What I would do differently

If I were to start again, I would spend less time thinking about the feature list, and more time thinking about how quickly a new user could get one useful answer.

A user should be able to install it, open the popup, and understand something about today without reading a guide.

I would still add advanced options, but I would place them behind natural paths: reports after people have data, rules after people notice a pattern, sync after people care about history, import after people are ready to switch.

There are technical things I would do earlier, of course: IndexedDB, integration tests, and more explicit cross-browser design.

But the simpler lesson is the one I keep coming back to: don't make users pay attention before the product has earned it. Let the default experience carry the first mile, and treat real user routines as product input, not just support work.

Links

If you are building a small product that started as a personal tool, I would love to hear what changed when real users walked in.

Use i18n with TypeScript checks

victor zhang — Fri, 28 Jun 2024 06:16:15 +0000

I tried a simple way to check i18n resources with TypeScript to reduce errors. Here share it with you guys.

Steps

Firstly, enable resolveJsonModule in your tsconfig.json

{
    "compilerOptions": {
        "resolveJsonModule" true
        // ...
    }
    // ...
}

Define the type for locales

export type Locale = 'en_US' | 'zh_CN'

Define the type for messages

export type Messages<T> = {
    [locale in Locale]: T
}

Define the type for your resource

export type AboutMessage = {
   label: {
       name: string
       version: string
   }
   tip: {
       feedback: string
   }
}

Edit resource json file

{
    "en_US": {
        "label": {
            "name": "My App",
            "version": "Version",
        },
        "tip": {
            "feedback": "This is a feedback link"
        }
    },
    "zh_CN": {
        "label": {
            "name": "我的应用",
            "version": "版本",
        },
        "tip": {
            "feedback": "这是反馈链接"
        }
    }
}

And then, define t() function

import resource "../app-resource.json"

// Use this to check if your resource file is correct
const messages: Messages<AboutMessage> = resource

// Define a function key to get snippet tips while invoking t()
type Key = (msg: AboutMessage) => string

export function t(key: Key, locale: Locale) {
    try {
        return key?.(messages[locale])
    } catch { /* ignored */ }
    try {
        return key?.(messages['en_US'])
    } catch { /* ignored again */ }
    return null
}

Finally, you can use it like this, or integrate it into other frameworks

const feedbackTip = t(msg => msg.tip.feedback, 'en_US')

Real Project

The above is just a simple example of my idea, you can extend it according to your project.

And I applied it to my own project Time Tracker which is a browser extension helping people track the time spent on each website.

Thanks for reading

DEV Community: victor zhang